dri-devel March 2018

dri-devel@lists.freedesktop.org

263 participants
1856 discussions

[Bug 105359] kms_frontbuffer_tracking - FBC disabled
by bugzilla-daemon＠freedesktop.org 06 Mar '18

06 Mar '18

https://bugs.freedesktop.org/show_bug.cgi?id=105359 --- Comment #5 from Marta Löfstedt <marta.lofstedt(a)intel.com> --- very funny PW results on shards basically all fbc related frontbuffer_tracking tests are skipped. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH v2 00/10] drm/sun4i: Allwinner MIPI-DSI support
by Maxime Ripard 06 Mar '18

06 Mar '18

Hi, Here is an preliminary version of the MIPI-DSI support for the Allwinner SoCs. This controller can be found on a number of recent SoCs, such as the A31, A33 or the A64. Given the sparse documentation, there's a number of obscure areas, but the current implementation has been tested with a 4-lanes DSI panel on an A33. The support is a bit rough around the edges at the time, and some artifacts are still shown on the screen for some reasons. Wider testing with different display will hopefully nail those down. Let me know what you think, Maxime Changes from v1: - Rebased on 4.16-rc1 - Constified a few function arguments and structures - Reworked the DT binding example a bit - Reworked the panel driver to check for DSI return codes, and use DCS helpers when possible Maxime Ripard (10): regmap: mmio: Add function to attach a clock drm/sun4i: tcon: Add TRI finish interrupt for vblank drm/sun4i: Protect the TCON pixel clocks dt-bindings: display: Add Allwinner MIPI-DSI bindings drm/sun4i: Add Allwinner A31 MIPI-DSI controller support dt-bindings: vendor: Add Huarui Lighting dt-bindings: panel: Add Huarui LHR050H41 panel documentation drm/panel: Add Huarui LHR050H41 panel driver arm: dts: sun8i: a33: Add the DSI-related nodes [DO NOT MERGE] arm: dts: sun8i: bpi-m2m: Add DSI display Documentation/devicetree/bindings/display/panel/huarui,lhr050h41.txt | 19 +- Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 84 +++++- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +- arch/arm/boot/dts/sun8i-a33.dtsi | 35 ++- arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 39 +++- drivers/base/regmap/regmap-mmio.c | 24 ++- drivers/gpu/drm/panel/Kconfig | 9 +- drivers/gpu/drm/panel/Makefile | 1 +- drivers/gpu/drm/panel/panel-huarui-lhr050h41.c | 506 +++++++++++++++++++++++++++++++++- drivers/gpu/drm/sun4i/Kconfig | 10 +- drivers/gpu/drm/sun4i/Makefile | 4 +- drivers/gpu/drm/sun4i/sun4i_tcon.c | 115 ++++++- drivers/gpu/drm/sun4i/sun4i_tcon.h | 46 +++- drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c | 297 +++++++++++++++++++- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 1111 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 67 ++++- include/linux/regmap.h | 3 +- 17 files changed, 2366 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/huarui,lhr050h41.txt create mode 100644 Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt create mode 100644 drivers/gpu/drm/panel/panel-huarui-lhr050h41.c create mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dphy.c create mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c create mode 100644 drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h base-commit: 91ab883eb21325ad80f3473633f794c78ac87f51 -- git-series 0.9.1

6 19

reservation questions
by Liu, Monk 06 Mar '18

06 Mar '18

Hi Christian & Chris two question regarding resv: 1) considering below sequence: call reservation_object_add_shared_fence, now assume old->shared_count is now 3 call reservation_object_add_shared_fence, now assume old->shared_count is now 4, call reservation_object_reserve_shared, now obj->staged is new allocated, and its shared_max = 8, but not used by far. call reservation_object_add_excl_fence, it set obj->fence->shared_count to 0, and put all shared fence from obj->fence without waiting signaling. (this action looks inappropriate, I think at least before put all those shared fences we should dma_wait_fence() on them to make sure they are signaled) call reservation_object_reserve_shared, this time obj->staged isn't NULL, and it is freed (nothing bad now since obj->fence points to other place), and obj->staged set to NULL, call reservation_object_add_shared_fence, this time should going through reservation_object_add_shared_inplace, But BUG_ON(old->shared_count >= old->shared_max) will hit ! This looks a design flaw in reservation object, shouldn't we fix it ? 2) in add_excl_fence(), it simply set old->shared_count to 0, and put all shared fences of old is that correct? if excl fence is really exclusively used, why we still consider both shared fence and excl fence on wait_timeout_rcu() routine, see blew description of this routine /** * reservation_object_wait_timeout_rcu - Wait on reservation's objects * shared and/or exclusive fences. * @obj: the reservation object * @wait_all: if true, wait on all fences, else wait on just exclusive fence * @intr: if true, do interruptible wait * @timeout: timeout value in jiffies or zero to return immediately * * RETURNS * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or * greater than zer on success. */ long reservation_object_wait_timeout_rcu(struct reservation_object *obj, bool wait_all, bool intr, unsigned long timeout) thanks /Monk

4 14

[Bug 105359] kms_frontbuffer_tracking - FBC disabled
by bugzilla-daemon＠freedesktop.org 06 Mar '18

06 Mar '18

https://bugs.freedesktop.org/show_bug.cgi?id=105359 --- Comment #4 from Marta Löfstedt <marta.lofstedt(a)intel.com> --- https://patchwork.freedesktop.org/patch/208170/ This caused some discussion. I appears as if devs want a way for user space to reset the "fbc state". I am assuming this also applies for FIFO underrun caused FBC disabled. I guess that is OK, the only one calling: intel_fbc_handle_fifo_underrun_irq(dev_priv); is: void intel_cpu_fifo_underrun_irq_handler(struct drm_i915_private *dev_priv, enum pipe pipe) However, this comment in above function: /* There's no guarantee that underrun_detected won't be set to true * right after this check and before the work is scheduled, but that's * not a problem since we'll check it again under the work function * while FBC is locked. This check here is just to prevent us from * unnecessarily scheduling the work, and it relies on the fact that we * never switch underrun_detect back to false after it's true. */ so maybe not totally straight forward to implement. Also, I believe that the massive hit from "FBC disabled" on kasan and shard testlist on BAT is due to this FBC banned by FIFO underrun thing. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH] dma-buf/reservation: should keep later one in add fence(v2)
by Monk Liu 06 Mar '18

06 Mar '18

v2: still check context first to avoid warning from dma_fence_is_later apply this fix in add_shared_replace as well Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767 Signed-off-by: Monk Liu <Monk.Liu(a)amd.com> --- drivers/dma-buf/reservation.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c index 314eb10..c6e3c86 100644 --- a/drivers/dma-buf/reservation.c +++ b/drivers/dma-buf/reservation.c @@ -118,7 +118,8 @@ reservation_object_add_shared_inplace(struct reservation_object *obj, old_fence = rcu_dereference_protected(fobj->shared[i], reservation_object_held(obj)); - if (old_fence->context == fence->context) { + if (old_fence->context == fence->context && + dma_fence_is_later(fence, old_fence)) { /* memory barrier is added by write_seqcount_begin */ RCU_INIT_POINTER(fobj->shared[i], fence); write_seqcount_end(&obj->seq); @@ -179,7 +180,8 @@ reservation_object_add_shared_replace(struct reservation_object *obj, check = rcu_dereference_protected(old->shared[i], reservation_object_held(obj)); - if (check->context == fence->context || + if ((check->context == fence->context && + dma_fence_is_later(fence, check)) || dma_fence_is_signaled(check)) RCU_INIT_POINTER(fobj->shared[--k], check); else -- 2.7.4

4 6

[PATCH] drm/drm_ioctl.c: Test client capability value early when setting.
by Liviu Dudau 06 Mar '18

06 Mar '18

The drm_setclientcap() function implementing the DRM_IOCTL_SET_CLIENT_CAP ioctl expects that any capability set by the client will have a value of 1. Make the check early so that we don't have to test the value for each capability. Signed-off-by: Liviu Dudau <liviu.dudau(a)arm.com> --- drivers/gpu/drm/drm_ioctl.c | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c index af782911c505..02ffa0e8d77b 100644 --- a/drivers/gpu/drm/drm_ioctl.c +++ b/drivers/gpu/drm/drm_ioctl.c @@ -306,22 +306,19 @@ drm_setclientcap(struct drm_device *dev, void *data, struct drm_file *file_priv) { struct drm_set_client_cap *req = data; + if (req->value > 1) + return -EINVAL; + switch (req->capability) { case DRM_CLIENT_CAP_STEREO_3D: - if (req->value > 1) - return -EINVAL; file_priv->stereo_allowed = req->value; break; case DRM_CLIENT_CAP_UNIVERSAL_PLANES: - if (req->value > 1) - return -EINVAL; file_priv->universal_planes = req->value; break; case DRM_CLIENT_CAP_ATOMIC: if (!drm_core_check_feature(dev, DRIVER_ATOMIC)) return -EINVAL; - if (req->value > 1) - return -EINVAL; file_priv->atomic = req->value; file_priv->universal_planes = req->value; break; -- 2.16.2

3 5

Re: [PATCH] drm/atomic: Add new reverse iterator over all plane state
by Alex Deucher 06 Mar '18

06 Mar '18

+ dri-devel On Wed, Feb 28, 2018 at 4:33 AM, S, Shirish <Shirish.S(a)amd.com> wrote: > From: Shirish S <shirish.s(a)amd.com> > > Add reverse iterator "for_each_oldnew_plane_in_state_reverse" to > complement "for_each_oldnew_plane_in_state" way of reading plane > states. > > The plane states are required to be read in reverse order for > amdgpu, as the z order convention followed in linux is > opposite to how the planes are supposed to be presented to DC > engine, which is in common to both windows and linux. > > Signed-off-by: Shirish S <shirish.s(a)amd.com> > Signed-off-by: Pratik Vishwakarma <Pratik.Vishwakarma(a)amd.com> > --- > include/drm/drm_atomic.h | 22 ++++++++++++++++++++++ > 1 file changed, 22 insertions(+) > > diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h > index cf13842..b947930 100644 > --- a/include/drm/drm_atomic.h > +++ b/include/drm/drm_atomic.h > @@ -754,6 +754,28 @@ void drm_state_dump(struct drm_device *dev, struct drm_printer *p); > (new_plane_state) = (__state)->planes[__i].new_state, 1)) > > /** > + * for_each_oldnew_plane_in_state_reverse - iterate over all planes in an atomic > + * update in reverse order > + * @__state: &struct drm_atomic_state pointer > + * @plane: &struct drm_plane iteration cursor > + * @old_plane_state: &struct drm_plane_state iteration cursor for the old state > + * @new_plane_state: &struct drm_plane_state iteration cursor for the new state > + * @__i: int iteration cursor, for macro-internal use > + * > + * This iterates over all planes in an atomic update in reverse order, > + * tracking both old and new state. This is useful in places where the > + * state delta needs to be considered, for example in atomic check functions. > + */ > +#define for_each_oldnew_plane_in_state_reverse(__state, plane, old_plane_state, new_plane_state, __i) \ > + (for ((__i) = ((__state)->dev->mode_config.num_total_plane - 1); \ > + (__i) >= 0; \ > + (__i)--) \ > + for_each_if ((__state)->planes[__i].ptr && \ > + ((plane) = (__state)->planes[__i].ptr, \ > + (old_plane_state) = (__state)->planes[__i].old_state,\ > + (new_plane_state) = (__state)->planes[__i].new_state, 1))) > + > +/** > * for_each_old_plane_in_state - iterate over all planes in an atomic update > * @__state: &struct drm_atomic_state pointer > * @plane: &struct drm_plane iteration cursor > -- > 2.7.4 > > _______________________________________________ > amd-gfx mailing list > amd-gfx(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx

2 1

[PATCH v2 0/2] drm/panel: Add device link in drm_panel_attach()
by Jyri Sarha 06 Mar '18

06 Mar '18

The first version of the series can be found here: https://lists.freedesktop.org/archives/dri-devel/2018-February/166909.html The only change is the dev_err print in drm_panel_attach() if device_link_add() fails. The device_link_del() is still there in drm_panel_detach(), despite Lukas Wunner's comment[1]. In the usual (currently all) cases things would work perfectly without the call too, because device_links_driver_cleanup() will eventually remove all orphaned links. However, this would cause an error in the situation where a drm device would like to detach a panel but remain operational, since the drm device would be unbound for no good reason if the detached panel is later unbound. Anyway, if somebody still comes up with an argument for dropping the device_link_del() from drm_panel_detach(), I'll do it as things will normally work fine either case (drm devices don't normally detach panels and remain operational). These older comment still apply: The first patch could be squashed to second, but kept is separate since I think it is correct even without the second patch. With these patches unbinding a panel driver in use does not cause nasty backtraces and corrupted drm core structures, but instead it cleanly unbind the drm master device at the same time. The only down side (currently[2]) is that the drm device does not reprobe if the panel driver is bound again, but everything should work if the drm master driver is bound manually. Best regards, Jyri [1] https://lists.freedesktop.org/archives/dri-devel/2018-February/167047.html [2] https://lists.freedesktop.org/archives/dri-devel/2018-February/166907.html Jyri Sarha (2): drm/panel: Remove drm_panel_detach() calls from all panel drives drm/panel: Add device_link from panel device to drm device drivers/gpu/drm/drm_panel.c | 12 ++++++++++++ drivers/gpu/drm/panel/panel-innolux-p079zca.c | 1 - drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 1 - drivers/gpu/drm/panel/panel-lvds.c | 1 - drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 1 - drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 1 - drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 1 - drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 1 - drivers/gpu/drm/panel/panel-simple.c | 1 - drivers/gpu/drm/panel/panel-sitronix-st7789v.c | 1 - include/drm/drm_panel.h | 1 + 11 files changed, 13 insertions(+), 9 deletions(-) -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

5 10

[PATCH 1/5] drm/prime: fix potential race in drm_gem_map_detach
by Christian König 06 Mar '18

06 Mar '18

Unpin the GEM object only after freeing the sg table. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/drm_prime.c | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index e82a976f0fba..c38dacda6119 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -230,26 +230,26 @@ void drm_gem_map_detach(struct dma_buf *dma_buf, struct drm_prime_attachment *prime_attach = attach->priv; struct drm_gem_object *obj = dma_buf->priv; struct drm_device *dev = obj->dev; - struct sg_table *sgt; - if (dev->driver->gem_prime_unpin) - dev->driver->gem_prime_unpin(obj); + if (prime_attach) { + struct sg_table *sgt = prime_attach->sgt; - if (!prime_attach) - return; - - sgt = prime_attach->sgt; - if (sgt) { - if (prime_attach->dir != DMA_NONE) - dma_unmap_sg_attrs(attach->dev, sgt->sgl, sgt->nents, - prime_attach->dir, - DMA_ATTR_SKIP_CPU_SYNC); - sg_free_table(sgt); + if (sgt) { + if (prime_attach->dir != DMA_NONE) + dma_unmap_sg_attrs(attach->dev, sgt->sgl, + sgt->nents, + prime_attach->dir, + DMA_ATTR_SKIP_CPU_SYNC); + sg_free_table(sgt); + } + + kfree(sgt); + kfree(prime_attach); + attach->priv = NULL; } - kfree(sgt); - kfree(prime_attach); - attach->priv = NULL; + if (dev->driver->gem_prime_unpin) + dev->driver->gem_prime_unpin(obj); } EXPORT_SYMBOL(drm_gem_map_detach); -- 2.14.1

8 21

[PATCH 0/9] drm/xen-front: Add support for Xen PV display frontend
by Oleksandr Andrushchenko 06 Mar '18

06 Mar '18

From: Oleksandr Andrushchenko <oleksandr_andrushchenko(a)epam.com> Hello! This patch series adds support for Xen [1] para-virtualized frontend display driver. It implements the protocol from include/xen/interface/io/displif.h [2]. Accompanying backend [3] is implemented as a user-space application and its helper library [4], capable of running as a Weston client or DRM master. Configuration of both backend and frontend is done via Xen guest domain configuration options [5]. ******************************************************************************* * Driver limitations ******************************************************************************* 1. Configuration options 1.1 (contiguous display buffers) and 2 (backend allocated buffers) below are not supported at the same time. 2. Only primary plane without additional properties is supported. 3. Only one video mode supported which resolution is configured via XenStore. 4. All CRTCs operate at fixed frequency of 60Hz. ******************************************************************************* * Driver modes of operation in terms of display buffers used ******************************************************************************* Depending on the requirements for the para-virtualized environment, namely requirements dictated by the accompanying DRM/(v)GPU drivers running in both host and guest environments, number of operating modes of para-virtualized display driver are supported: - display buffers can be allocated by either frontend driver or backend - display buffers can be allocated to be contiguous in memory or not Note! Frontend driver itself has no dependency on contiguous memory for its operation. ******************************************************************************* * 1. Buffers allocated by the frontend driver. ******************************************************************************* The below modes of operation are configured at compile-time via frontend driver's kernel configuration. 1.1. Front driver configured to use GEM CMA helpers This use-case is useful when used with accompanying DRM/vGPU driver in guest domain which was designed to only work with contiguous buffers, e.g. DRM driver based on GEM CMA helpers: such drivers can only import contiguous PRIME buffers, thus requiring frontend driver to provide such. In order to implement this mode of operation para-virtualized frontend driver can be configured to use GEM CMA helpers. 1.2. Front driver doesn't use GEM CMA If accompanying drivers can cope with non-contiguous memory then, to lower pressure on CMA subsystem of the kernel, driver can allocate buffers from system memory. Note! If used with accompanying DRM/(v)GPU drivers this mode of operation may require IOMMU support on the platform, so accompanying DRM/vGPU hardware can still reach display buffer memory while importing PRIME buffers from the frontend driver. ******************************************************************************* * 2. Buffers allocated by the backend ******************************************************************************* This mode of operation is run-time configured via guest domain configuration through XenStore entries. For systems which do not provide IOMMU support, but having specific requirements for display buffers it is possible to allocate such buffers at backend side and share those with the frontend. For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting physically contiguous memory, this allows implementing zero-copying use-cases. I would like to thank at least, but not at last the following people/communities who helped this driver to happen ;) 1. My team at EPAM for continuous support 2. Xen community for answering tons of questions on different modes of operation of the driver with respect to virtualized environment. 3. Rob Clark for "GEM allocation for para-virtualized DRM driver" [6] 4. Maarten Lankhorst for "Atomic driver and old remove FB behavior" [7] 5. Ville Syrjälä for "Questions on page flips and atomic modeset" [8] Thank you, Oleksandr Andrushchenko P.S. There are two dependencies for this driver limiting some of the use-cases which are on review now: 1. "drm/simple_kms_helper: Add {enable|disable}_vblank callback support" [9] 2. "drm/simple_kms_helper: Fix NULL pointer dereference with no active CRTC" [10] [1] https://wiki.xen.org/wiki/Paravirtualization_(PV)#PV_IO_Drivers [2] https://elixir.bootlin.com/linux/v4.16-rc2/source/include/xen/interface/io/… [3] https://github.com/xen-troops/displ_be [4] https://github.com/xen-troops/libxenbe [5] https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/man/xl.cfg.pod.5.in… [6] https://lists.freedesktop.org/archives/dri-devel/2017-March/136038.html [7] https://www.spinics.net/lists/dri-devel/msg164102.html [8] https://www.spinics.net/lists/dri-devel/msg164463.html [9] https://patchwork.freedesktop.org/series/38073/ [10] https://patchwork.freedesktop.org/series/38139/ Oleksandr Andrushchenko (9): drm/xen-front: Introduce Xen para-virtualized frontend driver drm/xen-front: Implement Xen bus state handling drm/xen-front: Read driver configuration from Xen store drm/xen-front: Implement Xen event channel handling drm/xen-front: Implement handling of shared display buffers drm/xen-front: Introduce DRM/KMS virtual display driver drm/xen-front: Implement KMS/connector handling drm/xen-front: Implement GEM operations drm/xen-front: Implement communication with backend drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/xen/Kconfig | 30 ++ drivers/gpu/drm/xen/Makefile | 17 + drivers/gpu/drm/xen/xen_drm_front.c | 712 ++++++++++++++++++++++++++++ drivers/gpu/drm/xen/xen_drm_front.h | 154 ++++++ drivers/gpu/drm/xen/xen_drm_front_cfg.c | 84 ++++ drivers/gpu/drm/xen/xen_drm_front_cfg.h | 45 ++ drivers/gpu/drm/xen/xen_drm_front_conn.c | 125 +++++ drivers/gpu/drm/xen/xen_drm_front_conn.h | 35 ++ drivers/gpu/drm/xen/xen_drm_front_drv.c | 294 ++++++++++++ drivers/gpu/drm/xen/xen_drm_front_drv.h | 73 +++ drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 399 ++++++++++++++++ drivers/gpu/drm/xen/xen_drm_front_evtchnl.h | 89 ++++ drivers/gpu/drm/xen/xen_drm_front_gem.c | 360 ++++++++++++++ drivers/gpu/drm/xen/xen_drm_front_gem.h | 46 ++ drivers/gpu/drm/xen/xen_drm_front_gem_cma.c | 93 ++++ drivers/gpu/drm/xen/xen_drm_front_kms.c | 299 ++++++++++++ drivers/gpu/drm/xen/xen_drm_front_kms.h | 30 ++ drivers/gpu/drm/xen/xen_drm_front_shbuf.c | 430 +++++++++++++++++ drivers/gpu/drm/xen/xen_drm_front_shbuf.h | 80 ++++ 21 files changed, 3398 insertions(+) create mode 100644 drivers/gpu/drm/xen/Kconfig create mode 100644 drivers/gpu/drm/xen/Makefile create mode 100644 drivers/gpu/drm/xen/xen_drm_front.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front.h create mode 100644 drivers/gpu/drm/xen/xen_drm_front_cfg.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front_cfg.h create mode 100644 drivers/gpu/drm/xen/xen_drm_front_conn.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front_conn.h create mode 100644 drivers/gpu/drm/xen/xen_drm_front_drv.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front_drv.h create mode 100644 drivers/gpu/drm/xen/xen_drm_front_evtchnl.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front_evtchnl.h create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem.h create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem_cma.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front_kms.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front_kms.h create mode 100644 drivers/gpu/drm/xen/xen_drm_front_shbuf.c create mode 100644 drivers/gpu/drm/xen/xen_drm_front_shbuf.h -- 2.7.4

9 62

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2018