Re: [PATCH] drm: fix spelling mistake: "committing"
On Wed, Apr 12, 2017 at 05:27:22PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in DRM_DEBUG_ATOMIC debug message
>
> Signed-off-by: Colin Ian King
Applied for 4.13 (4.12 feature cutoff is already gone).
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_atomic.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index f32506a7c1d6..30229ab719c0 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1618,7 +1618,7 @@ int drm_atomic_commit(struct drm_atomic_state *state)
> if (ret)
> return ret;
>
> - DRM_DEBUG_ATOMIC("commiting %p\n", state);
> + DRM_DEBUG_ATOMIC("committing %p\n", state);
>
> return config->funcs->atomic_commit(state->dev, state, false);
> }
> @@ -1647,7 +1647,7 @@ int drm_atomic_nonblocking_commit(struct
> drm_atomic_state *state)
> if (ret)
> return ret;
>
> - DRM_DEBUG_ATOMIC("commiting %p nonblocking\n", state);
> + DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state);
>
> return config->funcs->atomic_commit(state->dev, state, true);
> }
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm/etnaviv: Reuse dma_fence_release.
On Wed, Apr 12, 2017 at 12:12:01PM -0700, Eric Anholt wrote:
> If we follow the typical pattern of the base class being the first
> member, we can use the default dma_fence_free function.
>
> Signed-off-by: Eric Anholt
On 3&4: Reviewed-by: Daniel Vetter
> Cc: Lucas Stach
> Cc: Russell King
> Cc: Christian Gmeiner
> Cc: etna...@lists.freedesktop.org
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index da48819ff2e6..0d26ca56e94b 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -998,8 +998,8 @@ static void hangcheck_disable(struct etnaviv_gpu *gpu)
>
> /* fence object management */
> struct etnaviv_fence {
> - struct etnaviv_gpu *gpu;
> struct dma_fence base;
> + struct etnaviv_gpu *gpu;
> };
>
> static inline struct etnaviv_fence *to_etnaviv_fence(struct dma_fence *fence)
> @@ -1031,20 +1031,13 @@ static bool etnaviv_fence_signaled(struct dma_fence
> *fence)
> return fence_completed(f->gpu, f->base.seqno);
> }
>
> -static void etnaviv_fence_release(struct dma_fence *fence)
> -{
> - struct etnaviv_fence *f = to_etnaviv_fence(fence);
> -
> - kfree_rcu(f, base.rcu);
> -}
> -
> static const struct dma_fence_ops etnaviv_fence_ops = {
> .get_driver_name = etnaviv_fence_get_driver_name,
> .get_timeline_name = etnaviv_fence_get_timeline_name,
> .enable_signaling = etnaviv_fence_enable_signaling,
> .signaled = etnaviv_fence_signaled,
> .wait = dma_fence_default_wait,
> - .release = etnaviv_fence_release,
> + .release = dma_fence_free,
> };
>
> static struct dma_fence *etnaviv_gpu_fence_alloc(struct etnaviv_gpu *gpu)
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] drm/vc4: Expose dma-buf fences for V3D rendering.
On Wed, Apr 12, 2017 at 12:12:02PM -0700, Eric Anholt wrote:
> This is needed for proper synchronization with display on another DRM
> device (pl111 or tinydrm) with buffers produced by vc4 V3D. Fixes the
> new igt vc4_dmabuf_poll testcase, and rendering of one of the glmark2
> desktop tests on pl111+vc4.
>
> This doesn't yet introduce waits on other device's fences before vc4's
> rendering/display, because I don't have testcases for them.
>
> v2: Reuse dma_fence_free(), retitle commit message to clarify that
> it's not a full dma-buf fencing implementation yet.
>
> Signed-off-by: Eric Anholt
Double-checked a few things in your ww_mutex scheme, seems are correct.
And testing with CONFIG_DEBUG_WW_MUTEX_SLOWPATH should catch any kind of
fumbles in your error paths. I didnt do a full review, so just
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/vc4/Makefile| 1 +
> drivers/gpu/drm/vc4/vc4_bo.c| 37 ++-
> drivers/gpu/drm/vc4/vc4_drv.c | 3 +-
> drivers/gpu/drm/vc4/vc4_drv.h | 30 +
> drivers/gpu/drm/vc4/vc4_fence.c | 56 +
> drivers/gpu/drm/vc4/vc4_gem.c | 136
> +++-
> drivers/gpu/drm/vc4/vc4_irq.c | 4 ++
> 7 files changed, 262 insertions(+), 5 deletions(-)
> create mode 100644 drivers/gpu/drm/vc4/vc4_fence.c
>
> diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
> index 61f45d122bd0..ab687fba4916 100644
> --- a/drivers/gpu/drm/vc4/Makefile
> +++ b/drivers/gpu/drm/vc4/Makefile
> @@ -9,6 +9,7 @@ vc4-y := \
> vc4_drv.o \
> vc4_dpi.o \
> vc4_dsi.o \
> + vc4_fence.o \
> vc4_kms.o \
> vc4_gem.o \
> vc4_hdmi.o \
> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> index af29432a6471..80b2f9e55c5c 100644
> --- a/drivers/gpu/drm/vc4/vc4_bo.c
> +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> @@ -19,6 +19,8 @@
> * rendering can return quickly.
> */
>
> +#include
> +
> #include "vc4_drv.h"
> #include "uapi/drm/vc4_drm.h"
>
> @@ -88,6 +90,10 @@ static void vc4_bo_destroy(struct vc4_bo *bo)
>
> vc4->bo_stats.num_allocated--;
> vc4->bo_stats.size_allocated -= obj->size;
> +
> + if (bo->resv == &bo->_resv)
> + reservation_object_fini(bo->resv);
> +
> drm_gem_cma_free_object(obj);
> }
>
> @@ -244,8 +250,12 @@ struct vc4_bo *vc4_bo_create(struct drm_device *dev,
> size_t unaligned_size,
> return ERR_PTR(-ENOMEM);
> }
> }
> + bo = to_vc4_bo(&cma_obj->base);
>
> - return to_vc4_bo(&cma_obj->base);
> + bo->resv = &bo->_resv;
> + reservation_object_init(bo->resv);
> +
> + return bo;
> }
>
> int vc4_dumb_create(struct drm_file *file_priv,
> @@ -369,6 +379,13 @@ static void vc4_bo_cache_time_timer(unsigned long data)
> schedule_work(&vc4->bo_cache.time_work);
> }
>
> +struct reservation_object *vc4_prime_res_obj(struct drm_gem_object *obj)
> +{
> + struct vc4_bo *bo = to_vc4_bo(obj);
> +
> + return bo->resv;
> +}
> +
> struct dma_buf *
> vc4_prime_export(struct drm_device *dev, struct drm_gem_object *obj, int
> flags)
> {
> @@ -440,6 +457,24 @@ void *vc4_prime_vmap(struct drm_gem_object *obj)
> return drm_gem_cma_prime_vmap(obj);
> }
>
> +struct drm_gem_object *
> +vc4_prime_import_sg_table(struct drm_device *dev,
> + struct dma_buf_attachment *attach,
> + struct sg_table *sgt)
> +{
> + struct drm_gem_object *obj;
> + struct vc4_bo *bo;
> +
> + obj = drm_gem_cma_prime_import_sg_table(dev, attach, sgt);
> + if (IS_ERR(obj))
> + return obj;
> +
> + bo = to_vc4_bo(obj);
> + bo->resv = attach->dmabuf->resv;
> +
> + return obj;
> +}
> +
> int vc4_create_bo_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file_priv)
> {
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 61e674baf3a6..92fb9a41fe7c 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -168,8 +168,9 @@ static struct drm_driver vc4_drm_driver = {
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> .gem_prime_import = drm_gem_prime_import,
> .gem_prime_export = vc4_prime_export,
> + .gem_prime_res_obj = vc4_prime_res_obj,
> .gem_prime_get_sg_table = drm_gem_cma_prime_get_sg_table,
> - .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table,
> + .gem_prime_import_sg_table = vc4_prime_import_sg_table,
> .gem_prime_vmap = vc4_prime_vmap,
> .gem_prime_vunmap = drm_gem_cma_prime_vunmap,
> .gem_prime_mmap = vc4_prime_mmap,
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index dea304966e65..08d5c2213c80 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -8,7 +8,9 @@
>
> #include "drmP.h"
> #include "drm_gem_cma_helper.h"
> +#include "d
Re: [PATCH] drm/exynos/dsi: fix bridge_node DT parsing
2017년 04월 12일 16:22에 Andrzej Hajda 이(가) 쓴 글:
> DSIM uses MIC bridge which is between DECON and DSIM, so the driver
> should expect bridge node on input side.
Confirmed and merged.
Thanks,
Inki Dae
>
> Fixes: 86418f9 ("drm: convert drivers to use of_graph_get_remote_node")
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index dcb50d4d..3ae459f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1659,7 +1659,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
>
> of_node_put(ep);
>
> - dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_OUT, 0);
> + dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0);
> if (!dsi->bridge_node)
> return -EINVAL;
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/doc: Fix missing @ctx documentation
Forgot to add this :(
Fixes: 1931529448bc ("drm: Add acquire ctx parameter to ->plane_disable")
Cc: Harry Wentland
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index b84a295230fc..9854a503e201 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -381,6 +381,7 @@ EXPORT_SYMBOL(drm_primary_helper_update);
/**
* drm_primary_helper_disable() - Helper for primary plane disable
* @plane: plane to disable
+ * @ctx: lock acquire context, not used here
*
* Provides a default plane disable handler for primary planes. This is
handler
* is called in response to a userspace SetPlane operation on the plane with a
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Fix missing @ctx documentation
On 04/13/2017 09:40 AM, Daniel Vetter wrote:
> Forgot to add this :(
>
> Fixes: 1931529448bc ("drm: Add acquire ctx parameter to ->plane_disable")
> Cc: Harry Wentland
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_plane_helper.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_plane_helper.c
> b/drivers/gpu/drm/drm_plane_helper.c
> index b84a295230fc..9854a503e201 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -381,6 +381,7 @@ EXPORT_SYMBOL(drm_primary_helper_update);
> /**
> * drm_primary_helper_disable() - Helper for primary plane disable
> * @plane: plane to disable
> + * @ctx: lock acquire context, not used here
> *
> * Provides a default plane disable handler for primary planes. This is
> handler
> * is called in response to a userspace SetPlane operation on the plane with
> a
>
Reviewed-by: Neil Armstrong
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RfC PATCH] drm: fourcc byteorder: brings header file comments in line with reality.
On Tue, 11 Apr 2017 13:23:53 +0200 Gerd Hoffmann wrote: > Hi, > > > > Just let know what you need tested, I should be able to turn it around > > > within a couple of days. > > > > That's part of my problem. I don't really know what should be tested. > > What do people do with their BE machines that we should avoid breaking? > > For the virtual machine use case the bar is pretty low, it's mostly > about a graphical server console. Anaconda installer. Gnome desktop > with browser and standard xorg (xterm) + gtk apps. No heavy OpenGL > stuff. No hardware acceleration, so if opengl is used then it'll be > llvmpipe. > > Right now Xorg is important. Not sure whenever wayland ever will be, > possibly the ppc64 -> ppc64le switch goes faster than the xorg -> > wayland switch. Hi, IMHO you can ignore Wayland for now I suppose, I just wanted to point out that we have similar problems there and whatever you do with the DRM format codes will affect things on Wayland too. Once you get things hashed out on an X.org based stack, we can look what it means for Wayland software. After all, BE users are scarce and allegedly favouring old software to avoid breakage; Wayland is new, and Wayland compositors still "rare", so the intersection of people using both BE and Wayland and relying on it to work is... minuscule? insignificant? I don't mean to belittle people that use Wayland on BE, but by that one bug report EGL is and probably has been broken, and it's unclear if anything has ever worked. Thanks, pq pgpngHzov5GC7.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Fix missing @ctx documentation
On Thu, Apr 13, 2017 at 09:43:07AM +0200, Neil Armstrong wrote:
> On 04/13/2017 09:40 AM, Daniel Vetter wrote:
> > Forgot to add this :(
> >
> > Fixes: 1931529448bc ("drm: Add acquire ctx parameter to ->plane_disable")
> > Cc: Harry Wentland
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_plane_helper.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/drm_plane_helper.c
> > b/drivers/gpu/drm/drm_plane_helper.c
> > index b84a295230fc..9854a503e201 100644
> > --- a/drivers/gpu/drm/drm_plane_helper.c
> > +++ b/drivers/gpu/drm/drm_plane_helper.c
> > @@ -381,6 +381,7 @@ EXPORT_SYMBOL(drm_primary_helper_update);
> > /**
> > * drm_primary_helper_disable() - Helper for primary plane disable
> > * @plane: plane to disable
> > + * @ctx: lock acquire context, not used here
> > *
> > * Provides a default plane disable handler for primary planes. This is
> > handler
> > * is called in response to a userspace SetPlane operation on the plane
> > with a
> >
>
> Reviewed-by: Neil Armstrong
Thanks for your review, applied to drm-misc-next.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: sii902x: Add missing \n to the end of some dev_err messages
On 11.04.2017 04:22, Liu Ying wrote: > Trivial fix. > Some dev_err messages in this driver are missing \n, so add them. > > Signed-off-by: Liu Ying Reviewed-by: Andrzej Hajda -- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/9] drm/exynos/decon5433: kill BIT_IRQS_ENABLED flag
2017년 04월 05일 16:28에 Andrzej Hajda 이(가) 쓴 글:
> Since DECON uses enable_irq/disable_irq to full control IRQs,
> there is no point in having flags to trace it separately.
> As a bonus condition for software trigger becomes always true,
> so it can be removed.
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index 5bdf1a0..dc2e69a 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -49,7 +49,6 @@ static const char * const decon_clks_name[] = {
>
> enum decon_flag_bits {
> BIT_CLKS_ENABLED,
> - BIT_IRQS_ENABLED,
> BIT_WIN_UPDATED,
> BIT_SUSPENDED
> };
> @@ -112,8 +111,6 @@ static int decon_enable_vblank(struct exynos_drm_crtc
> *crtc)
> if (!(ctx->out_type & I80_HW_TRG))
> enable_irq(ctx->te_irq);
>
> - set_bit(BIT_IRQS_ENABLED, &ctx->flags);
> -
> return 0;
> }
>
> @@ -121,7 +118,6 @@ static void decon_disable_vblank(struct exynos_drm_crtc
> *crtc)
> {
> struct decon_context *ctx = crtc->ctx;
>
> - clear_bit(BIT_IRQS_ENABLED, &ctx->flags);
> if (test_bit(BIT_SUSPENDED, &ctx->flags))
> return;
>
> @@ -536,9 +532,7 @@ static irqreturn_t decon_te_irq_handler(int irq, void
> *dev_id)
> (ctx->out_type & I80_HW_TRG))
> return IRQ_HANDLED;
>
> - if (test_and_clear_bit(BIT_WIN_UPDATED, &ctx->flags) ||
> - test_bit(BIT_IRQS_ENABLED, &ctx->flags))
> - decon_set_bits(ctx, DECON_TRIGCON, TRIGCON_SWTRIGCMD, ~0);
> + decon_set_bits(ctx, DECON_TRIGCON, TRIGCON_SWTRIGCMD, ~0);
This code would incur mulfunction if now decon driver uses sw trigger mode.
The panel device on TM2 and TM2E boards supports ALPM mode which makes Panel
device to be keeped on with low power even ARM, crtc and encoder devices are
off.
In this case, even if decon device is off te interrupt could happen and writing
to decon register could be tried.
Thanks,
Inki Dae
>
> return IRQ_HANDLED;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH v3 10/10] drm/nouveau: Enable stereoscopic 3D output over HDMI
On 04/13/2017 01:22 AM, Alastair Bridgewater wrote: On Tue, Apr 11, 2017 at 1:32 PM, Ilia Mirkin mailto:imir...@alum.mit.edu>> wrote: On Tue, Apr 11, 2017 at 1:11 PM, Alastair Bridgewater mailto:alastair.bridgewa...@gmail.com>> wrote: > + /* HDMI 3D support */ > + if ((disp->disp.oclass >= NV50_DISP) You probably meant G82_DISP. Although I don't know if there were any G80's with DP or HDMI. Either way, all that logic is in hdmig84.c (and newer), so ... :) Having taken a closer look at the lower level code, I agree. It should be G82_DISP. Will correct in the v4 patch series (if there ends up being a v4 patch series). Good catch, and thank you! Hey Alastair, Firstly, a minor nit-pick: I modified some of the commit titles a little. For any changes under nvkm/, use "drm/nouveau/[SUBDEV][/CHIPSET(s)]:" as a prefix instead of just drm/nouveau. Second, and more importantly, this series looks really good to me. Nice work! I've given it a quick test on a 3D-capable TV I have, and the TV definitely thinks it's getting a 3D mode :) My glasses are flat, so couldn't test any further. Regardless, I've fixed up the suggestion that Ilia made and merged the series. If there's any other changes to come, there's plenty of time to squash those in before the next merge window. Thanks again, Ben. -- Alastair Bridgewater ___ Nouveau mailing list nouv...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid
On 12/04/17 17:04, Hans Verkuil wrote: >> So is some other driver supporting this already? Or is the omap4 the >> first platform you're trying this on? > > No, there are quite a few CEC drivers by now, but typically the CEC block is > a totally independent IP block with its own power, irq, etc. The omap4 is by > far > the most complex one to set up with various GPIO pins, interrupts, regulators, > etc. to deal with. > > Normally it takes about 2 days to make a new CEC driver, but the omap4 is much > more work :-( Ok. I mentioned the omapdrm restructuring that we've planned to do, I think after that this will be easier to implement in a nice way. For now, I think more or less what you have now is an acceptable solution. We can hack the tpd12s015 to keep the level shifter always enabled, and, afaics, everything else can be handled inside the hdmi4 driver, right? Generally speaking, what are the "dependencies" for CEC? It needs to access EDID? Does CEC care about HPD? Does it care if the cable is connected or not? For Panda, the level shifter of tpd12s015 is obviously one hard dendency. Is there anything else CEC needs to access or control (besides the CEC IP itself)? Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/9] drm/exynos/decon5433: kill BIT_IRQS_ENABLED flag
On 13.04.2017 10:33, Inki Dae wrote:
>
> 2017년 04월 05일 16:28에 Andrzej Hajda 이(가) 쓴 글:
>> Since DECON uses enable_irq/disable_irq to full control IRQs,
>> there is no point in having flags to trace it separately.
>> As a bonus condition for software trigger becomes always true,
>> so it can be removed.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 8 +---
>> 1 file changed, 1 insertion(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> index 5bdf1a0..dc2e69a 100644
>> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
>> @@ -49,7 +49,6 @@ static const char * const decon_clks_name[] = {
>>
>> enum decon_flag_bits {
>> BIT_CLKS_ENABLED,
>> -BIT_IRQS_ENABLED,
>> BIT_WIN_UPDATED,
>> BIT_SUSPENDED
>> };
>> @@ -112,8 +111,6 @@ static int decon_enable_vblank(struct exynos_drm_crtc
>> *crtc)
>> if (!(ctx->out_type & I80_HW_TRG))
>> enable_irq(ctx->te_irq);
>>
>> -set_bit(BIT_IRQS_ENABLED, &ctx->flags);
>> -
>> return 0;
>> }
>>
>> @@ -121,7 +118,6 @@ static void decon_disable_vblank(struct exynos_drm_crtc
>> *crtc)
>> {
>> struct decon_context *ctx = crtc->ctx;
>>
>> -clear_bit(BIT_IRQS_ENABLED, &ctx->flags);
>> if (test_bit(BIT_SUSPENDED, &ctx->flags))
>> return;
>>
>> @@ -536,9 +532,7 @@ static irqreturn_t decon_te_irq_handler(int irq, void
>> *dev_id)
>> (ctx->out_type & I80_HW_TRG))
>> return IRQ_HANDLED;
>>
>> -if (test_and_clear_bit(BIT_WIN_UPDATED, &ctx->flags) ||
>> -test_bit(BIT_IRQS_ENABLED, &ctx->flags))
>> -decon_set_bits(ctx, DECON_TRIGCON, TRIGCON_SWTRIGCMD, ~0);
>> +decon_set_bits(ctx, DECON_TRIGCON, TRIGCON_SWTRIGCMD, ~0);
> This code would incur mulfunction if now decon driver uses sw trigger mode.
> The panel device on TM2 and TM2E boards supports ALPM mode which makes Panel
> device to be keeped on with low power even ARM, crtc and encoder devices are
> off.
> In this case, even if decon device is off te interrupt could happen and
> writing to decon register could be tried.
As commit message explains it should not happen because of precise
control of irqs enablement.
More precisely patch 4 prevents it - te irq is disabled by
decon_disable_vblank, and synchronized (ie ensured that there are no
pending irqs) in decon_disable.
Regards
Andrzej
>
> Thanks,
> Inki Dae
>
>>
>> return IRQ_HANDLED;
>> }
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings (v4.11-rc6-1945-g6184edce6665)
drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings (v4.11-rc6-1945-g6184edce6665) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1945-g6184edce6665/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1945-g6184edce6665 Git Commit: 6184edce6665aee9c9131149a7b9314a1313eaf9 Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Built: 4 unique architectures Build Failure Detected: x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig+CONFIG_OF=n: FAIL Warnings Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) defconfig+CONFIG_KASAN=y: 4 warnings arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: 4 warnings multi_v7_defconfig+CONFIG_ARM_LPAE=y: 4 warnings multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 4 warnings multi_v7_defconfig+CONFIG_EFI=y: 4 warnings multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 4 warnings multi_v7_defconfig+CONFIG_LKDTM=y: 4 warnings multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 4 warnings multi_v7_defconfig+CONFIG_SMP=n: 4 warnings multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 4 warnings x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) defconfig+CONFIG_KASAN=y: 5 warnings Warnings summary: 9 arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI 9 arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI 9 arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI 9 arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP 1 net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 bytes is larger than 2048 bytes [-Wframe-larger-than=] Detailed per-defconfig build reports: acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches allmodconfig (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches allmodconfig (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches allmodconfig+CONFIG_OF=n (x86) — FAIL, 0 errors, 0 warnings, 0 section mismatches allnoconfig (x86) — PASS, 0 errors, 0 warnings, 0 section mismatches allnoconfig (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches allnoconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches allnoconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches am200epdkit_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches ar7_defconfig (mips) — PASS, 0 errors, 0 warnings, 0 section mismatches aspeed_g4_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches
Re: [RFC PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid
On 04/13/2017 10:43 AM, Tomi Valkeinen wrote: > On 12/04/17 17:04, Hans Verkuil wrote: > >>> So is some other driver supporting this already? Or is the omap4 the >>> first platform you're trying this on? >> >> No, there are quite a few CEC drivers by now, but typically the CEC block is >> a totally independent IP block with its own power, irq, etc. The omap4 is by >> far >> the most complex one to set up with various GPIO pins, interrupts, >> regulators, >> etc. to deal with. >> >> Normally it takes about 2 days to make a new CEC driver, but the omap4 is >> much >> more work :-( > > Ok. > > I mentioned the omapdrm restructuring that we've planned to do, I think > after that this will be easier to implement in a nice way. > > For now, I think more or less what you have now is an acceptable > solution. We can hack the tpd12s015 to keep the level shifter always > enabled, and, afaics, everything else can be handled inside the hdmi4 > driver, right? Right. > Generally speaking, what are the "dependencies" for CEC? It needs to > access EDID? Does CEC care about HPD? Does it care if the cable is > connected or not? For Panda, the level shifter of tpd12s015 is obviously > one hard dendency. > > Is there anything else CEC needs to access or control (besides the CEC > IP itself)? The CEC framework needs to be informed about the physical address contained in the EDID (part of the CEA-861 block). And when the HPD goes down it needs to be informed as well (same call, but with CEC_PHYS_ADDR_INVALID as argument). And it needs to stay powered up even if the HPD is down. That's all. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4.1 01/9] drm/atomic: Handle aspect ratio and scaling mode in core, v2.
This is required to for i915 to convert connector properties to atomic.
Changes since v1:
- Add docbook info. (danvet)
- Change picture_aspect_ratio to enum hdmi_picture_aspect.
Signed-off-by: Maarten Lankhorst
Cc: dri-devel@lists.freedesktop.org
Acked-by: Dave Airlie
---
drivers/gpu/drm/drm_atomic.c | 8
include/drm/drm_connector.h | 16
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 30229ab719c0..25ea6f797a54 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1123,6 +1123,10 @@ int drm_atomic_connector_set_property(struct
drm_connector *connector,
*/
if (state->link_status != DRM_LINK_STATUS_GOOD)
state->link_status = val;
+ } else if (property == config->aspect_ratio_property) {
+ state->picture_aspect_ratio = val;
+ } else if (property == config->scaling_mode_property) {
+ state->scaling_mode = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -1199,6 +1203,10 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = state->tv.hue;
} else if (property == config->link_status_property) {
*val = state->link_status;
+ } else if (property == config->aspect_ratio_property) {
+ *val = state->picture_aspect_ratio;
+ } else if (property == config->scaling_mode_property) {
+ *val = state->scaling_mode;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 4eeda120e46d..5b50bc2db6fb 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -25,6 +25,7 @@
#include
#include
+#include
#include
#include
@@ -326,6 +327,21 @@ struct drm_connector_state {
struct drm_atomic_state *state;
struct drm_tv_connector_state tv;
+
+ /**
+* @picture_aspect_ratio: Connector property to control the
+* HDMI infoframe aspect ratio setting.
+*
+* The DRM_MODE_PICTURE_ASPECT_* values much match the
+* values for &enum hdmi_picture_aspect
+*/
+ enum hdmi_picture_aspect picture_aspect_ratio;
+
+ /**
+* @scaling_mode: Connector property to control the
+* upscaling, mostly used for built-in panels.
+*/
+ unsigned int scaling_mode;
};
/**
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 87738] [OpenCL] Please add Image support
https://bugs.freedesktop.org/show_bug.cgi?id=87738 --- Comment #1 from Antonio Ospite --- Hi, I still get this when running darktable with mesa 17: [opencl_init] discarding device 0 `AMD REDWOOD (DRM 2.48.0 / 4.9.0-2-amd64, LLVM 4.0.0)' due to missing image support. Is it the driver that lack support for that functionality or is it rather a limitation of the device itself? My device is an "ATI Radeon HD 5670". Thanks, Antonio -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/3] encoder-tpd12s015: keep the ls_oe_gpio on while the phys_addr is valid
On 13/04/17 12:12, Hans Verkuil wrote: >> Is there anything else CEC needs to access or control (besides the CEC >> IP itself)? > > The CEC framework needs to be informed about the physical address contained > in the EDID (part of the CEA-861 block). And when the HPD goes down it needs > to be informed as well (same call, but with CEC_PHYS_ADDR_INVALID as > argument). Ah, hmm... And currently that's (kind of) handled in hdmi_power_off_full() by setting CEC_PHYS_ADDR_INVALID? That's not the same thing as HPD off, though, but maybe it's enough (for now). Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/bridge: sii902x: Add missing \n to the end of some dev_err messages
On 13.04.2017 10:20, Andrzej Hajda wrote: > On 11.04.2017 04:22, Liu Ying wrote: >> Trivial fix. >> Some dev_err messages in this driver are missing \n, so add them. >> >> Signed-off-by: Liu Ying > Reviewed-by: Andrzej Hajda > > -- > Regards > Andrzej Queued to drm-misc-next. -- Regards Andrzej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm:drm-syncobj-sem 3/8] drivers/dma-buf/sync_file.c:36:1-3: WARNING: PTR_ERR_OR_ZERO can be used
tree: git://people.freedesktop.org/~airlied/linux.git drm-syncobj-sem head: faf022804be516663a33f620536b006a56d59ee4 commit: 8281fe367426f82485f68767c5c8c7106685e9a9 [3/8] sync_file: split out fence_file base class from sync_file. coccinelle warnings: (new ones prefixed by >>) >> drivers/dma-buf/sync_file.c:36:1-3: WARNING: PTR_ERR_OR_ZERO can be used Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] sync_file: fix ptr_ret.cocci warnings
drivers/dma-buf/sync_file.c:36:1-3: WARNING: PTR_ERR_OR_ZERO can be used
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Generated by: scripts/coccinelle/api/ptr_ret.cocci
Signed-off-by: Fengguang Wu
---
sync_file.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -33,9 +33,7 @@ static int fence_file_init(struct fence_
{
fence_file->file = anon_inode_getfile("fence_file", fops,
fence_file, 0);
- if (IS_ERR(fence_file->file))
- return PTR_ERR(fence_file->file);
- return 0;
+ return PTR_ERR_OR_ZERO(fence_file->file);
}
static struct sync_file *sync_file_alloc(void)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!
https://bugs.freedesktop.org/show_bug.cgi?id=100443 --- Comment #4 from taij...@posteo.de --- Created attachment 130826 --> https://bugs.freedesktop.org/attachment.cgi?id=130826&action=edit relevant dmesg output I have a similar problem on my new notebook. System: Arch Linux - Kernel 4.11-rc6 Intel i7-7700HQ AMD RX470 dGPU dmesg, lshw, and lspci outputs are attached. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!
https://bugs.freedesktop.org/show_bug.cgi?id=100443 --- Comment #5 from taij...@posteo.de --- Created attachment 130827 --> https://bugs.freedesktop.org/attachment.cgi?id=130827&action=edit lshw output reference in comment 4 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!
https://bugs.freedesktop.org/show_bug.cgi?id=100443 --- Comment #6 from taij...@posteo.de --- Created attachment 130828 --> https://bugs.freedesktop.org/attachment.cgi?id=130828&action=edit lspci output referenced above -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 03/14] vb2: Move cache synchronisation from buffer done to dqbuf handler
The cache synchronisation may be a time consuming operation and thus not
best performed in an interrupt which is a typical context for
vb2_buffer_done() calls. This may consume up to tens of ms on some
machines, depending on the buffer size.
Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
---
drivers/media/v4l2-core/videobuf2-core.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 8bf3369..e866115 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -889,7 +889,6 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
{
struct vb2_queue *q = vb->vb2_queue;
unsigned long flags;
- unsigned int plane;
if (WARN_ON(vb->state != VB2_BUF_STATE_ACTIVE))
return;
@@ -910,10 +909,6 @@ void vb2_buffer_done(struct vb2_buffer *vb, enum
vb2_buffer_state state)
dprintk(4, "done processing on buffer %d, state: %d\n",
vb->index, state);
- /* sync buffers */
- for (plane = 0; plane < vb->num_planes; ++plane)
- call_void_memop(vb, finish, vb->planes[plane].mem_priv);
-
spin_lock_irqsave(&q->done_lock, flags);
if (state == VB2_BUF_STATE_QUEUED ||
state == VB2_BUF_STATE_REQUEUEING) {
@@ -1573,6 +1568,10 @@ static void __vb2_dqbuf(struct vb2_buffer *vb)
vb->state = VB2_BUF_STATE_DEQUEUED;
+ /* sync buffers */
+ for (i = 0; i < vb->num_planes; ++i)
+ call_void_memop(vb, finish, vb->planes[i].mem_priv);
+
/* unmap DMABUF buffer */
if (q->memory == VB2_MEMORY_DMABUF)
for (i = 0; i < vb->num_planes; ++i) {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v11] drm: Unplug drm device when unregistering it (v8)
After unbinding drm, the user space may still owns the drm dev fd, and
may still be able to call drm ioctl.
We're using an unplugged state to prevent something like that, so let's
reuse it here.
Also drop drm_unplug_dev, because it would be unused after other changes.
Verified on rk3399 chromebook kevin(with cros 4.4 kernel), no more crashes
when unbinding drm with ui service still running.
v2: Fix some commit messages.
v3: Reuse unplug status.
v4: Add drm_device_set_plug_state helper.
v5: Fix hang when unregistering drm dev with open_count 0.
v6: Move drm_device_set_plug_state into drm_drv.
v7: Add missing drm_dev_unref in udl_drv.
v8: Fix compiler errors after enable udl.
Signed-off-by: Jeffy Chen
---
drivers/gpu/drm/drm_drv.c | 26 ++
drivers/gpu/drm/udl/udl_drv.c | 3 ++-
include/drm/drmP.h| 6 --
include/drm/drm_drv.h | 1 -
4 files changed, 12 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index b5c6bb4..e1da4d1 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -355,22 +355,6 @@ void drm_put_dev(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_put_dev);
-void drm_unplug_dev(struct drm_device *dev)
-{
- /* for a USB device */
- drm_dev_unregister(dev);
-
- mutex_lock(&drm_global_mutex);
-
- drm_device_set_unplugged(dev);
-
- if (dev->open_count == 0) {
- drm_put_dev(dev);
- }
- mutex_unlock(&drm_global_mutex);
-}
-EXPORT_SYMBOL(drm_unplug_dev);
-
/*
* DRM internal mount
* We want to be able to allocate our own "struct address_space" to control
@@ -733,6 +717,13 @@ static void remove_compat_control_link(struct drm_device
*dev)
kfree(name);
}
+static inline void drm_device_set_plug_state(struct drm_device *dev,
+bool plugged)
+{
+ smp_wmb();
+ atomic_set(&dev->unplugged, !plugged);
+}
+
/**
* drm_dev_register - Register DRM device
* @dev: Device to register
@@ -787,6 +778,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long
flags)
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_register_all(dev);
+ drm_device_set_plug_state(dev, true);
+
ret = 0;
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
@@ -826,6 +819,7 @@ void drm_dev_unregister(struct drm_device *dev)
drm_lastclose(dev);
dev->registered = false;
+ drm_device_set_plug_state(dev, false);
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_unregister_all(dev);
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index cd8b017..fc73e24 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -108,7 +108,8 @@ static void udl_usb_disconnect(struct usb_interface
*interface)
drm_kms_helper_poll_disable(dev);
udl_fbdev_unplug(dev);
udl_drop_usb(dev);
- drm_unplug_dev(dev);
+ drm_dev_unregister(dev);
+ drm_dev_unref(dev);
}
/*
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3bfafcd..980a204 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -488,12 +488,6 @@ static __inline__ int drm_core_check_feature(struct
drm_device *dev,
return ((dev->driver->driver_features & feature) ? 1 : 0);
}
-static inline void drm_device_set_unplugged(struct drm_device *dev)
-{
- smp_wmb();
- atomic_set(&dev->unplugged, 1);
-}
-
static inline int drm_device_is_unplugged(struct drm_device *dev)
{
int ret = atomic_read(&dev->unplugged);
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 0fefc3f..eb63078 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -544,7 +544,6 @@ void drm_dev_unregister(struct drm_device *dev);
void drm_dev_ref(struct drm_device *dev);
void drm_dev_unref(struct drm_device *dev);
void drm_put_dev(struct drm_device *dev);
-void drm_unplug_dev(struct drm_device *dev);
int drm_dev_set_unique(struct drm_device *dev, const char *name);
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] nouveau_hwmon: migrate to hwmon_device_register_with_info
Here is where most of the work is being done.
We are replacing the old API with the new one, that means changing the
functions layout and remove unnecessary code.
We also set up the other operations:
.read
.write
.read_string
--- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig 2017-04-13
10:11:29.24186 +0200
+++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c 2017-04-13
10:12:38.016055129 +0200
@@ -38,21 +38,17 @@
#include
#if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE))
-static ssize_t
-nouveau_hwmon_show_temp(struct device *d, struct device_attribute *a, char
*buf)
+static int
+nouveau_hwmon_show_temp(struct nouveau_drm *drm)
{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
int temp = nvkm_therm_temp_get(therm);
if (temp < 0)
return temp;
- return snprintf(buf, PAGE_SIZE, "%d\n", temp * 1000);
+ return (temp * 1000);
}
-static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, nouveau_hwmon_show_temp,
- NULL, 0);
static ssize_t
nouveau_hwmon_show_temp1_auto_point1_pwm(struct device *d,
@@ -129,311 +125,157 @@ static SENSOR_DEVICE_ATTR(temp1_auto_poi
nouveau_hwmon_temp1_auto_point1_temp_hyst,
nouveau_hwmon_set_temp1_auto_point1_temp_hyst, 0);
-static ssize_t
-nouveau_hwmon_max_temp(struct device *d, struct device_attribute *a, char *buf)
+static int
+nouveau_hwmon_max_temp(struct nouveau_drm *drm)
{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
- return snprintf(buf, PAGE_SIZE, "%d\n",
- therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK) * 1000);
+ return (therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK) * 1000);
}
-static ssize_t
-nouveau_hwmon_set_max_temp(struct device *d, struct device_attribute *a,
- const char *buf, size_t count)
+
+static int
+nouveau_hwmon_set_max_temp(struct nouveau_drm *drm, long val)
{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
- long value;
- if (kstrtol(buf, 10, &value) == -EINVAL)
- return count;
-
- therm->attr_set(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK, value / 1000);
-
- return count;
+ return therm->attr_set(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK,
+ val / 1000);
}
-static SENSOR_DEVICE_ATTR(temp1_max, S_IRUGO | S_IWUSR, nouveau_hwmon_max_temp,
- nouveau_hwmon_set_max_temp,
- 0);
-static ssize_t
-nouveau_hwmon_max_temp_hyst(struct device *d, struct device_attribute *a,
- char *buf)
+static int
+nouveau_hwmon_max_temp_hyst(struct nouveau_drm *drm)
{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
- return snprintf(buf, PAGE_SIZE, "%d\n",
- therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK_HYST) * 1000);
+ return therm->attr_get(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK_HYST)
+ * 1000;
}
-static ssize_t
-nouveau_hwmon_set_max_temp_hyst(struct device *d, struct device_attribute *a,
- const char *buf, size_t count)
+
+static int
+nouveau_hwmon_set_max_temp_hyst(struct nouveau_drm *drm, long val)
{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
- long value;
-
- if (kstrtol(buf, 10, &value) == -EINVAL)
- return count;
-
- therm->attr_set(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK_HYST,
- value / 1000);
- return count;
+ return therm->attr_set(therm, NVKM_THERM_ATTR_THRS_DOWN_CLK_HYST,
+ val / 1000);
}
-static SENSOR_DEVICE_ATTR(temp1_max_hyst, S_IRUGO | S_IWUSR,
- nouveau_hwmon_max_temp_hyst,
- nouveau_hwmon_set_max_temp_hyst, 0);
-static ssize_t
-nouveau_hwmon_critical_temp(struct device *d, struct device_attribute *a,
- char *buf)
+static int
+nouveau_hwmon_critical_temp(struct nouveau_drm *drm)
{
- struct drm_device *dev = dev_get_drvdata(d);
- struct nouveau_drm *drm = nouveau_drm(dev);
[PATCH 4/4] nouveau_hwmon: migrate to hwmon_device_register_with_info
This patch replaces symbolic permissions with the numeric ones and adds me to
the authors too.
--- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig 2017-04-13
10:18:37.471129756 +0200
+++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c 2017-04-13
10:19:58.182025638 +0200
@@ -1,5 +1,6 @@
/*
- * Copyright 2010 Red Hat Inc.
+ * Copyright 2010 Red Hat Inc. (Ben Skeggs)
+ * Copyright 2017 Oscar Salvador
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -19,7 +20,6 @@
* ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
* OTHER DEALINGS IN THE SOFTWARE.
*
- * Authors: Ben Skeggs
*/
#ifdef CONFIG_ACPI
@@ -56,7 +56,7 @@ nouveau_hwmon_show_temp1_auto_point1_pwm
{
return snprintf(buf, PAGE_SIZE, "%d\n", 100);
}
-static SENSOR_DEVICE_ATTR(temp1_auto_point1_pwm, S_IRUGO,
+static SENSOR_DEVICE_ATTR(temp1_auto_point1_pwm, 0444,
nouveau_hwmon_show_temp1_auto_point1_pwm, NULL, 0);
static ssize_t
@@ -88,7 +88,7 @@ nouveau_hwmon_set_temp1_auto_point1_temp
return count;
}
-static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp, 0644,
nouveau_hwmon_temp1_auto_point1_temp,
nouveau_hwmon_set_temp1_auto_point1_temp, 0);
@@ -121,7 +121,7 @@ nouveau_hwmon_set_temp1_auto_point1_temp
return count;
}
-static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp_hyst, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(temp1_auto_point1_temp_hyst, 0644,
nouveau_hwmon_temp1_auto_point1_temp_hyst,
nouveau_hwmon_set_temp1_auto_point1_temp_hyst, 0);
@@ -313,7 +313,7 @@ nouveau_hwmon_set_pwm1_min(struct device
return count;
}
-static SENSOR_DEVICE_ATTR(pwm1_min, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(pwm1_min, 0644,
nouveau_hwmon_get_pwm1_min,
nouveau_hwmon_set_pwm1_min, 0);
@@ -353,7 +353,7 @@ nouveau_hwmon_set_pwm1_max(struct device
return count;
}
-static SENSOR_DEVICE_ATTR(pwm1_max, S_IRUGO | S_IWUSR,
+static SENSOR_DEVICE_ATTR(pwm1_max, 0644,
nouveau_hwmon_get_pwm1_max,
nouveau_hwmon_set_pwm1_max, 0);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 10/14] vb2: dma-contig: Fix DMA attribute and cache management
Patch ccc66e73 ("ARM: 8508/2: videobuf2-dc: Let drivers specify DMA
attrs") added support for driver specific DMA attributes to
videobuf2-dma-contig but it had several issues in it.
In particular,
- cache operations were only performed on USERPTR buffers,
- DMA attributes were set only for MMAP buffers and
- it did not provide begin_cpu_access() and end_cpu_access() dma_buf_ops
callbacks for cache syncronisation on exported MMAP buffers.
This patch corrects these issues.
Also arrange the header files alphabetically.
Fixes: ccc66e73 ("ARM: 8508/2: videobuf2-dc: Let drivers specify DMA attrs")
Signed-off-by: Sakari Ailus
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 90 --
1 file changed, 69 insertions(+), 21 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 8ea9ab9..6a707d3 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -11,12 +11,12 @@
*/
#include
+#include
#include
#include
#include
#include
#include
-#include
#include
#include
@@ -116,12 +116,13 @@ static void vb2_dc_prepare(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
struct sg_table *sgt = buf->dma_sgt;
- /* DMABUF exporter will flush the cache for us */
- if (!buf->vec)
- return;
-
- dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
- buf->dma_dir);
+ /*
+* DMABUF exporter will flush the cache for us; only USERPTR
+* and MMAP buffers with non-coherent memory will be flushed.
+*/
+ if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+ dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
+ buf->dma_dir);
}
static void vb2_dc_finish(void *buf_priv)
@@ -129,11 +130,13 @@ static void vb2_dc_finish(void *buf_priv)
struct vb2_dc_buf *buf = buf_priv;
struct sg_table *sgt = buf->dma_sgt;
- /* DMABUF exporter will flush the cache for us */
- if (!buf->vec)
- return;
-
- dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir);
+ /*
+* DMABUF exporter will flush the cache for us; only USERPTR
+* and MMAP buffers with non-coherent memory will be flushed.
+*/
+ if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+ dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents,
+ buf->dma_dir);
}
/*/
@@ -172,9 +175,9 @@ static void *vb2_dc_alloc(struct device *dev, unsigned long
attrs,
buf->attrs = attrs;
buf->cookie = dma_alloc_attrs(dev, size, &buf->dma_addr,
- GFP_KERNEL | gfp_flags, buf->attrs);
+ GFP_KERNEL | gfp_flags, buf->attrs);
if (!buf->cookie) {
- dev_err(dev, "dma_alloc_coherent of size %ld failed\n", size);
+ dev_err(dev, "dma_alloc_attrs of size %ld failed\n", size);
kfree(buf);
return ERR_PTR(-ENOMEM);
}
@@ -187,6 +190,14 @@ static void *vb2_dc_alloc(struct device *dev, unsigned
long attrs,
buf->size = size;
buf->dma_dir = dma_dir;
+ buf->dma_sgt = vb2_dc_get_base_sgt(buf);
+ if (!buf->dma_sgt) {
+ dma_free_attrs(dev, size, buf->cookie, buf->dma_addr,
+ buf->attrs);
+ put_device(dev);
+ return ERR_PTR(-ENOMEM);
+ }
+
buf->handler.refcount = &buf->refcount;
buf->handler.put = vb2_dc_put;
buf->handler.arg = buf;
@@ -359,6 +370,40 @@ static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf,
unsigned long pgnum)
return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
}
+static int vb2_dc_dmabuf_ops_begin_cpu_access(struct dma_buf *dbuf,
+ enum dma_data_direction direction)
+{
+ struct vb2_dc_buf *buf = dbuf->priv;
+ struct sg_table *sgt = buf->dma_sgt;
+
+ /*
+* DMABUF exporter will flush the cache for us; only USERPTR
+* and MMAP buffers with non-coherent memory will be flushed.
+*/
+ if (buf->attrs & DMA_ATTR_NON_CONSISTENT)
+ dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents,
+ buf->dma_dir);
+
+ return 0;
+}
+
+static int vb2_dc_dmabuf_ops_end_cpu_access(struct dma_buf *dbuf,
+ enum dma_data_direction direction)
+{
+ struct vb2_dc_buf *buf = dbuf->priv;
+ struct sg_table *sgt = buf->dma_sgt;
+
+ /*
+* DMABUF exporter will flush the cache for us; only USERPTR
+* and MMAP buffers with non-coherent memory will be flushed.
+*/
+ if (buf->attrs &
[RFC v3 11/14] vb2: dma-contig: Add WARN_ON_ONCE() to check for potential bugs
The scatterlist should always be present when the cache would need to be flushed. Each buffer type has its own means to provide that. Add WARN_ON_ONCE() to check the scatterist exists. Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil --- drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c b/drivers/media/v4l2-core/videobuf2-dma-contig.c index 6a707d3..2847fbf 100644 --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c @@ -120,7 +120,7 @@ static void vb2_dc_prepare(void *buf_priv) * DMABUF exporter will flush the cache for us; only USERPTR * and MMAP buffers with non-coherent memory will be flushed. */ - if (buf->attrs & DMA_ATTR_NON_CONSISTENT) + if (buf->attrs & DMA_ATTR_NON_CONSISTENT && !WARN_ON_ONCE(!sgt)) dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir); } @@ -134,7 +134,7 @@ static void vb2_dc_finish(void *buf_priv) * DMABUF exporter will flush the cache for us; only USERPTR * and MMAP buffers with non-coherent memory will be flushed. */ - if (buf->attrs & DMA_ATTR_NON_CONSISTENT) + if (buf->attrs & DMA_ATTR_NON_CONSISTENT && !WARN_ON_ONCE(!sgt)) dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir); } @@ -380,7 +380,7 @@ static int vb2_dc_dmabuf_ops_begin_cpu_access(struct dma_buf *dbuf, * DMABUF exporter will flush the cache for us; only USERPTR * and MMAP buffers with non-coherent memory will be flushed. */ - if (buf->attrs & DMA_ATTR_NON_CONSISTENT) + if (buf->attrs & DMA_ATTR_NON_CONSISTENT && !WARN_ON_ONCE(!sgt)) dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir); @@ -397,7 +397,7 @@ static int vb2_dc_dmabuf_ops_end_cpu_access(struct dma_buf *dbuf, * DMABUF exporter will flush the cache for us; only USERPTR * and MMAP buffers with non-coherent memory will be flushed. */ - if (buf->attrs & DMA_ATTR_NON_CONSISTENT) + if (buf->attrs & DMA_ATTR_NON_CONSISTENT && !WARN_ON_ONCE(!sgt)) dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->nents, buf->dma_dir); -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 01/14] vb2: Rename confusingly named internal buffer preparation functions
Rename __qbuf_*() functions which are specific to a buffer type as
__prepare_*() which matches with what they do. The naming was there for
historical reasons; the purpose of the functions was changed without
renaming them.
Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
Reviewed-by: Laurent Pinchart
---
drivers/media/v4l2-core/videobuf2-core.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 94afbbf9..8df680d 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -956,9 +956,9 @@ void vb2_discard_done(struct vb2_queue *q)
EXPORT_SYMBOL_GPL(vb2_discard_done);
/**
- * __qbuf_mmap() - handle qbuf of an MMAP buffer
+ * __prepare_mmap() - prepare an MMAP buffer
*/
-static int __qbuf_mmap(struct vb2_buffer *vb, const void *pb)
+static int __prepare_mmap(struct vb2_buffer *vb, const void *pb)
{
int ret = 0;
@@ -969,9 +969,9 @@ static int __qbuf_mmap(struct vb2_buffer *vb, const void
*pb)
}
/**
- * __qbuf_userptr() - handle qbuf of a USERPTR buffer
+ * __prepare_userptr() - prepare a USERPTR buffer
*/
-static int __qbuf_userptr(struct vb2_buffer *vb, const void *pb)
+static int __prepare_userptr(struct vb2_buffer *vb, const void *pb)
{
struct vb2_plane planes[VB2_MAX_PLANES];
struct vb2_queue *q = vb->vb2_queue;
@@ -1087,9 +1087,9 @@ static int __qbuf_userptr(struct vb2_buffer *vb, const
void *pb)
}
/**
- * __qbuf_dmabuf() - handle qbuf of a DMABUF buffer
+ * __prepare_dmabuf() - prepare a DMABUF buffer
*/
-static int __qbuf_dmabuf(struct vb2_buffer *vb, const void *pb)
+static int __prepare_dmabuf(struct vb2_buffer *vb, const void *pb)
{
struct vb2_plane planes[VB2_MAX_PLANES];
struct vb2_queue *q = vb->vb2_queue;
@@ -1255,13 +1255,13 @@ static int __buf_prepare(struct vb2_buffer *vb, const
void *pb)
switch (q->memory) {
case VB2_MEMORY_MMAP:
- ret = __qbuf_mmap(vb, pb);
+ ret = __prepare_mmap(vb, pb);
break;
case VB2_MEMORY_USERPTR:
- ret = __qbuf_userptr(vb, pb);
+ ret = __prepare_userptr(vb, pb);
break;
case VB2_MEMORY_DMABUF:
- ret = __qbuf_dmabuf(vb, pb);
+ ret = __prepare_dmabuf(vb, pb);
break;
default:
WARN(1, "Invalid queue type\n");
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 07/14] vb2: dma-contig: Remove redundant sgt_base field
The struct vb2_dc_buf contains two struct sg_table fields: sgt_base and
dma_sgt. The former is used by DMA-BUF buffers whereas the latter is used
by USERPTR.
Unify the two, leaving dma_sgt.
MMAP buffers do not need cache flushing since they have been allocated
using dma_alloc_coherent().
Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index a8a46a8..ddbbcf0 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -31,12 +31,13 @@ struct vb2_dc_buf {
unsigned long attrs;
enum dma_data_direction dma_dir;
struct sg_table *dma_sgt;
- struct frame_vector *vec;
/* MMAP related */
struct vb2_vmarea_handler handler;
refcount_t refcount;
- struct sg_table *sgt_base;
+
+ /* USERPTR related */
+ struct frame_vector *vec;
/* DMABUF related */
struct dma_buf_attachment *db_attach;
@@ -96,7 +97,7 @@ static void vb2_dc_prepare(void *buf_priv)
struct sg_table *sgt = buf->dma_sgt;
/* DMABUF exporter will flush the cache for us */
- if (!sgt || buf->db_attach)
+ if (!buf->vec)
return;
dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
@@ -109,7 +110,7 @@ static void vb2_dc_finish(void *buf_priv)
struct sg_table *sgt = buf->dma_sgt;
/* DMABUF exporter will flush the cache for us */
- if (!sgt || buf->db_attach)
+ if (!buf->vec)
return;
dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir);
@@ -126,9 +127,9 @@ static void vb2_dc_put(void *buf_priv)
if (!refcount_dec_and_test(&buf->refcount))
return;
- if (buf->sgt_base) {
- sg_free_table(buf->sgt_base);
- kfree(buf->sgt_base);
+ if (buf->dma_sgt) {
+ sg_free_table(buf->dma_sgt);
+ kfree(buf->dma_sgt);
}
dma_free_attrs(buf->dev, buf->size, buf->cookie, buf->dma_addr,
buf->attrs);
@@ -239,13 +240,13 @@ static int vb2_dc_dmabuf_ops_attach(struct dma_buf *dbuf,
struct device *dev,
/* Copy the buf->base_sgt scatter list to the attachment, as we can't
* map the same scatter list to multiple attachments at the same time.
*/
- ret = sg_alloc_table(sgt, buf->sgt_base->orig_nents, GFP_KERNEL);
+ ret = sg_alloc_table(sgt, buf->dma_sgt->orig_nents, GFP_KERNEL);
if (ret) {
kfree(attach);
return -ENOMEM;
}
- rd = buf->sgt_base->sgl;
+ rd = buf->dma_sgt->sgl;
wr = sgt->sgl;
for (i = 0; i < sgt->orig_nents; ++i) {
sg_set_page(wr, sg_page(rd), rd->length, rd->offset);
@@ -396,10 +397,10 @@ static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv,
unsigned long flags)
exp_info.flags = flags;
exp_info.priv = buf;
- if (!buf->sgt_base)
- buf->sgt_base = vb2_dc_get_base_sgt(buf);
+ if (!buf->dma_sgt)
+ buf->dma_sgt = vb2_dc_get_base_sgt(buf);
- if (WARN_ON(!buf->sgt_base))
+ if (WARN_ON(!buf->dma_sgt))
return NULL;
dbuf = dma_buf_export(&exp_info);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] nouveau_hwmon: migrate to hwmon_device_register_with_info
This patch creates special group attributes for special attrs like
"*auto_point*".
We check if we need them, and if we do, we set them up in special_groups
structure, that then
we pass to hwmon_device_register_with_info.
--- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig 2017-04-13
10:13:26.331391326 +0200
+++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c 2017-04-13
10:15:02.274073273 +0200
@@ -417,6 +417,23 @@ nouveau_hwmon_get_power1_crit(struct nou
return iccsense->power_w_crit;
}
+static struct attribute *pwm_fan_sensor_attrs[] = {
+ &sensor_dev_attr_pwm1_min.dev_attr.attr,
+ &sensor_dev_attr_pwm1_max.dev_attr.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(pwm_fan_sensor);
+
+static struct attribute *temp1_auto_point_sensor_attrs[] = {
+ &sensor_dev_attr_temp1_auto_point1_pwm.dev_attr.attr,
+ &sensor_dev_attr_temp1_auto_point1_temp.dev_attr.attr,
+ &sensor_dev_attr_temp1_auto_point1_temp_hyst.dev_attr.attr,
+ NULL
+};
+ATTRIBUTE_GROUPS(temp1_auto_point_sensor);
+
+#define N_ATTR_GROUPS 3
+
static const u32 nouveau_config_chip[] = {
HWMON_C_UPDATE_INTERVAL,
0
@@ -868,17 +885,27 @@ nouveau_hwmon_init(struct drm_device *de
#if defined(CONFIG_HWMON) || (defined(MODULE) && defined(CONFIG_HWMON_MODULE))
struct nouveau_drm *drm = nouveau_drm(dev);
struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
+ const struct attribute_group *special_groups[N_ATTR_GROUPS];
struct nouveau_hwmon *hwmon;
struct device *hwmon_dev;
int ret = 0;
+ int i = 0;
hwmon = drm->hwmon = kzalloc(sizeof(*hwmon), GFP_KERNEL);
if (!hwmon)
return -ENOMEM;
hwmon->dev = dev;
+ if (therm && therm->attr_get && therm->attr_set) {
+ if (nvkm_therm_temp_get(therm) >= 0)
+ special_groups[i++] = &temp1_auto_point_sensor_group;
+ if (therm->fan_get && therm->fan_get(therm) >= 0)
+ special_groups[i++] = &pwm_fan_sensor_group;
+ }
+
+ special_groups[i] = 0;
hwmon_dev = hwmon_device_register_with_info(dev->dev, "nouveau", dev,
- &nouveau_chip_info, NULL);
+ &nouveau_chip_info, special_groups);
if (IS_ERR(hwmon_dev)) {
ret = PTR_ERR(hwmon_dev);
NV_ERROR(drm, "Unable to register hwmon device: %d\n", ret);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 05/14] vb2: Anticipate queue specific DMA attributes for USERPTR buffers
The DMA attributes were available for the memop implementation for MMAP
buffers but not for USERPTR buffers. Do the same for USERPTR. This patch
makes no functional changes.
Signed-off-by: Sakari Ailus
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 3 ++-
drivers/media/v4l2-core/videobuf2-dma-sg.c | 3 ++-
drivers/media/v4l2-core/videobuf2-vmalloc.c| 3 ++-
include/media/videobuf2-core.h | 3 ++-
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index d29a07f..30082a4 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -475,7 +475,8 @@ static inline dma_addr_t vb2_dc_pfn_to_dma(struct device
*dev, unsigned long pfn
#endif
static void *vb2_dc_get_userptr(struct device *dev, unsigned long vaddr,
- unsigned long size, enum dma_data_direction dma_dir)
+ unsigned long size, enum dma_data_direction dma_dir,
+ unsigned long attrs)
{
struct vb2_dc_buf *buf;
struct frame_vector *vec;
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 29fde1a..102ddb2 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -220,7 +220,8 @@ static void vb2_dma_sg_finish(void *buf_priv)
static void *vb2_dma_sg_get_userptr(struct device *dev, unsigned long vaddr,
unsigned long size,
- enum dma_data_direction dma_dir)
+ enum dma_data_direction dma_dir,
+ unsigned long dma_attrs)
{
struct vb2_dma_sg_buf *buf;
struct sg_table *sgt;
diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c
b/drivers/media/v4l2-core/videobuf2-vmalloc.c
index f83253a..a4914fc 100644
--- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
+++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
@@ -73,7 +73,8 @@ static void vb2_vmalloc_put(void *buf_priv)
static void *vb2_vmalloc_get_userptr(struct device *dev, unsigned long vaddr,
unsigned long size,
-enum dma_data_direction dma_dir)
+enum dma_data_direction dma_dir,
+unsigned long dma_attrs)
{
struct vb2_vmalloc_buf *buf;
struct frame_vector *vec;
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index cb97c22..4172f6e 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -122,7 +122,8 @@ struct vb2_mem_ops {
void*(*get_userptr)(struct device *dev, unsigned long vaddr,
unsigned long size,
- enum dma_data_direction dma_dir);
+ enum dma_data_direction dma_dir,
+ unsigned long dma_attrs);
void(*put_userptr)(void *buf_priv);
void(*prepare)(void *buf_priv);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 09/14] vb2: dma-contig: Move vb2_dc_get_base_sgt() up
Just move the function up. It'll be soon needed earlier than previously.
Signed-off-by: Sakari Ailus
Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 40 +-
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 22636cd..8ea9ab9 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -63,6 +63,26 @@ static unsigned long vb2_dc_get_contiguous_size(struct
sg_table *sgt)
return size;
}
+static struct sg_table *vb2_dc_get_base_sgt(struct vb2_dc_buf *buf)
+{
+ int ret;
+ struct sg_table *sgt;
+
+ sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
+ if (!sgt)
+ return NULL;
+
+ ret = dma_get_sgtable_attrs(buf->dev, sgt, buf->cookie, buf->dma_addr,
+ buf->size, buf->attrs);
+ if (ret < 0) {
+ dev_err(buf->dev, "failed to get scatterlist from DMA API\n");
+ kfree(sgt);
+ return NULL;
+ }
+
+ return sgt;
+}
+
/*/
/* callbacks for all buffers */
/*/
@@ -364,26 +384,6 @@ static struct dma_buf_ops vb2_dc_dmabuf_ops = {
.release = vb2_dc_dmabuf_ops_release,
};
-static struct sg_table *vb2_dc_get_base_sgt(struct vb2_dc_buf *buf)
-{
- int ret;
- struct sg_table *sgt;
-
- sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
- if (!sgt)
- return NULL;
-
- ret = dma_get_sgtable_attrs(buf->dev, sgt, buf->cookie, buf->dma_addr,
- buf->size, buf->attrs);
- if (ret < 0) {
- dev_err(buf->dev, "failed to get scatterlist from DMA API\n");
- kfree(sgt);
- return NULL;
- }
-
- return sgt;
-}
-
static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv, unsigned long flags)
{
struct vb2_dc_buf *buf = buf_priv;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] nouveau_hwmon: migrate to hwmon_device_register_with_info
This patch introduces the structure "struct hwmon_ops" and sets up the
".visible" operation.
Is also a preparation for the next patch where all work is being done.
--- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig 2017-04-12
19:22:29.070573187 +0200
+++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c 2017-04-12
19:21:32.391338011 +0200
@@ -764,6 +764,166 @@ static const struct hwmon_channel_info *
&nouveau_power,
NULL
};
+
+static umode_t
+nouveau_chip_is_visible(const void *data, u32 attr, int channel)
+{
+ switch (attr) {
+ case hwmon_chip_update_interval:
+ return 0444;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_power_is_visible(const void *data, u32 attr, int channel)
+{
+ struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+ struct nvkm_iccsense *iccsense = nvxx_iccsense(&drm->client.device);
+
+ switch (attr) {
+ case hwmon_power_input:
+ if (iccsense && iccsense->data_valid &&
+ !list_empty(&iccsense->rails))
+ return 0444;
+ case hwmon_power_max:
+ case hwmon_power_crit:
+ if (iccsense->power_w_max && iccsense->power_w_crit)
+ return 0444;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_temp_is_visible(const void *data, u32 attr, int channel)
+{
+ struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+ struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
+
+ if (therm && therm->attr_get && therm->attr_set)
+ if (nvkm_therm_temp_get(therm) < 0)
+ return 0;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ return 0444;
+ case hwmon_temp_max:
+ case hwmon_temp_max_hyst:
+ case hwmon_temp_crit:
+ case hwmon_temp_crit_hyst:
+ case hwmon_temp_emergency:
+ case hwmon_temp_emergency_hyst:
+ return 0644;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_pwm_is_visible(const void *data, u32 attr, int channel)
+{
+ struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+ struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
+
+ if (therm && therm->attr_get)
+ if (therm->fan_get && therm->fan_get(therm) < 0)
+ return 0;
+
+ switch (attr) {
+ case hwmon_pwm_enable:
+ case hwmon_pwm_input:
+ return 0644;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_input_is_visible(const void *data, u32 attr, int channel)
+{
+ struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+ struct nvkm_volt *volt = nvxx_volt(&drm->client.device);
+
+ if (!volt || nvkm_volt_get(volt) < 0)
+ return 0;
+
+ switch (attr) {
+ case hwmon_in_input:
+ case hwmon_in_label:
+ case hwmon_in_min:
+ case hwmon_in_max:
+ return 0444;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_fan_is_visible(const void *data, u32 attr, int channel)
+{
+ struct nouveau_drm *drm = nouveau_drm((struct drm_device *)data);
+ struct nvkm_therm *therm = nvxx_therm(&drm->client.device);
+
+ if (!therm || !therm->attr_get || nvkm_therm_fan_sense(therm) < 0)
+ return 0;
+
+ switch (attr) {
+ case hwmon_fan_input:
+ return 0444;
+ default:
+ return 0;
+ }
+}
+
+static umode_t
+nouveau_is_visible(const void *data, enum hwmon_sensor_types type, u32 attr,
+ int channel)
+{
+ switch (type) {
+ case hwmon_chip:
+ return nouveau_chip_is_visible(data, attr, channel);
+ case hwmon_temp:
+ return nouveau_temp_is_visible(data, attr, channel);
+ case hwmon_fan:
+ return nouveau_fan_is_visible(data, attr, channel);
+ case hwmon_in:
+ return nouveau_input_is_visible(data, attr, channel);
+ case hwmon_pwm:
+ return nouveau_pwm_is_visible(data, attr, channel);
+ case hwmon_power:
+ return nouveau_power_is_visible(data, attr, channel);
+ default:
+ return 0;
+ }
+}
+
+static char *input_label = "GPU core";
+
+static int
+nouveau_read_string(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+ int channel, char **buf)
+{
+ if (type == hwmon_in && attr == hwmon_in_label) {
+ *buf = input_label;
+ return 0;
+ }
+
+ return -EOPNOTSUPP;
+}
+
+static const struct hwmon_ops nouveau_hwmon_ops = {
+ .is_visible = nouveau_is_visible,
+ .read = NULL,
+ .read_string = nouveau_re
[RFC v3 02/14] vb2: Move buffer cache synchronisation to prepare from queue
The buffer cache should be synchronised in buffer preparation, not when
the buffer is queued to the device. Fix this.
Mmap buffers do not need cache synchronisation since they are always
coherent.
Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
---
drivers/media/v4l2-core/videobuf2-core.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 8df680d..8bf3369 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1227,23 +1227,19 @@ static int __prepare_dmabuf(struct vb2_buffer *vb,
const void *pb)
static void __enqueue_in_driver(struct vb2_buffer *vb)
{
struct vb2_queue *q = vb->vb2_queue;
- unsigned int plane;
vb->state = VB2_BUF_STATE_ACTIVE;
atomic_inc(&q->owned_by_drv_count);
trace_vb2_buf_queue(q, vb);
- /* sync buffers */
- for (plane = 0; plane < vb->num_planes; ++plane)
- call_void_memop(vb, prepare, vb->planes[plane].mem_priv);
-
call_void_vb_qop(vb, buf_queue, vb);
}
static int __buf_prepare(struct vb2_buffer *vb, const void *pb)
{
struct vb2_queue *q = vb->vb2_queue;
+ unsigned int plane;
int ret;
if (q->error) {
@@ -1268,11 +1264,19 @@ static int __buf_prepare(struct vb2_buffer *vb, const
void *pb)
ret = -EINVAL;
}
- if (ret)
+ if (ret) {
dprintk(1, "buffer preparation failed: %d\n", ret);
- vb->state = ret ? VB2_BUF_STATE_DEQUEUED : VB2_BUF_STATE_PREPARED;
+ vb->state = VB2_BUF_STATE_DEQUEUED;
+ return ret;
+ }
- return ret;
+ /* sync buffers */
+ for (plane = 0; plane < vb->num_planes; ++plane)
+ call_void_memop(vb, prepare, vb->planes[plane].mem_priv);
+
+ vb->state = VB2_BUF_STATE_PREPARED;
+
+ return 0;
}
int vb2_core_prepare_buf(struct vb2_queue *q, unsigned int index, void *pb)
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 13/14] vb2: Don't sync cache for a buffer if so requested
From: Samu Onkalo
The user may request to the driver (vb2) to skip the cache maintenance
operations in case the buffer does not need cache synchronisation, e.g. in
cases where the buffer is passed between hardware blocks without it being
touched by the CPU.
Also document that the prepare and finish vb2_mem_ops might not get called
every time the buffer ownership changes between the kernel and the user
space.
Signed-off-by: Samu Onkalo
Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
---
drivers/media/v4l2-core/videobuf2-core.c | 101 +--
drivers/media/v4l2-core/videobuf2-v4l2.c | 14 -
include/media/videobuf2-core.h | 23 ---
3 files changed, 97 insertions(+), 41 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index e866115..7f21acd 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -189,6 +189,28 @@ static void __vb2_queue_cancel(struct vb2_queue *q);
static void __enqueue_in_driver(struct vb2_buffer *vb);
/**
+ * __mem_prepare_planes() - call finish mem op for all planes of the buffer
+ */
+static void __mem_prepare_planes(struct vb2_buffer *vb)
+{
+ unsigned int plane;
+
+ for (plane = 0; plane < vb->num_planes; ++plane)
+ call_void_memop(vb, prepare, vb->planes[plane].mem_priv);
+}
+
+/**
+ * __mem_finish_planes() - call finish mem op for all planes of the buffer
+ */
+static void __mem_finish_planes(struct vb2_buffer *vb)
+{
+ unsigned int plane;
+
+ for (plane = 0; plane < vb->num_planes; ++plane)
+ call_void_memop(vb, finish, vb->planes[plane].mem_priv);
+}
+
+/**
* __vb2_buf_mem_alloc() - allocate video memory for the given buffer
*/
static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
@@ -953,20 +975,29 @@ EXPORT_SYMBOL_GPL(vb2_discard_done);
/**
* __prepare_mmap() - prepare an MMAP buffer
*/
-static int __prepare_mmap(struct vb2_buffer *vb, const void *pb)
+static int __prepare_mmap(struct vb2_buffer *vb, const void *pb,
+ bool no_cache_sync)
{
- int ret = 0;
+ int ret;
- if (pb)
+ if (pb) {
ret = call_bufop(vb->vb2_queue, fill_vb2_buffer,
vb, pb, vb->planes);
- return ret ? ret : call_vb_qop(vb, buf_prepare, vb);
+ if (ret)
+ return ret;
+ }
+
+ if (!no_cache_sync)
+ __mem_prepare_planes(vb);
+
+ return call_vb_qop(vb, buf_prepare, vb);
}
/**
* __prepare_userptr() - prepare a USERPTR buffer
*/
-static int __prepare_userptr(struct vb2_buffer *vb, const void *pb)
+static int __prepare_userptr(struct vb2_buffer *vb, const void *pb,
+bool no_cache_sync)
{
struct vb2_plane planes[VB2_MAX_PLANES];
struct vb2_queue *q = vb->vb2_queue;
@@ -1057,6 +1088,11 @@ static int __prepare_userptr(struct vb2_buffer *vb,
const void *pb)
dprintk(1, "buffer initialization failed\n");
goto err;
}
+
+ /* This is new buffer memory --- always synchronise cache. */
+ __mem_prepare_planes(vb);
+ } else if (!no_cache_sync) {
+ __mem_prepare_planes(vb);
}
ret = call_vb_qop(vb, buf_prepare, vb);
@@ -1084,7 +1120,8 @@ static int __prepare_userptr(struct vb2_buffer *vb, const
void *pb)
/**
* __prepare_dmabuf() - prepare a DMABUF buffer
*/
-static int __prepare_dmabuf(struct vb2_buffer *vb, const void *pb)
+static int __prepare_dmabuf(struct vb2_buffer *vb, const void *pb,
+ bool no_cache_sync)
{
struct vb2_plane planes[VB2_MAX_PLANES];
struct vb2_queue *q = vb->vb2_queue;
@@ -1199,6 +1236,11 @@ static int __prepare_dmabuf(struct vb2_buffer *vb, const
void *pb)
dprintk(1, "buffer initialization failed\n");
goto err;
}
+
+ /* This is new buffer memory --- always synchronise cache. */
+ __mem_prepare_planes(vb);
+ } else if (!no_cache_sync) {
+ __mem_prepare_planes(vb);
}
ret = call_vb_qop(vb, buf_prepare, vb);
@@ -1231,10 +1273,10 @@ static void __enqueue_in_driver(struct vb2_buffer *vb)
call_void_vb_qop(vb, buf_queue, vb);
}
-static int __buf_prepare(struct vb2_buffer *vb, const void *pb)
+static int __buf_prepare(struct vb2_buffer *vb, const void *pb,
+bool no_cache_sync)
{
struct vb2_queue *q = vb->vb2_queue;
- unsigned int plane;
int ret;
if (q->error) {
@@ -1246,13 +1288,13 @@ static int __buf_prepare(struct vb2_buffer *vb, const
void *pb)
switch (q->memory) {
case VB2_MEMORY_MMAP:
- ret = __prepare_mmap(vb, pb);
+ ret = __prepare_mmap(vb, pb, no_
[RFC v3 12/14] vb2: dma-sg: Let drivers decide DMA attrs of MMAP and USERPTR bufs
The desirable DMA attributes are not generic for all devices using
Videobuf2 scatter-gather DMA ops. Let the drivers decide.
As a result, also the DMA-BUF exporter must provide ops for synchronising
the cache. This adds begin_cpu_access and end_cpu_access ops to
vb2_dc_dmabuf_ops.
Signed-off-by: Sakari Ailus
---
drivers/media/v4l2-core/videobuf2-dma-sg.c | 81 +++---
1 file changed, 62 insertions(+), 19 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 102ddb2..5662f00 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -38,6 +38,7 @@ struct vb2_dma_sg_buf {
struct frame_vector *vec;
int offset;
enum dma_data_direction dma_dir;
+ unsigned long dma_attrs;
struct sg_table sg_table;
/*
* This will point to sg_table when used with the MMAP or USERPTR
@@ -114,6 +115,7 @@ static void *vb2_dma_sg_alloc(struct device *dev, unsigned
long dma_attrs,
buf->vaddr = NULL;
buf->dma_dir = dma_dir;
+ buf->dma_attrs = dma_attrs;
buf->offset = 0;
buf->size = size;
/* size is already page aligned */
@@ -143,7 +145,7 @@ static void *vb2_dma_sg_alloc(struct device *dev, unsigned
long dma_attrs,
* prepare() memop is called.
*/
sgt->nents = dma_map_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents,
- buf->dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
+ buf->dma_dir, dma_attrs);
if (!sgt->nents)
goto fail_map;
@@ -181,7 +183,7 @@ static void vb2_dma_sg_put(void *buf_priv)
dprintk(1, "%s: Freeing buffer of %d pages\n", __func__,
buf->num_pages);
dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents,
- buf->dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
+ buf->dma_dir, buf->dma_attrs);
if (buf->vaddr)
vm_unmap_ram(buf->vaddr, buf->num_pages);
sg_free_table(buf->dma_sgt);
@@ -198,12 +200,13 @@ static void vb2_dma_sg_prepare(void *buf_priv)
struct vb2_dma_sg_buf *buf = buf_priv;
struct sg_table *sgt = buf->dma_sgt;
- /* DMABUF exporter will flush the cache for us */
- if (buf->db_attach)
- return;
-
- dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
- buf->dma_dir);
+ /*
+* DMABUF exporter will flush the cache for us; only USERPTR
+* and MMAP buffers with non-coherent memory will be flushed.
+*/
+ if (buf->dma_attrs & DMA_ATTR_NON_CONSISTENT)
+ dma_sync_sg_for_device(buf->dev, sgt->sgl, sgt->orig_nents,
+ buf->dma_dir);
}
static void vb2_dma_sg_finish(void *buf_priv)
@@ -211,11 +214,13 @@ static void vb2_dma_sg_finish(void *buf_priv)
struct vb2_dma_sg_buf *buf = buf_priv;
struct sg_table *sgt = buf->dma_sgt;
- /* DMABUF exporter will flush the cache for us */
- if (buf->db_attach)
- return;
-
- dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir);
+ /*
+* DMABUF exporter will flush the cache for us; only USERPTR
+* and MMAP buffers with non-coherent memory will be flushed.
+*/
+ if (buf->dma_attrs & DMA_ATTR_NON_CONSISTENT)
+ dma_sync_sg_for_cpu(buf->dev, sgt->sgl, sgt->orig_nents,
+ buf->dma_dir);
}
static void *vb2_dma_sg_get_userptr(struct device *dev, unsigned long vaddr,
@@ -237,6 +242,7 @@ static void *vb2_dma_sg_get_userptr(struct device *dev,
unsigned long vaddr,
buf->vaddr = NULL;
buf->dev = dev;
buf->dma_dir = dma_dir;
+ buf->dma_attrs = dma_attrs;
buf->offset = vaddr & ~PAGE_MASK;
buf->size = size;
buf->dma_sgt = &buf->sg_table;
@@ -260,7 +266,7 @@ static void *vb2_dma_sg_get_userptr(struct device *dev,
unsigned long vaddr,
* prepare() memop is called.
*/
sgt->nents = dma_map_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents,
- buf->dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
+ buf->dma_dir, dma_attrs);
if (!sgt->nents)
goto userptr_fail_map;
@@ -288,7 +294,7 @@ static void vb2_dma_sg_put_userptr(void *buf_priv)
dprintk(1, "%s: Releasing userspace buffer of %d pages\n",
__func__, buf->num_pages);
dma_unmap_sg_attrs(buf->dev, sgt->sgl, sgt->orig_nents, buf->dma_dir,
- DMA_ATTR_SKIP_CPU_SYNC);
+ buf->dma_attrs);
if (buf->vaddr)
[RFC v3 04/14] v4l: Unify cache management hint buffer flags
The V4L2_BUF_FLAG_NO_CACHE_INVALIDATE and V4L2_BUF_FLAG_NO_CACHE_CLEAN
buffer flags are currently not used by the kernel. Replace the definitions
by a single V4L2_BUF_FLAG_NO_CACHE_SYNC flag to be used by further
patches.
Different cache architectures should not be visible to the user space
which can make no meaningful use of the differences anyway. In case a
device can make use of non-coherent memory accesses, the necessary cache
operations depend on the CPU architecture and the buffer type, not the
requests of the user. The cache operation itself may be skipped on the
user's request which was the purpose of the two flags.
On ARM the invalidate and clean are separate operations whereas on
x86(-64) the two are a single operation (flush). Whether the hardware uses
the buffer for reading (V4L2_BUF_TYPE_*_OUTPUT*) or writing
(V4L2_BUF_TYPE_*CAPTURE*) already defines the required cache operation
(clean and invalidate, respectively). No user input is required.
Signed-off-by: Sakari Ailus
Acked-by: Hans Verkuil
---
Documentation/media/uapi/v4l/buffer.rst| 24 --
.../media/uapi/v4l/vidioc-prepare-buf.rst | 5 ++---
include/trace/events/v4l2.h| 3 +--
include/uapi/linux/videodev2.h | 7 +--
4 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/Documentation/media/uapi/v4l/buffer.rst
b/Documentation/media/uapi/v4l/buffer.rst
index ac58966..601c3e9 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -437,23 +437,17 @@ Buffer Flags
:ref:`VIDIOC_PREPARE_BUF `,
:ref:`VIDIOC_QBUF` or
:ref:`VIDIOC_DQBUF ` ioctl is called.
-* .. _`V4L2-BUF-FLAG-NO-CACHE-INVALIDATE`:
+* .. _`V4L2-BUF-FLAG-NO-CACHE-SYNC`:
- - ``V4L2_BUF_FLAG_NO_CACHE_INVALIDATE``
+ - ``V4L2_BUF_FLAG_NO_CACHE_SYNC``
- 0x0800
- - Caches do not have to be invalidated for this buffer. Typically
- applications shall use this flag if the data captured in the
- buffer is not going to be touched by the CPU, instead the buffer
- will, probably, be passed on to a DMA-capable hardware unit for
- further processing or output.
-* .. _`V4L2-BUF-FLAG-NO-CACHE-CLEAN`:
-
- - ``V4L2_BUF_FLAG_NO_CACHE_CLEAN``
- - 0x1000
- - Caches do not have to be cleaned for this buffer. Typically
- applications shall use this flag for output buffers if the data in
- this buffer has not been created by the CPU but by some
- DMA-capable unit, in which case caches have not been used.
+ - Do not perform CPU cache synchronisation operations when the buffer is
+ queued or dequeued. The user is responsible for the correct use of
+ this flag. It should be only used when the buffer is not accessed
+ using the CPU, e.g. the buffer is written to by a hardware block and
+ then read by another one, in which case the flag should be set in both
+ :ref:`VIDIOC_QBUF` and :ref:`VIDIOC_DQBUF` ioctls. The flag has no
+ effect on some devices / architectures.
* .. _`V4L2-BUF-FLAG-LAST`:
- ``V4L2_BUF_FLAG_LAST``
diff --git a/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst
b/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst
index bdcfd9f..80aeb7e 100644
--- a/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst
+++ b/Documentation/media/uapi/v4l/vidioc-prepare-buf.rst
@@ -36,9 +36,8 @@ pass ownership of the buffer to the driver before actually
enqueuing it,
using the :ref:`VIDIOC_QBUF` ioctl, and to prepare it for future I/O. Such
preparations may include cache invalidation or cleaning. Performing them
in advance saves time during the actual I/O. In case such cache
-operations are not required, the application can use one of
-``V4L2_BUF_FLAG_NO_CACHE_INVALIDATE`` and
-``V4L2_BUF_FLAG_NO_CACHE_CLEAN`` flags to skip the respective step.
+operations are not required, the application can use the
+``V4L2_BUF_FLAG_NO_CACHE_SYNC`` flag to skip the cache synchronization step.
The struct :c:type:`v4l2_buffer` structure is specified in
:ref:`buffer`.
diff --git a/include/trace/events/v4l2.h b/include/trace/events/v4l2.h
index ee7754c..fb9ad7b 100644
--- a/include/trace/events/v4l2.h
+++ b/include/trace/events/v4l2.h
@@ -80,8 +80,7 @@ SHOW_FIELD
{ V4L2_BUF_FLAG_ERROR, "ERROR" }, \
{ V4L2_BUF_FLAG_TIMECODE,"TIMECODE" },\
{ V4L2_BUF_FLAG_PREPARED,"PREPARED" },\
- { V4L2_BUF_FLAG_NO_CACHE_INVALIDATE, "NO_CACHE_INVALIDATE" }, \
- { V4L2_BUF_FLAG_NO_CACHE_CLEAN, "NO_CACHE_CLEAN" }, \
+ { V4L2_BUF_FLAG_NO_CACHE_SYNC, "NO_CACHE_SYNC" }, \
{ V4L2_BUF_FLAG_TIMESTAMP_MASK, "TIMESTAMP_MASK" }, \
{ V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN, "TIMESTAMP_UNKNOWN" }, \
[PATCH 1/4] nouveau_hwmon: migrate to hwmon_device_register_with_info
This patch introduces the structure "struct hwmon_ops" and sets up the
".visible" operation.
Is also a preparation for the next patch.
--- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig 2017-04-12
19:18:09.638073562 +0200
+++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c 2017-04-12
19:19:44.244797202 +0200
@@ -692,6 +692,78 @@ static const struct attribute_group hwmo
static const struct attribute_group hwmon_power_caps_attrgroup = {
.attrs = hwmon_power_caps_attributes,
};
+
+static const u32 nouveau_config_chip[] = {
+ HWMON_C_UPDATE_INTERVAL,
+ 0
+};
+
+static const u32 nouveau_config_in[] = {
+ HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX | HWMON_I_LABEL,
+ 0
+};
+
+static const u32 nouveau_config_temp[] = {
+ HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
+ HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_EMERGENCY |
+ HWMON_T_EMERGENCY_HYST,
+ 0
+};
+
+static const u32 nouveau_config_fan[] = {
+ HWMON_F_INPUT,
+ 0
+};
+
+static const u32 nouveau_config_pwm[] = {
+ HWMON_PWM_INPUT | HWMON_PWM_ENABLE,
+ 0
+};
+
+static const u32 nouveau_config_power[] = {
+ HWMON_P_INPUT | HWMON_P_CAP_MAX | HWMON_P_CRIT,
+ 0
+};
+
+static const struct hwmon_channel_info nouveau_chip = {
+ .type = hwmon_chip,
+ .config = nouveau_config_chip,
+};
+
+static const struct hwmon_channel_info nouveau_temp = {
+ .type = hwmon_temp,
+ .config = nouveau_config_temp,
+};
+
+static const struct hwmon_channel_info nouveau_fan = {
+ .type = hwmon_fan,
+ .config = nouveau_config_fan,
+};
+
+static const struct hwmon_channel_info nouveau_in = {
+ .type = hwmon_in,
+ .config = nouveau_config_in,
+};
+
+static const struct hwmon_channel_info nouveau_pwm = {
+ .type = hwmon_pwm,
+ .config = nouveau_config_pwm,
+};
+
+static const struct hwmon_channel_info nouveau_power = {
+ .type = hwmon_power,
+ .config = nouveau_config_power,
+};
+
+static const struct hwmon_channel_info *nouveau_info[] = {
+ &nouveau_chip,
+ &nouveau_temp,
+ &nouveau_fan,
+ &nouveau_in,
+ &nouveau_pwm,
+ &nouveau_power,
+ NULL
+};
#endif
int
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 06/14] vb2: dma-contig: Assign DMA attrs for a buffer unconditionally
attrs used to be a pointer and the caller of vb2_dc_alloc() could
optionally provide it, or NULL. This was when struct dma_attrs was used
to describe DMA attributes rather than an unsigned long value. There is no
longer a need to maintain the condition, assign the value unconditionally.
There is no functional difference because the memory was initialised to
zero anyway.
Fixes: 00085f1e ("dma-mapping: use unsigned long for dma_attrs")
Signed-off-by: Sakari Ailus
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index 30082a4..a8a46a8 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -149,8 +149,7 @@ static void *vb2_dc_alloc(struct device *dev, unsigned long
attrs,
if (!buf)
return ERR_PTR(-ENOMEM);
- if (attrs)
- buf->attrs = attrs;
+ buf->attrs = attrs;
buf->cookie = dma_alloc_attrs(dev, size, &buf->dma_addr,
GFP_KERNEL | gfp_flags, buf->attrs);
if (!buf->cookie) {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v9] drm: Unplug drm device when unregistering it
Hi Sean,
On 04/12/2017 11:03 PM, Sean Paul wrote:
On Wed, Apr 12, 2017 at 04:56:21PM +0800, Jeffy Chen wrote:
After unbinding drm, the user space may still owns the drm dev fd, and
may still be able to call drm ioctl.
We're using an unplugged state to prevent something like that, so let's
reuse it here.
Also drop drm_unplug_dev, because it would be unused after other changes.
Signed-off-by: Jeffy Chen
Changes in v9:
Move drm_device_set_plug_state into drm_drv.c .
Changes in v8:
Fix hang when unregistering drm dev with open_count 0.
Changes in v7:
Add drm_device_set_plug_state helper.
Changes in v6:
Reuse unplug status.
Changes in v5:
Fix wrong git account.
Changes in v2:
Fix some commit messages.
Hi Jeffy,
A couple bookkeeping notes:
- Please end the commit message with your Signed-off-by tag
- No need to send cover letters for one patch. All info should be in the commit
message. Include superfluous information (such as tested on 4.4 kernel) after
---
hmm...i'm using u-boot's patman tool to send patches. and the changelogs
would be formated by the tool.
i'll switch changelogs to drm style.
---
drivers/gpu/drm/drm_drv.c | 26 ++
drivers/gpu/drm/udl/udl_drv.c | 2 +-
include/drm/drmP.h| 6 --
include/drm/drm_drv.h | 1 -
4 files changed, 11 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index b5c6bb4..e1da4d1 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -355,22 +355,6 @@ void drm_put_dev(struct drm_device *dev)
}
EXPORT_SYMBOL(drm_put_dev);
-void drm_unplug_dev(struct drm_device *dev)
-{
- /* for a USB device */
- drm_dev_unregister(dev);
-
- mutex_lock(&drm_global_mutex);
-
- drm_device_set_unplugged(dev);
-
- if (dev->open_count == 0) {
- drm_put_dev(dev);
- }
- mutex_unlock(&drm_global_mutex);
-}
-EXPORT_SYMBOL(drm_unplug_dev);
-
/*
* DRM internal mount
* We want to be able to allocate our own "struct address_space" to control
@@ -733,6 +717,13 @@ static void remove_compat_control_link(struct drm_device
*dev)
kfree(name);
}
+static inline void drm_device_set_plug_state(struct drm_device *dev,
+bool plugged)
+{
+ smp_wmb();
+ atomic_set(&dev->unplugged, !plugged);
+}
+
/**
* drm_dev_register - Register DRM device
* @dev: Device to register
@@ -787,6 +778,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long
flags)
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_register_all(dev);
+ drm_device_set_plug_state(dev, true);
+
ret = 0;
DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
@@ -826,6 +819,7 @@ void drm_dev_unregister(struct drm_device *dev)
drm_lastclose(dev);
dev->registered = false;
+ drm_device_set_plug_state(dev, false);
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_unregister_all(dev);
diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
index cd8b017..5dbd916 100644
--- a/drivers/gpu/drm/udl/udl_drv.c
+++ b/drivers/gpu/drm/udl/udl_drv.c
@@ -108,7 +108,7 @@ static void udl_usb_disconnect(struct usb_interface
*interface)
drm_kms_helper_poll_disable(dev);
udl_fbdev_unplug(dev);
udl_drop_usb(dev);
- drm_unplug_dev(dev);
+ drm_dev_unregister(dev);
I think you need drm_dev_unref here as well.
right, will do.
Sean
}
/*
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 3bfafcd..980a204 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -488,12 +488,6 @@ static __inline__ int drm_core_check_feature(struct
drm_device *dev,
return ((dev->driver->driver_features & feature) ? 1 : 0);
}
-static inline void drm_device_set_unplugged(struct drm_device *dev)
-{
- smp_wmb();
- atomic_set(&dev->unplugged, 1);
-}
-
static inline int drm_device_is_unplugged(struct drm_device *dev)
{
int ret = atomic_read(&dev->unplugged);
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 0fefc3f..eb63078 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -544,7 +544,6 @@ void drm_dev_unregister(struct drm_device *dev);
void drm_dev_ref(struct drm_device *dev);
void drm_dev_unref(struct drm_device *dev);
void drm_put_dev(struct drm_device *dev);
-void drm_unplug_dev(struct drm_device *dev);
int drm_dev_set_unique(struct drm_device *dev, const char *name);
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 00/14] vb2: Handle user cache hints, allow drivers to choose cache coherency
Hello,
This is a rebased and partially reworked version of the vb2 cache hints
support patch series posted by Laurent more three months ago. The patches
have been modified as needed by the upstream changes. There are a number
of other changes as well. Since then, patch ccc66e73 ("ARM: 8508/2:
videobuf2-dc: Let drivers specify DMA attrs") that supposedly added DMA
attribute support for videobuf2-dma-contig has been merged. For dma-contig
memory type, this patchset addresses issues in that patch instead of
providing support for the feature from scratch. It also adds support for
USERPTR buffer type and makes necessary changes to dma-sg memory type as
well. Details below.
I'm still posting this patchset as RFC as the dma-sg patch hasn't been
tested apart from compiling it. Otherwise the subject line would have
PATCH instead of RFC. Testing especially on a device using dma-sg would be
beneficial.
The videobuf2 memory managers use the DMA mapping API to handle cache
synchronization on systems that require them transparently for drivers. As
cache operations are expensive, system performances can be impacted. Cache
synchronization can't be skipped altogether if we want to retain correct
behaviour, but optimizations are possible in cases related to buffer sharing
between multiple devices without CPU access to the memory.
The first optimization covers cases where the memory never needs to be
accessed by the CPU (neither in kernelspace nor in userspace). In those cases,
as no CPU memory mappings exist, cache synchronization can be skipped. The
situation could be detected in the kernel as we have enough information to
determine whether CPU mappings for kernelspace or userspace exist (in the
first case because drivers should request them explicitly, in the second case
because the mmap() handler hasn't been invoked). This optimization is not
implemented currently but should at least be prototyped as it could improve
performances automatically in a large number of cases.
The second class of optimizations cover cases where the memory sometimes needs
to be accessed by the CPU. In those cases memory mapping must be created and
cache handled, but cache synchronization could be skipped for buffer that are
not touched by the CPU.
By default the following cache synchronization operations need to be performed
related to the buffer management ioctls. For simplicity means of QBUF below
apply to buf VIDIOC_QBUF and VIDIOC_PREPARE_BUF.
| QBUF | DQBUF
CAPTURE | Invalidate| Invalidate (*)
OUTPUT | Clean | -
(*) for systems using speculative pre-fetching only
The following cases can be optimized.
1. CAPTURE, the CPU has not written to the buffer before QBUF
Cache invalidation can be skipped at QBUF time, but becomes required at
DQBUF time on all systems, regardless of whether they use speculative
prefetching.
2. CAPTURE, the CPU will not read from the buffer after DQBUF
Cache invalidation can be skipped at DQBUF time.
3. CAPTURE, combination of (1) and (2)
Cache invalidation can be skipped at both QBUF and DQBUF time.
4. OUTPUT, the CPU has not written to the buffer before QBUF
Cache clean can be skipped at QBUF time.
The kernel can't detect thoses situations automatically and thus requires
hints from userspace to decide whether cache synchronization can be skipped.
It should be noted that those hints might not be honoured. In particular, if
userspace hints that it hasn't touched the buffer with the CPU, drivers might
need to perform memory accesses themselves (adding JPEG or MPEG headers to
buffers is a common case where CPU access could be needed in the kernel), in
which case the userspace hints will be ignored.
Getting the hints wrong will result in data corruption. Userspace applications
are allowed to shoot themselves in the foot, but driver are responsible for
deciding whether data corruption can pose a risk to the system in general. For
instance if the device could be made to crash, or behave in a way that would
jeopardize system security, reliability or performances, when fed with invalid
data, cache synchronization shall not be skipped solely due to possibly
incorrect userspace hints.
The V4L2 API defines two flags, V4L2_BUF_FLAG_NO_CACHE_INVALIDATE and
V4L2_BUF_FLAG_NO_CACHE_SYNC, that can be used to provide cache-related hints
to the kernel. However, no kernel has ever implemented support for those flags
that are thus most likely unused.
A single flag is enough to cover all the optimization cases described above,
provided we keep track of the flag being set at QBUF time to force cache
invalidation at DQBUF time for case (1) if the flag isn't set at DQBUF time.
This patch series thus cleans up the userspace API and merges both flags into
a single one.
One potential issue with case (1) is that cache invalidation at DQBUF time for
CAPTURE buffers isn't fully under the control of video
[RFC v3 08/14] vb2: dma-contig: Don't warn on failure in obtaining scatterlist
vb2_dc_get_base_sgt() which obtains the scatterlist already prints
information on why the scatterlist could not be obtained.
Also, remove the useless warning of a failed kmalloc().
Signed-off-by: Sakari Ailus
Reviewed-by: Laurent Pinchart
Acked-by: Hans Verkuil
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index ddbbcf0..22636cd 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -370,10 +370,8 @@ static struct sg_table *vb2_dc_get_base_sgt(struct
vb2_dc_buf *buf)
struct sg_table *sgt;
sgt = kmalloc(sizeof(*sgt), GFP_KERNEL);
- if (!sgt) {
- dev_err(buf->dev, "failed to alloc sg table\n");
+ if (!sgt)
return NULL;
- }
ret = dma_get_sgtable_attrs(buf->dev, sgt, buf->cookie, buf->dma_addr,
buf->size, buf->attrs);
@@ -400,7 +398,7 @@ static struct dma_buf *vb2_dc_get_dmabuf(void *buf_priv,
unsigned long flags)
if (!buf->dma_sgt)
buf->dma_sgt = vb2_dc_get_base_sgt(buf);
- if (WARN_ON(!buf->dma_sgt))
+ if (!buf->dma_sgt)
return NULL;
dbuf = dma_buf_export(&exp_info);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/4] nouveau_hwmon: migrate to hwmon_device_register_with_info
Hi again,
I've split the patches as Karol Herbst suggested.
I hope now it's fine.
This series of patches introduce the new hwmon_device_register_with_info
and gets rid of the old hwmon_device_register.
This patch adds the default sensors with their possible config values.
Just to prepare for the next patches
--- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig 2017-04-12
19:18:09.638073562 +0200
+++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c 2017-04-12
19:19:44.244797202 +0200
@@ -692,6 +692,78 @@ static const struct attribute_group hwmo
static const struct attribute_group hwmon_power_caps_attrgroup = {
.attrs = hwmon_power_caps_attributes,
};
+
+static const u32 nouveau_config_chip[] = {
+ HWMON_C_UPDATE_INTERVAL,
+ 0
+};
+
+static const u32 nouveau_config_in[] = {
+ HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX | HWMON_I_LABEL,
+ 0
+};
+
+static const u32 nouveau_config_temp[] = {
+ HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
+ HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_EMERGENCY |
+ HWMON_T_EMERGENCY_HYST,
+ 0
+};
+
+static const u32 nouveau_config_fan[] = {
+ HWMON_F_INPUT,
+ 0
+};
+
+static const u32 nouveau_config_pwm[] = {
+ HWMON_PWM_INPUT | HWMON_PWM_ENABLE,
+ 0
+};
+
+static const u32 nouveau_config_power[] = {
+ HWMON_P_INPUT | HWMON_P_CAP_MAX | HWMON_P_CRIT,
+ 0
+};
+
+static const struct hwmon_channel_info nouveau_chip = {
+ .type = hwmon_chip,
+ .config = nouveau_config_chip,
+};
+
+static const struct hwmon_channel_info nouveau_temp = {
+ .type = hwmon_temp,
+ .config = nouveau_config_temp,
+};
+
+static const struct hwmon_channel_info nouveau_fan = {
+ .type = hwmon_fan,
+ .config = nouveau_config_fan,
+};
+
+static const struct hwmon_channel_info nouveau_in = {
+ .type = hwmon_in,
+ .config = nouveau_config_in,
+};
+
+static const struct hwmon_channel_info nouveau_pwm = {
+ .type = hwmon_pwm,
+ .config = nouveau_config_pwm,
+};
+
+static const struct hwmon_channel_info nouveau_power = {
+ .type = hwmon_power,
+ .config = nouveau_config_power,
+};
+
+static const struct hwmon_channel_info *nouveau_info[] = {
+ &nouveau_chip,
+ &nouveau_temp,
+ &nouveau_fan,
+ &nouveau_in,
+ &nouveau_pwm,
+ &nouveau_power,
+ NULL
+};
#endif
int
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3 14/14] vb2: Improve struct vb2_mem_ops documentation; alloc and put are for MMAP
The alloc() and put() ops are for MMAP buffers only. Document it. Signed-off-by: Sakari Ailus Acked-by: Hans Verkuil Reviewed-by: Laurent Pinchart --- include/media/videobuf2-core.h | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index 08f1d0e..dd67ae6 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -46,16 +46,16 @@ struct vb2_threadio_data; /** * struct vb2_mem_ops - memory handling/memory allocator operations - * @alloc: allocate video memory and, optionally, allocator private data, - * return ERR_PTR() on failure or a pointer to allocator private, - * per-buffer data on success; the returned private structure - * will then be passed as @buf_priv argument to other ops in this - * structure. Additional gfp_flags to use when allocating the - * are also passed to this operation. These flags are from the - * gfp_flags field of vb2_queue. - * @put: inform the allocator that the buffer will no longer be used; - * usually will result in the allocator freeing the buffer (if - * no other users of this buffer are present); the @buf_priv + * @alloc: allocate video memory for an MMAP buffer and, optionally, + * allocator private data, return ERR_PTR() on failure or a pointer + * to allocator private, per-buffer data on success; the returned + * private structure will then be passed as @buf_priv argument to + * other ops in this structure. Additional gfp_flags to use when + * allocating the memory are also passed to this operation. These + * flags are from the gfp_flags field of vb2_queue. + * @put: inform the allocator that the MMAP buffer will no longer be + * used; usually will result in the allocator freeing the buffer + * (if no other users of this buffer are present); the @buf_priv * argument is the allocator private per-buffer structure * previously returned from the alloc callback. * @get_dmabuf: acquire userspace memory for a hardware operation; used for -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100673] Tonga agd5f drm-next-4.12-wip xorg segfault on startx
https://bugs.freedesktop.org/show_bug.cgi?id=100673 Bug ID: 100673 Summary: Tonga agd5f drm-next-4.12-wip xorg segfault on startx Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: adf.li...@gmail.com Created attachment 130829 --> https://bugs.freedesktop.org/attachment.cgi?id=130829&action=edit xorg log with segfault With current agd5f drm-next-4.12-wip I get a segfault on startx (xserver 1.19.3, git ddx,mesa,llvm. Log attached. On the previous incarnation of the same kernel I can startx, but there are a lot of warnings in dmesg every time the screen is turned on - ie. startx or coming out of dpms. dmesg attached. Don't know when I'll get time to bisect, so just getting these reported now. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100673] Tonga agd5f drm-next-4.12-wip xorg segfault on startx
https://bugs.freedesktop.org/show_bug.cgi?id=100673 --- Comment #1 from Andy Furniss --- Created attachment 130830 --> https://bugs.freedesktop.org/attachment.cgi?id=130830&action=edit dmesg with lots of warnings on startx (older kernel) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip boot: 117 boots: 4 failed, 112 passed with 1 offline (v4.11-rc6-1945-g6184edce6665)
drm-tip/drm-tip boot: 117 boots: 4 failed, 112 passed with 1 offline (v4.11-rc6-1945-g6184edce6665) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1945-g6184edce6665/ Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1945-g6184edce6665/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1945-g6184edce6665 Git Commit: 6184edce6665aee9c9131149a7b9314a1313eaf9 Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Tested: 15 unique boards, 8 SoC families, 23 builds out of 207 Boot Failures Detected: arm64: allmodconfig meson-gxbb-p200: 1 failed lab x86: allnoconfig minnowboard-max: 1 failed lab tinyconfig minnowboard-max: 1 failed lab arm: multi_v7_defconfig+CONFIG_SMP=n exynos5250-snow: 1 failed lab Offline Platforms: x86: allmodconfig: minnowboard-max: 1 offline lab --- For more info write to ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1949-g74e7a6859913)
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1949-g74e7a6859913) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1949-g74e7a6859913/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1949-g74e7a6859913 Git Commit: 74e7a68599131906746cd65229beb772697e50f0 Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Built: 4 unique architectures Build Failures Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: FAIL defconfig: FAIL defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: FAIL defconfig+CONFIG_KASAN=y: FAIL defconfig+CONFIG_LKDTM=y: FAIL defconfig+CONFIG_OF_UNITTEST=y: FAIL defconfig+CONFIG_RANDOMIZE_BASE=y: FAIL arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: FAIL multi_v7_defconfig+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL multi_v7_defconfig+CONFIG_EFI=y: FAIL multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_LKDTM=y: FAIL multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: FAIL multi_v7_defconfig+CONFIG_SMP=n: FAIL multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: FAIL tegra_defconfig: FAIL x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: FAIL allmodconfig+CONFIG_OF=n: FAIL Errors and Warnings Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: 1 error defconfig: 1 error defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: 1 error defconfig+CONFIG_KASAN=y: 1 error, 4 warnings defconfig+CONFIG_LKDTM=y: 1 error defconfig+CONFIG_OF_UNITTEST=y: 1 error defconfig+CONFIG_RANDOMIZE_BASE=y: 1 error arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: 1 error, 4 warnings multi_v7_defconfig+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_LKDTM=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_SMP=n: 1 error, 4 warnings multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 1 error, 4 warnings tegra_defconfig: 1 error x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: 1 error allmodconfig+CONFIG_OF=n: 1 error defconfig+CONFIG_KASAN=y: 5 warnings Errors summary: 20 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: redefinition of 'nv137_chipset' Warnings summary: 9 arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI 9 arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI 9 arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI 9 arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP 1 net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 bytes is larger than 2048 bytes [-Wframe-larger-than=] Detailed per-defconfig build reports: acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches --
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1950-gf1faf571d953)
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1950-gf1faf571d953) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1950-gf1faf571d953/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1950-gf1faf571d953 Git Commit: f1faf571d9530365a34fe33a3efa3fb224661692 Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Built: 4 unique architectures Build Failures Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: FAIL defconfig: FAIL defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: FAIL defconfig+CONFIG_KASAN=y: FAIL defconfig+CONFIG_LKDTM=y: FAIL defconfig+CONFIG_OF_UNITTEST=y: FAIL defconfig+CONFIG_RANDOMIZE_BASE=y: FAIL arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: FAIL multi_v7_defconfig+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL multi_v7_defconfig+CONFIG_EFI=y: FAIL multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_LKDTM=y: FAIL multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: FAIL multi_v7_defconfig+CONFIG_SMP=n: FAIL multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: FAIL tegra_defconfig: FAIL x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: FAIL allmodconfig+CONFIG_OF=n: FAIL Errors and Warnings Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: 1 error defconfig: 1 error defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: 1 error defconfig+CONFIG_KASAN=y: 1 error, 4 warnings defconfig+CONFIG_LKDTM=y: 1 error defconfig+CONFIG_OF_UNITTEST=y: 1 error defconfig+CONFIG_RANDOMIZE_BASE=y: 1 error arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: 1 error, 4 warnings multi_v7_defconfig+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_LKDTM=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_SMP=n: 1 error, 4 warnings multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 1 error, 4 warnings tegra_defconfig: 1 error x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: 1 error allmodconfig+CONFIG_OF=n: 1 error defconfig+CONFIG_KASAN=y: 5 warnings Errors summary: 20 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: redefinition of 'nv137_chipset' Warnings summary: 9 arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI 9 arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI 9 arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI 9 arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP 1 net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 bytes is larger than 2048 bytes [-Wframe-larger-than=] Detailed per-defconfig build reports: acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches --
KMS question
Hi, how can I disable the behaviour in the KMS drivers that enables all outputs at once? It is very annoying that on a POS machine with an 1024x768 LVDS and a 800x480 secondary monitor (both built-in) the KMS driver wakes up both. Then the framebuffer console and plymouth use both screens, making the primary output very odd with only the top-left part used by the boot splash. I would like the boot splash to be shown only on the primary output at its full resolution instead of on all outputs using the smallest common rectangle. Is there a kernel command line configuration that achieves this? The device in question uses the gma500 kernel driver but the same behaviour is observed with the i915 and radeon drivers. Thanks in advance, Zoltán Böszörmenyi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100673] Tonga agd5f drm-next-4.12-wip xorg segfault on startx
https://bugs.freedesktop.org/show_bug.cgi?id=100673 --- Comment #2 from Alex Deucher --- (In reply to Andy Furniss from comment #1) > Created attachment 130830 [details] > dmesg with lots of warnings on startx (older kernel) This was fixed here: https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.12-wip&id=53552d5df6694f68f276b2e86f8162d0ef7cad93 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KMS question
On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan wrote: > Hi, > > how can I disable the behaviour in the KMS drivers > that enables all outputs at once? > > It is very annoying that on a POS machine with an > 1024x768 LVDS and a 800x480 secondary monitor (both built-in) > the KMS driver wakes up both. Then the framebuffer console > and plymouth use both screens, making the primary output > very odd with only the top-left part used by the boot splash. > > I would like the boot splash to be shown only on the primary > output at its full resolution instead of on all outputs using > the smallest common rectangle. > > Is there a kernel command line configuration that achieves this? > > The device in question uses the gma500 kernel driver but the same > behaviour is observed with the i915 and radeon drivers. > The problem is fbdev is not multi-head aware. The fbdev emulation in the KMS drivers attempts to light up all monitors so that something shows up on all heads. If you really want different per head configurations, you need to use the KMS API directly. As a workaround, you can use the kernel command line to disable the output you don't want to be lit up. See: https://wiki.archlinux.org/index.php/kernel_mode_setting for more info. basically add video=TV-1:d to disable the output in question. Replace TV-1 with whatever connector you want to disable. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] omapdrm: fences and zpos
Hi Tomi, On Wednesday 05 Apr 2017 09:52:36 Tomi Valkeinen wrote: > On 03/01/17 14:06, Tomi Valkeinen wrote: > > I got this with your series. AM5 EVM, dual display, I run "kmstest --flip" > > and then exit by pressing enter, which is when I see the warning. It > > happens only sometimes, but having lots of cpu load (I used "stress -c > > 4") makes the driver spam the warning. > > > > [ 67.207223] [ cut here ] > > [ 67.211937] WARNING: CPU: 1 PID: 324 at > > drivers/gpu/drm/omapdrm/omap_gem.c:1085 omap_gem_free_object+0x270/0x2d4 > > [omapdrm] [ 67.223138] Modules linked in: omapdrm drm_kms_helper drm > > panel_dsi_cm panel_dpi connector_analog_tv connector_dvi connector_hdmi > > encoder_tp d12s015 encoder_tfp410 omapdss cfbfillrect cfbimgblt > > cfbcopyarea [last unloaded: omapdss] [ 67.243953] CPU: 1 PID: 324 Comm: > > kmstest Not tainted 4.9.0-rc8-00163-g55f4a6c2d775 #135 > > After rebasing to latest drm-next, I no longer see this, but the kms++ > test script hangs when exiting it. And then I get BUGs from the kernel. > Do you know if all the dependencies are in drm-next? I've just rebased the patches on top of drm-next and I can't reproduce any of these two issues. I've ran kmstest --flip for 250 frames in a loop for half an hour, with and without CPU load (with 'stress -c 4') and everything works fine. I'll repost the rebased patches now. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 87738] [OpenCL] Please add Image support
https://bugs.freedesktop.org/show_bug.cgi?id=87738 --- Comment #2 from Vedran Miletić --- In case anyone works on it, I have saved Zoltan Gillian's patches here: https://github.com/vedranmiletic/mesa/tree/r600-image-support -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 88886] GPU fault detected on luxmark the Room test with AMD Tahiti
https://bugs.freedesktop.org/show_bug.cgi?id=6 Vedran Miletić changed: What|Removed |Added Blocks||99553 --- Comment #8 from Vedran Miletić --- Does this bug still occur? Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99553 [Bug 99553] Tracker bug for runnning OpenCL applications on Clover -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Vedran Miletić changed: What|Removed |Added Depends on||6 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=6 [Bug 6] GPU fault detected on luxmark the Room test with AMD Tahiti -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KMS question
2017-04-13 16:05 keltezéssel, Alex Deucher írta: On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan wrote: Hi, how can I disable the behaviour in the KMS drivers that enables all outputs at once? It is very annoying that on a POS machine with an 1024x768 LVDS and a 800x480 secondary monitor (both built-in) the KMS driver wakes up both. Then the framebuffer console and plymouth use both screens, making the primary output very odd with only the top-left part used by the boot splash. I would like the boot splash to be shown only on the primary output at its full resolution instead of on all outputs using the smallest common rectangle. Is there a kernel command line configuration that achieves this? The device in question uses the gma500 kernel driver but the same behaviour is observed with the i915 and radeon drivers. The problem is fbdev is not multi-head aware. The fbdev emulation in the KMS drivers attempts to light up all monitors so that something shows up on all heads. If you really want different per head configurations, you need to use the KMS API directly. As a workaround, you can use the kernel command line to disable the output you don't want to be lit up. See: https://wiki.archlinux.org/index.php/kernel_mode_setting for more info. basically add video=TV-1:d to disable the output in question. Replace TV-1 with whatever connector you want to disable. I tried adding video=DVI-D-1:d to the kernel command line. The effect is while the second output is indeed disabled, the framebuffer console still takes the second output's resolution into account and the boot splash is still using only the top-left 800x480 part of the 1024x768 primary screen. Also, the secondary screen got disabled also in X which is not desired. Can I wake it up under X somehow? This device is using the modesetting DDX driver. Thanks, Zoltán Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 87738] [OpenCL] Please add Image support
https://bugs.freedesktop.org/show_bug.cgi?id=87738 --- Comment #3 from Vedran Miletić --- funfunctor has also worked on it a bit: https://cgit.freedesktop.org/~funfunctor/mesa/log/?h=clover-image-support https://cgit.freedesktop.org/~funfunctor/mesa/log/?h=clover-image-support-enabled -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v3.1 05/14] vb2: Anticipate queue specific DMA attributes for USERPTR buffers
The DMA attributes were available for the memop implementation for MMAP
buffers but not for USERPTR buffers. Do the same for USERPTR. This patch
makes no functional changes.
Signed-off-by: Sakari Ailus
---
since RFC v1:
- Add missing q->dma_attrs argument to call_ptr_memop(vb, get_userptr...
drivers/media/v4l2-core/videobuf2-core.c | 2 +-
drivers/media/v4l2-core/videobuf2-dma-contig.c | 3 ++-
drivers/media/v4l2-core/videobuf2-dma-sg.c | 3 ++-
drivers/media/v4l2-core/videobuf2-vmalloc.c| 3 ++-
include/media/videobuf2-core.h | 3 ++-
5 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index e866115..c659b64 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -1025,7 +1025,7 @@ static int __prepare_userptr(struct vb2_buffer *vb, const
void *pb)
mem_priv = call_ptr_memop(vb, get_userptr,
q->alloc_devs[plane] ? : q->dev,
planes[plane].m.userptr,
- planes[plane].length, dma_dir);
+ planes[plane].length, dma_dir, q->dma_attrs);
if (IS_ERR(mem_priv)) {
dprintk(1, "failed acquiring userspace memory for plane
%d\n",
plane);
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index d29a07f..30082a4 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -475,7 +475,8 @@ static inline dma_addr_t vb2_dc_pfn_to_dma(struct device
*dev, unsigned long pfn
#endif
static void *vb2_dc_get_userptr(struct device *dev, unsigned long vaddr,
- unsigned long size, enum dma_data_direction dma_dir)
+ unsigned long size, enum dma_data_direction dma_dir,
+ unsigned long attrs)
{
struct vb2_dc_buf *buf;
struct frame_vector *vec;
diff --git a/drivers/media/v4l2-core/videobuf2-dma-sg.c
b/drivers/media/v4l2-core/videobuf2-dma-sg.c
index 29fde1a..102ddb2 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-sg.c
@@ -220,7 +220,8 @@ static void vb2_dma_sg_finish(void *buf_priv)
static void *vb2_dma_sg_get_userptr(struct device *dev, unsigned long vaddr,
unsigned long size,
- enum dma_data_direction dma_dir)
+ enum dma_data_direction dma_dir,
+ unsigned long dma_attrs)
{
struct vb2_dma_sg_buf *buf;
struct sg_table *sgt;
diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c
b/drivers/media/v4l2-core/videobuf2-vmalloc.c
index f83253a..a4914fc 100644
--- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
+++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
@@ -73,7 +73,8 @@ static void vb2_vmalloc_put(void *buf_priv)
static void *vb2_vmalloc_get_userptr(struct device *dev, unsigned long vaddr,
unsigned long size,
-enum dma_data_direction dma_dir)
+enum dma_data_direction dma_dir,
+unsigned long dma_attrs)
{
struct vb2_vmalloc_buf *buf;
struct frame_vector *vec;
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index cb97c22..4172f6e 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -122,7 +122,8 @@ struct vb2_mem_ops {
void*(*get_userptr)(struct device *dev, unsigned long vaddr,
unsigned long size,
- enum dma_data_direction dma_dir);
+ enum dma_data_direction dma_dir,
+ unsigned long dma_attrs);
void(*put_userptr)(void *buf_priv);
void(*prepare)(void *buf_priv);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KMS question
On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan wrote: > 2017-04-13 16:05 keltezéssel, Alex Deucher írta: >> >> On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan wrote: >>> >>> Hi, >>> >>> how can I disable the behaviour in the KMS drivers >>> that enables all outputs at once? >>> >>> It is very annoying that on a POS machine with an >>> 1024x768 LVDS and a 800x480 secondary monitor (both built-in) >>> the KMS driver wakes up both. Then the framebuffer console >>> and plymouth use both screens, making the primary output >>> very odd with only the top-left part used by the boot splash. >>> >>> I would like the boot splash to be shown only on the primary >>> output at its full resolution instead of on all outputs using >>> the smallest common rectangle. >>> >>> Is there a kernel command line configuration that achieves this? >>> >>> The device in question uses the gma500 kernel driver but the same >>> behaviour is observed with the i915 and radeon drivers. >>> >> >> The problem is fbdev is not multi-head aware. The fbdev emulation in >> the KMS drivers attempts to light up all monitors so that something >> shows up on all heads. If you really want different per head >> configurations, you need to use the KMS API directly. As a >> workaround, you can use the kernel command line to disable the output >> you don't want to be lit up. See: >> https://wiki.archlinux.org/index.php/kernel_mode_setting >> for more info. basically add video=TV-1:d to disable the output in >> question. Replace TV-1 with whatever connector you want to disable. > > > I tried adding video=DVI-D-1:d to the kernel command line. > > The effect is while the second output is indeed disabled, the > framebuffer console still takes the second output's resolution > into account and the boot splash is still using only the top-left > 800x480 part of the 1024x768 primary screen. > > Also, the secondary screen got disabled also in X which is not desired. > Can I wake it up under X somehow? This device is using the modesetting > DDX driver. Can you enable it via randr? Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KMS question
On Thu, Apr 13, 2017 at 11:36 AM, Alex Deucher wrote: > On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan wrote: >> 2017-04-13 16:05 keltezéssel, Alex Deucher írta: >>> >>> On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan wrote: Hi, how can I disable the behaviour in the KMS drivers that enables all outputs at once? It is very annoying that on a POS machine with an 1024x768 LVDS and a 800x480 secondary monitor (both built-in) the KMS driver wakes up both. Then the framebuffer console and plymouth use both screens, making the primary output very odd with only the top-left part used by the boot splash. I would like the boot splash to be shown only on the primary output at its full resolution instead of on all outputs using the smallest common rectangle. Is there a kernel command line configuration that achieves this? The device in question uses the gma500 kernel driver but the same behaviour is observed with the i915 and radeon drivers. >>> >>> The problem is fbdev is not multi-head aware. The fbdev emulation in >>> the KMS drivers attempts to light up all monitors so that something >>> shows up on all heads. If you really want different per head >>> configurations, you need to use the KMS API directly. As a >>> workaround, you can use the kernel command line to disable the output >>> you don't want to be lit up. See: >>> https://wiki.archlinux.org/index.php/kernel_mode_setting >>> for more info. basically add video=TV-1:d to disable the output in >>> question. Replace TV-1 with whatever connector you want to disable. >> >> >> I tried adding video=DVI-D-1:d to the kernel command line. >> >> The effect is while the second output is indeed disabled, the >> framebuffer console still takes the second output's resolution >> into account and the boot splash is still using only the top-left >> 800x480 part of the 1024x768 primary screen. >> >> Also, the secondary screen got disabled also in X which is not desired. >> Can I wake it up under X somehow? This device is using the modesetting >> DDX driver. > > Can you enable it via randr? I think the video= based disable forces the connector to be disabled irrevocably. -ilia ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-tip:drm-tip 1/7] drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: redefinition of 'nv137_chipset'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: f1faf571d9530365a34fe33a3efa3fb224661692
commit: 15b670ebb1bb7309b60c23b3fa1479d31cd79122 [1/7] Merge remote-tracking
branch 'drm-intel/drm-intel-next-queued' into drm-tip
config: x86_64-randconfig-i0-201715 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
git checkout 15b670ebb1bb7309b60c23b3fa1479d31cd79122
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error:
>> redefinition of 'nv137_chipset'
nv137_chipset = {
^
drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2290:1: note: previous
definition of 'nv137_chipset' was here
nv137_chipset = {
^
vim +/nv137_chipset +2347 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
fa1dbc49 Alexandre Courbot 2017-03-29 2331 .imem = gk20a_instmem_new,
fa1dbc49 Alexandre Courbot 2017-03-29 2332 .ltc = gp100_ltc_new,
fa1dbc49 Alexandre Courbot 2017-03-29 2333 .mc = gp10b_mc_new,
fa1dbc49 Alexandre Courbot 2017-03-29 2334 .mmu = gf100_mmu_new,
fa1dbc49 Alexandre Courbot 2017-03-29 2335 .secboot = gp10b_secboot_new,
fa1dbc49 Alexandre Courbot 2017-03-29 2336 .pmu = gm20b_pmu_new,
fa1dbc49 Alexandre Courbot 2017-03-29 2337 .timer = gk20a_timer_new,
fa1dbc49 Alexandre Courbot 2017-03-29 2338 .top = gk104_top_new,
fa1dbc49 Alexandre Courbot 2017-03-29 2339 .ce[2] = gp102_ce_new,
fa1dbc49 Alexandre Courbot 2017-03-29 2340 .dma = gf119_dma_new,
fa1dbc49 Alexandre Courbot 2017-03-29 2341 .fifo = gp10b_fifo_new,
fa1dbc49 Alexandre Courbot 2017-03-29 2342 .gr = gp10b_gr_new,
fa1dbc49 Alexandre Courbot 2017-03-29 2343 .sw = gf100_sw_new,
1fe487d7 Ben Skeggs2016-12-09 2344 };
1fe487d7 Ben Skeggs2016-12-09 2345
da2ba564 Ben Skeggs2017-04-06 2346 static const struct
nvkm_device_chip
da2ba564 Ben Skeggs2017-04-06 @2347 nv137_chipset = {
da2ba564 Ben Skeggs2017-04-06 2348 .name = "GP107",
da2ba564 Ben Skeggs2017-04-06 2349 .bar = gf100_bar_new,
da2ba564 Ben Skeggs2017-04-06 2350 .bios = nvkm_bios_new,
da2ba564 Ben Skeggs2017-04-06 2351 .bus = gf100_bus_new,
da2ba564 Ben Skeggs2017-04-06 2352 .devinit = gm200_devinit_new,
da2ba564 Ben Skeggs2017-04-06 2353 .fb = gp102_fb_new,
da2ba564 Ben Skeggs2017-04-06 2354 .fuse = gm107_fuse_new,
da2ba564 Ben Skeggs2017-04-06 2355 .gpio = gk104_gpio_new,
:: The code at line 2347 was first introduced by commit
:: da2ba564a6dcf46df4f828624ff55531ff11d5b0 drm/nouveau: initial support
(display-only) for GP107
:: TO: Ben Skeggs
:: CC: Ben Skeggs
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KMS question
2017-04-13 17:36 keltezéssel, Alex Deucher írta: On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan wrote: 2017-04-13 16:05 keltezéssel, Alex Deucher írta: On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan wrote: Hi, how can I disable the behaviour in the KMS drivers that enables all outputs at once? It is very annoying that on a POS machine with an 1024x768 LVDS and a 800x480 secondary monitor (both built-in) the KMS driver wakes up both. Then the framebuffer console and plymouth use both screens, making the primary output very odd with only the top-left part used by the boot splash. I would like the boot splash to be shown only on the primary output at its full resolution instead of on all outputs using the smallest common rectangle. Is there a kernel command line configuration that achieves this? The device in question uses the gma500 kernel driver but the same behaviour is observed with the i915 and radeon drivers. The problem is fbdev is not multi-head aware. The fbdev emulation in the KMS drivers attempts to light up all monitors so that something shows up on all heads. If you really want different per head configurations, you need to use the KMS API directly. As a workaround, you can use the kernel command line to disable the output you don't want to be lit up. See: https://wiki.archlinux.org/index.php/kernel_mode_setting for more info. basically add video=TV-1:d to disable the output in question. Replace TV-1 with whatever connector you want to disable. I tried adding video=DVI-D-1:d to the kernel command line. The effect is while the second output is indeed disabled, the framebuffer console still takes the second output's resolution into account and the boot splash is still using only the top-left 800x480 part of the 1024x768 primary screen. Also, the secondary screen got disabled also in X which is not desired. Can I wake it up under X somehow? This device is using the modesetting DDX driver. Can you enable it via randr? No, "xrandr --output DVI-D-1 --auto" does nothing. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 98604] [VDPAU, DRI3] Fullscreen flash video fails when hardware acceleration is enabled.
https://bugs.freedesktop.org/show_bug.cgi?id=98604 --- Comment #15 from Dieter Nützel --- Michel and Christian, can we have this patch in 17.1 (final)? I have to apply it by hand on every build. Any further logs/debug needed? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] mediatek-drm-next for 4.12
Hi, Dave: Sorry for my mistake, I would remember to add Signed-off-by me. Regards, CK On Thu, 2017-04-13 at 06:19 +1000, Dave Airlie wrote: > On 8 April 2017 at 02:42, CK Hu wrote: > > Hi, Dave: > > > > This series is MT2701 DRM support. > > Just FYI, I failed to notice this, but Stephen pointed it out, > > please make sure you add a Signed-off-by line if you are committing > other people's patch to a tree, As the maintainer you must add these, > not Acked-by. > > Acked-by are for non-maintainers. > > In this case I can't go back and undo things at this stage, they have > an Signed-off-by from a mediatek employee anyways which should leave > them in good standing. > > Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100618] Dead Island crash after starting a new game
https://bugs.freedesktop.org/show_bug.cgi?id=100618 --- Comment #12 from at...@t-online.de --- Created attachment 130831 --> https://bugs.freedesktop.org/attachment.cgi?id=130831&action=edit valgrind logfile An absolute path was the key. Logfile from valgrind is attached. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] Header: Add rotation property fields
From: Sean Paul
From drm_crtc.h, for use with the plane "rotation" property.
Signed-off-by: Sean Paul
Signed-off-by: Robert Foss
---
include/drm/drm.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index 1e7a4bc7a505..656c90045161 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -74,6 +74,14 @@ extern "C" {
#define _DRM_LOCK_IS_CONT(lock) ((lock) & _DRM_LOCK_CONT)
#define _DRM_LOCKING_CONTEXT(lock) ((lock) & ~(_DRM_LOCK_HELD|_DRM_LOCK_CONT))
+/* Rotation property bits */
+#define DRM_ROTATE_0 0
+#define DRM_ROTATE_90 1
+#define DRM_ROTATE_180 2
+#define DRM_ROTATE_270 3
+#define DRM_REFLECT_X 4
+#define DRM_REFLECT_Y 5
+
typedef unsigned int drm_context_t;
typedef unsigned int drm_drawable_t;
typedef unsigned int drm_magic_t;
--
2.11.0.453.g787f75f05
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed (v4.11-rc6-1949-g74e7a6859913)
drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed (v4.11-rc6-1949-g74e7a6859913) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1949-g74e7a6859913/ Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1949-g74e7a6859913/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1949-g74e7a6859913 Git Commit: 74e7a68599131906746cd65229beb772697e50f0 Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Tested: 11 unique boards, 4 SoC families, 11 builds out of 207 Boot Failures Detected: x86: allnoconfig minnowboard-max: 1 failed lab tinyconfig minnowboard-max: 1 failed lab --- For more info write to ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KMS question
On Thu, Apr 13, 2017 at 11:37:45AM -0400, Ilia Mirkin wrote: > On Thu, Apr 13, 2017 at 11:36 AM, Alex Deucher wrote: > > On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan wrote: > >> 2017-04-13 16:05 keltezéssel, Alex Deucher írta: > >>> > >>> On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan wrote: > > Hi, > > how can I disable the behaviour in the KMS drivers > that enables all outputs at once? > > It is very annoying that on a POS machine with an > 1024x768 LVDS and a 800x480 secondary monitor (both built-in) > the KMS driver wakes up both. Then the framebuffer console > and plymouth use both screens, making the primary output > very odd with only the top-left part used by the boot splash. > > I would like the boot splash to be shown only on the primary > output at its full resolution instead of on all outputs using > the smallest common rectangle. > > Is there a kernel command line configuration that achieves this? > > The device in question uses the gma500 kernel driver but the same > behaviour is observed with the i915 and radeon drivers. > > >>> > >>> The problem is fbdev is not multi-head aware. The fbdev emulation in > >>> the KMS drivers attempts to light up all monitors so that something > >>> shows up on all heads. If you really want different per head > >>> configurations, you need to use the KMS API directly. As a > >>> workaround, you can use the kernel command line to disable the output > >>> you don't want to be lit up. See: > >>> https://wiki.archlinux.org/index.php/kernel_mode_setting > >>> for more info. basically add video=TV-1:d to disable the output in > >>> question. Replace TV-1 with whatever connector you want to disable. > >> > >> > >> I tried adding video=DVI-D-1:d to the kernel command line. > >> > >> The effect is while the second output is indeed disabled, the > >> framebuffer console still takes the second output's resolution > >> into account and the boot splash is still using only the top-left > >> 800x480 part of the 1024x768 primary screen. > >> > >> Also, the secondary screen got disabled also in X which is not desired. > >> Can I wake it up under X somehow? This device is using the modesetting > >> DDX driver. > > > > Can you enable it via randr? > > I think the video= based disable forces the connector to be disabled > irrevocably. # echo detect > /sys/class/drm//status -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed (v4.11-rc6-1950-gf1faf571d953)
drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed (v4.11-rc6-1950-gf1faf571d953) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1950-gf1faf571d953/ Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1950-gf1faf571d953/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1950-gf1faf571d953 Git Commit: f1faf571d9530365a34fe33a3efa3fb224661692 Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Tested: 11 unique boards, 4 SoC families, 11 builds out of 207 Boot Failures Detected: x86: allnoconfig minnowboard-max: 1 failed lab tinyconfig minnowboard-max: 1 failed lab --- For more info write to ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1950-gdf0abb111336)
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1950-gdf0abb111336) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1950-gdf0abb111336/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1950-gdf0abb111336 Git Commit: df0abb1113368aa0af16907c769116ff6273812f Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Built: 4 unique architectures Build Failures Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: FAIL defconfig: FAIL defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: FAIL defconfig+CONFIG_KASAN=y: FAIL defconfig+CONFIG_LKDTM=y: FAIL defconfig+CONFIG_OF_UNITTEST=y: FAIL defconfig+CONFIG_RANDOMIZE_BASE=y: FAIL arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: FAIL multi_v7_defconfig+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL multi_v7_defconfig+CONFIG_EFI=y: FAIL multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_LKDTM=y: FAIL multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: FAIL multi_v7_defconfig+CONFIG_SMP=n: FAIL multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: FAIL tegra_defconfig: FAIL x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: FAIL allmodconfig+CONFIG_OF=n: FAIL Errors and Warnings Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: 1 error defconfig: 1 error defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: 1 error defconfig+CONFIG_KASAN=y: 1 error, 4 warnings defconfig+CONFIG_LKDTM=y: 1 error defconfig+CONFIG_OF_UNITTEST=y: 1 error defconfig+CONFIG_RANDOMIZE_BASE=y: 1 error arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: 1 error, 4 warnings multi_v7_defconfig+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_LKDTM=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_SMP=n: 1 error, 4 warnings multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 1 error, 4 warnings tegra_defconfig: 1 error x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: 1 error allmodconfig+CONFIG_OF=n: 1 error defconfig+CONFIG_KASAN=y: 5 warnings Errors summary: 20 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: redefinition of 'nv137_chipset' Warnings summary: 9 arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI 9 arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI 9 arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI 9 arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP 1 net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 bytes is larger than 2048 bytes [-Wframe-larger-than=] Detailed per-defconfig build reports: acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches --
Re: [PATCH v2 5/5] drm/vc4: Expose dma-buf fences for V3D rendering.
Daniel Vetter writes: > On Wed, Apr 12, 2017 at 12:12:02PM -0700, Eric Anholt wrote: >> This is needed for proper synchronization with display on another DRM >> device (pl111 or tinydrm) with buffers produced by vc4 V3D. Fixes the >> new igt vc4_dmabuf_poll testcase, and rendering of one of the glmark2 >> desktop tests on pl111+vc4. >> >> This doesn't yet introduce waits on other device's fences before vc4's >> rendering/display, because I don't have testcases for them. >> >> v2: Reuse dma_fence_free(), retitle commit message to clarify that >> it's not a full dma-buf fencing implementation yet. >> >> Signed-off-by: Eric Anholt > > Double-checked a few things in your ww_mutex scheme, seems are correct. > And testing with CONFIG_DEBUG_WW_MUTEX_SLOWPATH should catch any kind of > fumbles in your error paths. I didnt do a full review, so just Yeah, the lockdep and WW debug options were incredibly useful (and I should probably go turn them off now). signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: KMS question
2017-04-13 18:20 keltezéssel, Ville Syrjälä írta: On Thu, Apr 13, 2017 at 11:37:45AM -0400, Ilia Mirkin wrote: On Thu, Apr 13, 2017 at 11:36 AM, Alex Deucher wrote: On Thu, Apr 13, 2017 at 11:03 AM, Boszormenyi Zoltan wrote: 2017-04-13 16:05 keltezéssel, Alex Deucher írta: On Thu, Apr 13, 2017 at 9:03 AM, Boszormenyi Zoltan wrote: Hi, how can I disable the behaviour in the KMS drivers that enables all outputs at once? It is very annoying that on a POS machine with an 1024x768 LVDS and a 800x480 secondary monitor (both built-in) the KMS driver wakes up both. Then the framebuffer console and plymouth use both screens, making the primary output very odd with only the top-left part used by the boot splash. I would like the boot splash to be shown only on the primary output at its full resolution instead of on all outputs using the smallest common rectangle. Is there a kernel command line configuration that achieves this? The device in question uses the gma500 kernel driver but the same behaviour is observed with the i915 and radeon drivers. The problem is fbdev is not multi-head aware. The fbdev emulation in the KMS drivers attempts to light up all monitors so that something shows up on all heads. If you really want different per head configurations, you need to use the KMS API directly. As a workaround, you can use the kernel command line to disable the output you don't want to be lit up. See: https://wiki.archlinux.org/index.php/kernel_mode_setting for more info. basically add video=TV-1:d to disable the output in question. Replace TV-1 with whatever connector you want to disable. I tried adding video=DVI-D-1:d to the kernel command line. The effect is while the second output is indeed disabled, the framebuffer console still takes the second output's resolution into account and the boot splash is still using only the top-left 800x480 part of the 1024x768 primary screen. Also, the secondary screen got disabled also in X which is not desired. Can I wake it up under X somehow? This device is using the modesetting DDX driver. Can you enable it via randr? I think the video= based disable forces the connector to be disabled irrevocably. # echo detect > /sys/class/drm//status Thanks, that worked. I had to regenerate my initramfs to actually include the gma500 driver so KMS can kick in early. Before that the text mode plugin was used in plymouth and that doesn't switch dimensions when fbdev took over. The plymouth boot splash now looks good on the primary screen with the secondary display disabled from the kernel command line and I can enable the secondary screen from a boot script before X (a DM) starts which causes both screens to flash but it's good for me now. Thanks for everyone who answered. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/doc: Interlink color manager docs better
I have a tiny suggestion down there. Regardless this is :
Reviewed-by: Lionel Landwerlin
On 12/04/17 08:20, Daniel Vetter wrote:
Motivated by a request from Eric.
Cc: Eric Anholt
Cc: Lionel Landwerlin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 3 ++-
drivers/gpu/drm/drm_color_mgmt.c| 9 ++---
include/drm/drm_crtc.h | 31 +--
3 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index c3403edd0285..442724a80010 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3518,7 +3518,8 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_destroy_state);
*
* Implements support for legacy gamma correction table for drivers
* that support color management through the DEGAMMA_LUT/GAMMA_LUT
- * properties.
+ * properties. See drm_crtc_enable_color_mgmt() and the containing chapter for
+ * how the atomic color management and gamma tables work.
*/
int drm_atomic_helper_legacy_gamma_set(struct drm_crtc *crtc,
u16 *red, u16 *green, u16 *blue,
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 533f3a3e6877..3eda500fc005 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -43,7 +43,8 @@
*
*Setting this to NULL (blob property value set to 0) means a
*linear/pass-thru gamma table should be used. This is generally the
- * driver boot-up state too.
+ * driver boot-up state too. Drivers can access this blob through
+ * &drm_crtc_state.degamma_lut.
*
* “DEGAMMA_LUT_SIZE”:
*Unsinged range property to give the size of the lookup table to be set
@@ -60,7 +61,8 @@
*
*Setting this to NULL (blob property value set to 0) means a
*unit/pass-thru matrix should be used. This is generally the driver
- * boot-up state too.
+ * boot-up state too. Drivers can access the blob for the color conversion
+ * matrix through &drm_crtc_state.ctm.
*
* “GAMMA_LUT”:
*Blob property to set the gamma lookup table (LUT) mapping pixel data
@@ -72,7 +74,8 @@
*
*Setting this to NULL (blob property value set to 0) means a
*linear/pass-thru gamma table should be used. This is generally the
- * driver boot-up state too.
+ * driver boot-up state too. Drivers can access this blob through
+ * &drm_crtc_state.gamma_lut.
*
* “GAMMA_LUT_SIZE”:
*Unsigned range property to give the size of the lookup table to be set
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a8176a836e25..60b128a9e723 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -93,11 +93,6 @@ struct drm_plane_helper_funcs;
* @adjusted_mode: for use by helpers and drivers to compute adjusted mode
timings
* @mode: current mode timings
* @mode_blob: &drm_property_blob for @mode
- * @degamma_lut: Lookup table for converting framebuffer pixel data
- * before apply the conversion matrix
- * @ctm: Transformation matrix
- * @gamma_lut: Lookup table for converting pixel data after the
- * conversion matrix
* @state: backpointer to global drm_atomic_state
*
* Note that the distinction between @enable and @active is rather subtile:
@@ -144,9 +139,27 @@ struct drm_crtc_state {
/* blob property to expose current mode to atomic userspace */
struct drm_property_blob *mode_blob;
- /* blob property to expose color management to userspace */
+ /**
+* @degamma_lut:
+*
+* Lookup table for converting framebuffer pixel data before apply the
+* color conversion matrix @ctm. See drm_crtc_enable_color_mgmt().
Maybe you can add that the blob is either NULL or an array of drm_color_lut.
+*/
struct drm_property_blob *degamma_lut;
+
+ /**
+* @ctm:
+*
+* Color transformation matrix. See drm_crtc_enable_color_mgmt().
Here is blob is drm_color_ctm.
+*/
struct drm_property_blob *ctm;
+
+ /**
+* @gamma_lut:
+*
+* Lookup table for converting pixel data after the color conversion
+* matrix @ctm. See drm_crtc_enable_color_mgmt().
Here again NULL or an array of drm_color_lut.
+*/
struct drm_property_blob *gamma_lut;
/**
@@ -313,6 +326,12 @@ struct drm_crtc_funcs {
*
* This callback is optional.
*
+* Atomic drivers who want to support gamma tables should implement the
+* atomic color management support, enabled by calling
+* drm_crtc_enable_color_mgmt(), which then supports the legacy gamma
+* interface through the drm_atomic_helper_legacy_gamma_set()
+* compatibility implementation.
+*
* NOTE:
*
* Drivers that support gamma tables and also f
Re: [PATCH v2 5/5] drm/vc4: Expose dma-buf fences for V3D rendering.
Daniel Vetter writes: > On Wed, Apr 12, 2017 at 12:12:02PM -0700, Eric Anholt wrote: >> This is needed for proper synchronization with display on another DRM >> device (pl111 or tinydrm) with buffers produced by vc4 V3D. Fixes the >> new igt vc4_dmabuf_poll testcase, and rendering of one of the glmark2 >> desktop tests on pl111+vc4. >> >> This doesn't yet introduce waits on other device's fences before vc4's >> rendering/display, because I don't have testcases for them. >> >> v2: Reuse dma_fence_free(), retitle commit message to clarify that >> it's not a full dma-buf fencing implementation yet. >> >> Signed-off-by: Eric Anholt > > Double-checked a few things in your ww_mutex scheme, seems are correct. > And testing with CONFIG_DEBUG_WW_MUTEX_SLOWPATH should catch any kind of > fumbles in your error paths. I didnt do a full review, so just > > Acked-by: Daniel Vetter The two other most likely reviewers (ickle and padovan) have at least glanced at it, so I've pushed it now. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [drm-tip:drm-tip 1/7] drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: redefinition of 'nv137_chipset'
On Thu, 13 Apr 2017, kbuild test robot wrote:
> tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head: f1faf571d9530365a34fe33a3efa3fb224661692
> commit: 15b670ebb1bb7309b60c23b3fa1479d31cd79122 [1/7] Merge remote-tracking
> branch 'drm-intel/drm-intel-next-queued' into drm-tip
> config: x86_64-randconfig-i0-201715 (attached as .config)
> compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
> reproduce:
> git checkout 15b670ebb1bb7309b60c23b3fa1479d31cd79122
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All errors (new ones prefixed by >>):
>
>>> drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error:
>>> redefinition of 'nv137_chipset'
> nv137_chipset = {
> ^
>drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2290:1: note: previous
> definition of 'nv137_chipset' was here
> nv137_chipset = {
> ^
Blergh, this is probably due to me messing up a conflict resolution for
drm-tip.
BR,
Jani.
>
> vim +/nv137_chipset +2347 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
>
> fa1dbc49 Alexandre Courbot 2017-03-29 2331 .imem = gk20a_instmem_new,
> fa1dbc49 Alexandre Courbot 2017-03-29 2332 .ltc = gp100_ltc_new,
> fa1dbc49 Alexandre Courbot 2017-03-29 2333 .mc = gp10b_mc_new,
> fa1dbc49 Alexandre Courbot 2017-03-29 2334 .mmu = gf100_mmu_new,
> fa1dbc49 Alexandre Courbot 2017-03-29 2335 .secboot = gp10b_secboot_new,
> fa1dbc49 Alexandre Courbot 2017-03-29 2336 .pmu = gm20b_pmu_new,
> fa1dbc49 Alexandre Courbot 2017-03-29 2337 .timer = gk20a_timer_new,
> fa1dbc49 Alexandre Courbot 2017-03-29 2338 .top = gk104_top_new,
> fa1dbc49 Alexandre Courbot 2017-03-29 2339 .ce[2] = gp102_ce_new,
> fa1dbc49 Alexandre Courbot 2017-03-29 2340 .dma = gf119_dma_new,
> fa1dbc49 Alexandre Courbot 2017-03-29 2341 .fifo = gp10b_fifo_new,
> fa1dbc49 Alexandre Courbot 2017-03-29 2342 .gr = gp10b_gr_new,
> fa1dbc49 Alexandre Courbot 2017-03-29 2343 .sw = gf100_sw_new,
> 1fe487d7 Ben Skeggs2016-12-09 2344 };
> 1fe487d7 Ben Skeggs2016-12-09 2345
> da2ba564 Ben Skeggs2017-04-06 2346 static const struct
> nvkm_device_chip
> da2ba564 Ben Skeggs2017-04-06 @2347 nv137_chipset = {
> da2ba564 Ben Skeggs2017-04-06 2348 .name = "GP107",
> da2ba564 Ben Skeggs2017-04-06 2349 .bar = gf100_bar_new,
> da2ba564 Ben Skeggs2017-04-06 2350 .bios = nvkm_bios_new,
> da2ba564 Ben Skeggs2017-04-06 2351 .bus = gf100_bus_new,
> da2ba564 Ben Skeggs2017-04-06 2352 .devinit = gm200_devinit_new,
> da2ba564 Ben Skeggs2017-04-06 2353 .fb = gp102_fb_new,
> da2ba564 Ben Skeggs2017-04-06 2354 .fuse = gm107_fuse_new,
> da2ba564 Ben Skeggs2017-04-06 2355 .gpio = gk104_gpio_new,
>
> :: The code at line 2347 was first introduced by commit
> :: da2ba564a6dcf46df4f828624ff55531ff11d5b0 drm/nouveau: initial support
> (display-only) for GP107
>
> :: TO: Ben Skeggs
> :: CC: Ben Skeggs
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: uninitialized value on error path
"ret" isn't initialized on this error path. It doesn't really cause
any problems unless it's randomly set to -EDEADLK which is not likely.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 48a546210d8b..d0e9578952d5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9563,6 +9563,7 @@ int intel_get_load_detect_pipe(struct drm_connector
*connector,
*/
if (!crtc) {
DRM_DEBUG_KMS("no pipe available for load-detect\n");
+ ret = -ENODEV;
goto fail;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: checking for NULL instead of IS_ERR() in mock selftests
i915_gem_request_alloc() uses error pointers. It never returns NULLs.
Fixes: 0daf0113cff6 ("drm/i915: Mock infrastructure for request emission")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/selftests/mock_request.c
b/drivers/gpu/drm/i915/selftests/mock_request.c
index 0e8d2e7f8c70..8097e3693ec4 100644
--- a/drivers/gpu/drm/i915/selftests/mock_request.c
+++ b/drivers/gpu/drm/i915/selftests/mock_request.c
@@ -35,7 +35,7 @@ mock_request(struct intel_engine_cs *engine,
/* NB the i915->requests slab cache is enlarged to fit mock_request */
request = i915_gem_request_alloc(engine, context);
- if (!request)
+ if (IS_ERR(request))
return NULL;
mock = container_of(request, typeof(*mock), base);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100675] No signal on DisplayPort [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed
https://bugs.freedesktop.org/show_bug.cgi?id=100675 Bug ID: 100675 Summary: No signal on DisplayPort [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: oleg.hoefl...@gmail.com Created attachment 130835 --> https://bugs.freedesktop.org/attachment.cgi?id=130835&action=edit dmesg log First of all, this is the first bug reported by me, so I apologize in advance if I assigned it to a wrong category. I have a monitor, a DisplayPort cable and two notebooks. When the monitor is connected to the first notebook (Lenovo T440), everything works fine, so the cable seems is working fine. Now, when the monitor is connected to the second notebook, it shows "no signal is detected" and switches into sleep mode. Here is what dmesg outputs (I will attach the complete dmesg log): [ 12.064503] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed [ 12.064517] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed Of course, after logging into the X session, the monitor remains black, although Xorg does not report any errors in log: $ grep -n EE /var/log/Xorg.0.log 16: (WW) warning, (EE) error, (NI) not implemented, (??) unknown. System: Linux msi_gx70 4.10.9-gentoo #2 SMP Thu Apr 13 21:30:04 CEST 2017 x86_64 AMD A10-5750M APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100673] Tonga agd5f drm-next-4.12-wip xorg segfault on startx
https://bugs.freedesktop.org/show_bug.cgi?id=100673 --- Comment #3 from Andres Rodriguez --- Reverting the following commit fixes this branch for me: eb8eb02 drm: Drop modeset_lock_all from the getproperty ioctl Let me check if I can make a quick fix for it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/15] drm: Drop modeset_lock_all from the getproperty ioctl
On Mon, Apr 3, 2017 at 4:32 AM, Daniel Vetter wrote:
> Properties, i.e. the struct drm_property specifying the type and value
> range of a property, not the instantiation on a given object, are
> invariant over the lifetime of a driver.
>
> Hence no locking at all is needed, we can just remove it.
>
> While at it give the function some love and simplify it, to get it
> under the 80 char limit:
> - Straighten the loops to reduce the nesting.
> - use u64_to_user_ptr casting helper
> - use put_user for fixed u64 copies.
>
> Note there's a small behavioural change in that we now copy parts of
> the values to userspace if the arrays are a bit too small. Since
> userspace will immediately retry anyway, this doesn't matter.
>
> Signed-off-by: Daniel Vetter
This causes a segfault in our ddx:
https://bugs.freedesktop.org/show_bug.cgi?id=100673
Alex
> ---
> drivers/gpu/drm/drm_property.c | 72
> +-
> 1 file changed, 29 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> index b17959c3e099..3feef0659940 100644
> --- a/drivers/gpu/drm/drm_property.c
> +++ b/drivers/gpu/drm/drm_property.c
> @@ -442,8 +442,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
> struct drm_property *property;
> int enum_count = 0;
> int value_count = 0;
> - int ret = 0, i;
> - int copied;
> + int i, copied;
> struct drm_property_enum *prop_enum;
> struct drm_mode_property_enum __user *enum_ptr;
> uint64_t __user *values_ptr;
> @@ -451,55 +450,43 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
> if (!drm_core_check_feature(dev, DRIVER_MODESET))
> return -EINVAL;
>
> - drm_modeset_lock_all(dev);
> property = drm_property_find(dev, out_resp->prop_id);
> - if (!property) {
> - ret = -ENOENT;
> - goto done;
> - }
> -
> - if (drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
> - drm_property_type_is(property,
> DRM_MODE_PROP_BITMASK)) {
> - list_for_each_entry(prop_enum, &property->enum_list, head)
> - enum_count++;
> - }
> -
> - value_count = property->num_values;
> + if (!property)
> + return -ENOENT;
>
> strncpy(out_resp->name, property->name, DRM_PROP_NAME_LEN);
> out_resp->name[DRM_PROP_NAME_LEN-1] = 0;
> out_resp->flags = property->flags;
>
> - if ((out_resp->count_values >= value_count) && value_count) {
> - values_ptr = (uint64_t __user *)(unsigned
> long)out_resp->values_ptr;
> - for (i = 0; i < value_count; i++) {
> - if (copy_to_user(values_ptr + i,
> &property->values[i], sizeof(uint64_t))) {
> - ret = -EFAULT;
> - goto done;
> - }
> + value_count = property->num_values;
> + values_ptr = u64_to_user_ptr(out_resp->values_ptr);
> +
> + for (i = 0; i < value_count; i++) {
> + if (i < out_resp->count_values &&
> + put_user(property->values[i], values_ptr + i)) {
> + return -EFAULT;
> }
> }
> out_resp->count_values = value_count;
>
> + copied = 0;
> + enum_ptr = u64_to_user_ptr(out_resp->enum_blob_ptr);
> +
> if (drm_property_type_is(property, DRM_MODE_PROP_ENUM) ||
> - drm_property_type_is(property,
> DRM_MODE_PROP_BITMASK)) {
> - if ((out_resp->count_enum_blobs >= enum_count) && enum_count)
> {
> - copied = 0;
> - enum_ptr = (struct drm_mode_property_enum __user
> *)(unsigned long)out_resp->enum_blob_ptr;
> - list_for_each_entry(prop_enum, &property->enum_list,
> head) {
> -
> - if (copy_to_user(&enum_ptr[copied].value,
> &prop_enum->value, sizeof(uint64_t))) {
> - ret = -EFAULT;
> - goto done;
> - }
> -
> - if (copy_to_user(&enum_ptr[copied].name,
> -&prop_enum->name,
> DRM_PROP_NAME_LEN)) {
> - ret = -EFAULT;
> - goto done;
> - }
> - copied++;
> - }
> + drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) {
> + list_for_each_entry(prop_enum, &property->enum_list, head) {
> + enum_count++;
> + if (out_resp->count_enum_blobs <= enum_count)
> + continue;
> +
> + if (copy_to_user(&enum_ptr[copied].va
drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed (v4.11-rc6-1950-gdf0abb111336)
drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed (v4.11-rc6-1950-gdf0abb111336) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1950-gdf0abb111336/ Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1950-gdf0abb111336/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1950-gdf0abb111336 Git Commit: df0abb1113368aa0af16907c769116ff6273812f Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Tested: 11 unique boards, 4 SoC families, 11 builds out of 207 Boot Failures Detected: x86: allnoconfig minnowboard-max: 1 failed lab tinyconfig minnowboard-max: 1 failed lab --- For more info write to ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 06/15] drm: Drop modeset_lock_all from the getproperty ioctl
On Thu, Apr 13, 2017 at 04:03:16PM -0400, Alex Deucher wrote:
> On Mon, Apr 3, 2017 at 4:32 AM, Daniel Vetter wrote:
> > Properties, i.e. the struct drm_property specifying the type and value
> > range of a property, not the instantiation on a given object, are
> > invariant over the lifetime of a driver.
> >
> > Hence no locking at all is needed, we can just remove it.
> >
> > While at it give the function some love and simplify it, to get it
> > under the 80 char limit:
> > - Straighten the loops to reduce the nesting.
> > - use u64_to_user_ptr casting helper
> > - use put_user for fixed u64 copies.
> >
> > Note there's a small behavioural change in that we now copy parts of
> > the values to userspace if the arrays are a bit too small. Since
> > userspace will immediately retry anyway, this doesn't matter.
> >
> > Signed-off-by: Daniel Vetter
>
> This causes a segfault in our ddx:
> https://bugs.freedesktop.org/show_bug.cgi?id=100673
Should be fixed by:
commit 8cb68c83ab99a474ae847602f0c514d0fe17cc82
Author: Daniel Vetter
Date: Mon Apr 10 13:54:45 2017 +0200
drm: Fix get_property logic fumble
Yet again I've proven that I can't negate conditions :(
Testcase: igt/kms_properties/get_property-sanity
Reviewed-by: Maarten Lankhorst
Reviewed-by: Sean Paul
Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty
ioctl")
Does that help?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: checking for NULL instead of IS_ERR() in mock selftests
On Thu, Apr 13, 2017 at 10:52:17PM +0300, Dan Carpenter wrote:
> i915_gem_request_alloc() uses error pointers. It never returns NULLs.
>
> Fixes: 0daf0113cff6 ("drm/i915: Mock infrastructure for request emission")
> Signed-off-by: Dan Carpenter
Reviewed-by: Chris Wilson
Thanks for the catch.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: uninitialized value on error path
On Thu, Apr 13, 2017 at 10:53:11PM +0300, Dan Carpenter wrote:
> "ret" isn't initialized on this error path. It doesn't really cause
> any problems unless it's randomly set to -EDEADLK which is not likely.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 48a546210d8b..d0e9578952d5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9563,6 +9563,7 @@ int intel_get_load_detect_pipe(struct drm_connector
> *connector,
>*/
> if (!crtc) {
> DRM_DEBUG_KMS("no pipe available for load-detect\n");
> + ret = -ENODEV;
> goto fail;
> }
Looks like we need
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8ffeda9d349b..4d0b3d80ed24 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9618,6 +9618,7 @@ int intel_get_load_detect_pipe(struct drm_connector
*connector,
DRM_DEBUG_KMS("reusing fbdev for load-detection framebuffer\n");
if (IS_ERR(fb)) {
DRM_DEBUG_KMS("failed to allocate framebuffer for
load-detection\n");
+ ret = PTR_ERR(fb);
goto fail;
}
as well.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100673] Tonga agd5f drm-next-4.12-wip xorg segfault on startx
https://bugs.freedesktop.org/show_bug.cgi?id=100673
--- Comment #4 from Alex Deucher ---
Should be fixed by:
commit 8cb68c83ab99a474ae847602f0c514d0fe17cc82
Author: Daniel Vetter
Date: Mon Apr 10 13:54:45 2017 +0200
drm: Fix get_property logic fumble
Yet again I've proven that I can't negate conditions :(
Testcase: igt/kms_properties/get_property-sanity
Reviewed-by: Maarten Lankhorst
Reviewed-by: Sean Paul
Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty
ioctl")
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1952-g0a54b7fee9ec)
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1952-g0a54b7fee9ec) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1952-g0a54b7fee9ec/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1952-g0a54b7fee9ec Git Commit: 0a54b7fee9ecda9257d34e5c3ac8de6516a60a90 Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Built: 4 unique architectures Build Failures Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: FAIL defconfig: FAIL defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: FAIL defconfig+CONFIG_KASAN=y: FAIL defconfig+CONFIG_LKDTM=y: FAIL defconfig+CONFIG_OF_UNITTEST=y: FAIL defconfig+CONFIG_RANDOMIZE_BASE=y: FAIL arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: FAIL multi_v7_defconfig+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL multi_v7_defconfig+CONFIG_EFI=y: FAIL multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_LKDTM=y: FAIL multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: FAIL multi_v7_defconfig+CONFIG_SMP=n: FAIL multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: FAIL tegra_defconfig: FAIL x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: FAIL allmodconfig+CONFIG_OF=n: FAIL Errors and Warnings Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: 1 error defconfig: 1 error defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: 1 error defconfig+CONFIG_KASAN=y: 1 error, 4 warnings defconfig+CONFIG_LKDTM=y: 1 error defconfig+CONFIG_OF_UNITTEST=y: 1 error defconfig+CONFIG_RANDOMIZE_BASE=y: 1 error arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: 1 error, 4 warnings multi_v7_defconfig+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_LKDTM=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_SMP=n: 1 error, 4 warnings multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 1 error, 4 warnings tegra_defconfig: 1 error x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: 1 error allmodconfig+CONFIG_OF=n: 1 error defconfig+CONFIG_KASAN=y: 5 warnings Errors summary: 20 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: redefinition of 'nv137_chipset' Warnings summary: 9 arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI 9 arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI 9 arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI 9 arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP 1 net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 bytes is larger than 2048 bytes [-Wframe-larger-than=] Detailed per-defconfig build reports: acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches --
Re: [PATCH] drm: Fix get_property logic fumble
On 2017-04-10 08:40 AM, Maarten Lankhorst wrote:
Op 10-04-17 om 13:54 schreef Daniel Vetter:
Yet again I've proven that I can't negate conditions :(
Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty ioctl")
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Reported-by: Tvrtko Ursulin
Cc: Tvrtko Ursulin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_property.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index 3feef0659940..3e88fa24eab3 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -476,7 +476,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
drm_property_type_is(property, DRM_MODE_PROP_BITMASK)) {
list_for_each_entry(prop_enum, &property->enum_list, head) {
enum_count++;
- if (out_resp->count_enum_blobs <= enum_count)
+ if (out_resp->count_enum_blobs < enum_count)
continue;
if (copy_to_user(&enum_ptr[copied].value,
Neither can I, glanced over it while looking why the bisect pointed at this
commit.
Same.
Tested-by: Andres Rodriguez
Fixes segfaults on xorg-video-amdgpu-1.1.2
Reviewed-by: Maarten Lankhorst
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: uninitialized value on error path
True. I'll resend. regards, dan carpenter ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100673] Tonga agd5f drm-next-4.12-wip xorg segfault on startx
https://bugs.freedesktop.org/show_bug.cgi?id=100673
--- Comment #5 from Andy Furniss ---
(In reply to Alex Deucher from comment #4)
> Should be fixed by:
>
> commit 8cb68c83ab99a474ae847602f0c514d0fe17cc82
> Author: Daniel Vetter
> Date: Mon Apr 10 13:54:45 2017 +0200
>
> drm: Fix get_property logic fumble
>
> Yet again I've proven that I can't negate conditions :(
>
> Testcase: igt/kms_properties/get_property-sanity
> Reviewed-by: Maarten Lankhorst
> Reviewed-by: Sean Paul
> Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty
> ioctl")
Ok, but it doesn't seem to be anywhere in your tree.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100673] Tonga agd5f drm-next-4.12-wip xorg segfault on startx
https://bugs.freedesktop.org/show_bug.cgi?id=100673
--- Comment #6 from Alex Deucher ---
(In reply to Andy Furniss from comment #5)
> (In reply to Alex Deucher from comment #4)
> > Should be fixed by:
> >
> > commit 8cb68c83ab99a474ae847602f0c514d0fe17cc82
> > Author: Daniel Vetter
> > Date: Mon Apr 10 13:54:45 2017 +0200
> >
> > drm: Fix get_property logic fumble
> >
> > Yet again I've proven that I can't negate conditions :(
> >
> > Testcase: igt/kms_properties/get_property-sanity
> > Reviewed-by: Maarten Lankhorst
> > Reviewed-by: Sean Paul
> > Fixes: eb8eb02ed850 ("drm: Drop modeset_lock_all from the getproperty
> > ioctl")
>
> Ok, but it doesn't seem to be anywhere in your tree.
It hasn't been pulled into drm-next yet.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1953-g4079da1bee73)
drm-tip/drm-tip build: 207 builds: 20 failed, 187 passed, 20 errors, 45 warnings (v4.11-rc6-1953-g4079da1bee73) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1953-g4079da1bee73/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1953-g4079da1bee73 Git Commit: 4079da1bee731e2bf185411abd9ecda25f247890 Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Built: 4 unique architectures Build Failures Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: FAIL defconfig: FAIL defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: FAIL defconfig+CONFIG_KASAN=y: FAIL defconfig+CONFIG_LKDTM=y: FAIL defconfig+CONFIG_OF_UNITTEST=y: FAIL defconfig+CONFIG_RANDOMIZE_BASE=y: FAIL arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: FAIL multi_v7_defconfig+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: FAIL multi_v7_defconfig+CONFIG_EFI=y: FAIL multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: FAIL multi_v7_defconfig+CONFIG_LKDTM=y: FAIL multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: FAIL multi_v7_defconfig+CONFIG_SMP=n: FAIL multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: FAIL tegra_defconfig: FAIL x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: FAIL allmodconfig+CONFIG_OF=n: FAIL Errors and Warnings Detected: arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) allmodconfig: 1 error defconfig: 1 error defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error defconfig+CONFIG_EXPERT=y+CONFIG_ACPI=y: 1 error defconfig+CONFIG_KASAN=y: 1 error, 4 warnings defconfig+CONFIG_LKDTM=y: 1 error defconfig+CONFIG_OF_UNITTEST=y: 1 error defconfig+CONFIG_RANDOMIZE_BASE=y: 1 error arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05) multi_v7_defconfig: 1 error, 4 warnings multi_v7_defconfig+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_CPU_BIG_ENDIAN=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_EFI=y+CONFIG_ARM_LPAE=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_LKDTM=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_PROVE_LOCKING=y: 1 error, 4 warnings multi_v7_defconfig+CONFIG_SMP=n: 1 error, 4 warnings multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y+CONFIG_ARM_MODULE_PLTS=y: 1 error, 4 warnings tegra_defconfig: 1 error x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) allmodconfig: 1 error allmodconfig+CONFIG_OF=n: 1 error defconfig+CONFIG_KASAN=y: 5 warnings Errors summary: 20 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c:2347:1: error: redefinition of 'nv137_chipset' Warnings summary: 9 arch/arm/configs/multi_v7_defconfig:599:warning: symbol value 'm' invalid for ROCKCHIP_INNO_HDMI 9 arch/arm/configs/multi_v7_defconfig:598:warning: symbol value 'm' invalid for ROCKCHIP_DW_MIPI_DSI 9 arch/arm/configs/multi_v7_defconfig:597:warning: symbol value 'm' invalid for ROCKCHIP_DW_HDMI 9 arch/arm/configs/multi_v7_defconfig:596:warning: symbol value 'm' invalid for ROCKCHIP_ANALOGIX_DP 1 net/wireless/nl80211.c:5732:1: warning: the frame size of 2064 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2240 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:4429:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3840 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1888:1: warning: the frame size of 3784 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2232 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/wireless/nl80211.c:1399:1: warning: the frame size of 2208 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 net/bridge/br_netlink.c:1339:1: warning: the frame size of 2544 bytes is larger than 2048 bytes [-Wframe-larger-than=] 1 drivers/tty/vt/keyboard.c:1471:1: warning: the frame size of 2344 bytes is larger than 2048 bytes [-Wframe-larger-than=] Detailed per-defconfig build reports: acs5k_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches acs5k_tiny_defconfig (arm) — PASS, 0 errors, 0 warnings, 0 section mismatches --
drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed (v4.11-rc6-1952-g0a54b7fee9ec)
drm-tip/drm-tip boot: 19 boots: 2 failed, 17 passed (v4.11-rc6-1952-g0a54b7fee9ec) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1952-g0a54b7fee9ec/ Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1952-g0a54b7fee9ec/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1952-g0a54b7fee9ec Git Commit: 0a54b7fee9ecda9257d34e5c3ac8de6516a60a90 Git URL: https://anongit.freedesktop.org/git/drm/drm-tip.git Tested: 11 unique boards, 4 SoC families, 11 builds out of 207 Boot Failures Detected: x86: allnoconfig minnowboard-max: 1 failed lab tinyconfig minnowboard-max: 1 failed lab --- For more info write to ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 17/22] mmc: sdhci: Make use of the new sg_map helper function
Straightforward conversion, except due to the lack of error path we
have to WARN if the memory in the SGL is not mappable.
Signed-off-by: Logan Gunthorpe
---
drivers/mmc/host/sdhci.c | 35 ++-
1 file changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 63bc33a..af0c107 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -497,15 +497,34 @@ static int sdhci_pre_dma_transfer(struct sdhci_host *host,
return sg_count;
}
+/*
+ * Note this function may return PTR_ERR and must be checked.
+ */
static char *sdhci_kmap_atomic(struct scatterlist *sg, unsigned long *flags)
{
+ void *ret;
+
local_irq_save(*flags);
- return kmap_atomic(sg_page(sg)) + sg->offset;
+
+ ret = sg_map(sg, SG_KMAP_ATOMIC);
+ if (IS_ERR(ret)) {
+ /*
+* This should really never happen unless the code is changed
+* to use memory that is not mappable in the sg. Seeing there
+* doesn't seem to be any error path out of here, we can only
+* WARN.
+*/
+ WARN(1, "Non-mappable memory used in sg!");
+ local_irq_restore(*flags);
+ }
+
+ return ret;
}
-static void sdhci_kunmap_atomic(void *buffer, unsigned long *flags)
+static void sdhci_kunmap_atomic(struct scatterlist *sg, void *buffer,
+ unsigned long *flags)
{
- kunmap_atomic(buffer);
+ sg_unmap(sg, buffer, SG_KMAP_ATOMIC);
local_irq_restore(*flags);
}
@@ -568,8 +587,11 @@ static void sdhci_adma_table_pre(struct sdhci_host *host,
if (offset) {
if (data->flags & MMC_DATA_WRITE) {
buffer = sdhci_kmap_atomic(sg, &flags);
+ if (IS_ERR(buffer))
+ return;
+
memcpy(align, buffer, offset);
- sdhci_kunmap_atomic(buffer, &flags);
+ sdhci_kunmap_atomic(sg, buffer, &flags);
}
/* tran, valid */
@@ -646,8 +668,11 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
(sg_dma_address(sg) &
SDHCI_ADMA2_MASK);
buffer = sdhci_kmap_atomic(sg, &flags);
+ if (IS_ERR(buffer))
+ return;
+
memcpy(buffer, align, size);
- sdhci_kunmap_atomic(buffer, &flags);
+ sdhci_kunmap_atomic(sg, buffer, &flags);
align += SDHCI_ADMA2_ALIGN;
}
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 19/22] mmc: tmio: Make use of the new sg_map helper function
Straightforward conversion to sg_map helper. A couple paths will
WARN if the memory does not end up being mappable.
Signed-off-by: Logan Gunthorpe
---
drivers/mmc/host/tmio_mmc.h | 12 ++--
drivers/mmc/host/tmio_mmc_dma.c | 5 +
drivers/mmc/host/tmio_mmc_pio.c | 24
3 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h
index 2b349d4..ba68c9fed 100644
--- a/drivers/mmc/host/tmio_mmc.h
+++ b/drivers/mmc/host/tmio_mmc.h
@@ -198,17 +198,25 @@ void tmio_mmc_enable_mmc_irqs(struct tmio_mmc_host *host,
u32 i);
void tmio_mmc_disable_mmc_irqs(struct tmio_mmc_host *host, u32 i);
irqreturn_t tmio_mmc_irq(int irq, void *devid);
+/* Note: this function may return PTR_ERR and must be checked! */
static inline char *tmio_mmc_kmap_atomic(struct scatterlist *sg,
unsigned long *flags)
{
+ void *ret;
+
local_irq_save(*flags);
- return kmap_atomic(sg_page(sg)) + sg->offset;
+ ret = sg_map(sg, SG_KMAP_ATOMIC);
+
+ if (IS_ERR(ret))
+ local_irq_restore(*flags);
+
+ return ret;
}
static inline void tmio_mmc_kunmap_atomic(struct scatterlist *sg,
unsigned long *flags, void *virt)
{
- kunmap_atomic(virt - sg->offset);
+ sg_unmap(sg, virt, SG_KMAP_ATOMIC);
local_irq_restore(*flags);
}
diff --git a/drivers/mmc/host/tmio_mmc_dma.c b/drivers/mmc/host/tmio_mmc_dma.c
index fa8a936..07531f7 100644
--- a/drivers/mmc/host/tmio_mmc_dma.c
+++ b/drivers/mmc/host/tmio_mmc_dma.c
@@ -149,6 +149,11 @@ static void tmio_mmc_start_dma_tx(struct tmio_mmc_host
*host)
if (!aligned) {
unsigned long flags;
void *sg_vaddr = tmio_mmc_kmap_atomic(sg, &flags);
+ if (IS_ERR(sg_vaddr)) {
+ ret = PTR_ERR(sg_vaddr);
+ goto pio;
+ }
+
sg_init_one(&host->bounce_sg, host->bounce_buf, sg->length);
memcpy(host->bounce_buf, sg_vaddr, host->bounce_sg.length);
tmio_mmc_kunmap_atomic(sg, &flags, sg_vaddr);
diff --git a/drivers/mmc/host/tmio_mmc_pio.c b/drivers/mmc/host/tmio_mmc_pio.c
index 6b789a7..d6fdbf6 100644
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -479,6 +479,18 @@ static void tmio_mmc_pio_irq(struct tmio_mmc_host *host)
}
sg_virt = tmio_mmc_kmap_atomic(host->sg_ptr, &flags);
+ if (IS_ERR(sg_virt)) {
+ /*
+* This should really never happen unless
+* the code is changed to use memory that is
+* not mappable in the sg. Seeing there doesn't
+* seem to be any error path out of here,
+* we can only WARN.
+*/
+ WARN(1, "Non-mappable memory used in sg!");
+ return;
+ }
+
buf = (unsigned short *)(sg_virt + host->sg_off);
count = host->sg_ptr->length - host->sg_off;
@@ -506,6 +518,18 @@ static void tmio_mmc_check_bounce_buffer(struct
tmio_mmc_host *host)
if (host->sg_ptr == &host->bounce_sg) {
unsigned long flags;
void *sg_vaddr = tmio_mmc_kmap_atomic(host->sg_orig, &flags);
+ if (IS_ERR(sg_vaddr)) {
+ /*
+* This should really never happen unless
+* the code is changed to use memory that is
+* not mappable in the sg. Seeing there doesn't
+* seem to be any error path out of here,
+* we can only WARN.
+*/
+ WARN(1, "Non-mappable memory used in sg!");
+ return;
+ }
+
memcpy(sg_vaddr, host->bounce_buf, host->bounce_sg.length);
tmio_mmc_kunmap_atomic(host->sg_orig, &flags, sg_vaddr);
}
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH 0/4] nouveau_hwmon: migrate to hwmon_device_register_with_info
Hi Oscar,
this is a cover letter, there should be no patch attached to it, but a
stat of the following patches and an explenation what the series is
doing.
2017-04-13 11:07 GMT+02:00 Oscar Salvador :
> Hi again,
>
> I've split the patches as Karol Herbst suggested.
> I hope now it's fine.
>
> This series of patches introduce the new hwmon_device_register_with_info
> and gets rid of the old hwmon_device_register.
>
> This patch adds the default sensors with their possible config values.
> Just to prepare for the next patches
>
>
> --- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig 2017-04-12
> 19:18:09.638073562 +0200
> +++ linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c 2017-04-12
> 19:19:44.244797202 +0200
> @@ -692,6 +692,78 @@ static const struct attribute_group hwmo
> static const struct attribute_group hwmon_power_caps_attrgroup = {
> .attrs = hwmon_power_caps_attributes,
> };
> +
> +static const u32 nouveau_config_chip[] = {
> + HWMON_C_UPDATE_INTERVAL,
> + 0
> +};
> +
> +static const u32 nouveau_config_in[] = {
> + HWMON_I_INPUT | HWMON_I_MIN | HWMON_I_MAX | HWMON_I_LABEL,
> + 0
> +};
> +
> +static const u32 nouveau_config_temp[] = {
> + HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST |
> + HWMON_T_CRIT | HWMON_T_CRIT_HYST | HWMON_T_EMERGENCY |
> + HWMON_T_EMERGENCY_HYST,
> + 0
> +};
> +
> +static const u32 nouveau_config_fan[] = {
> + HWMON_F_INPUT,
> + 0
> +};
> +
> +static const u32 nouveau_config_pwm[] = {
> + HWMON_PWM_INPUT | HWMON_PWM_ENABLE,
> + 0
> +};
> +
> +static const u32 nouveau_config_power[] = {
> + HWMON_P_INPUT | HWMON_P_CAP_MAX | HWMON_P_CRIT,
> + 0
> +};
> +
> +static const struct hwmon_channel_info nouveau_chip = {
> + .type = hwmon_chip,
> + .config = nouveau_config_chip,
> +};
> +
> +static const struct hwmon_channel_info nouveau_temp = {
> + .type = hwmon_temp,
> + .config = nouveau_config_temp,
> +};
> +
> +static const struct hwmon_channel_info nouveau_fan = {
> + .type = hwmon_fan,
> + .config = nouveau_config_fan,
> +};
> +
> +static const struct hwmon_channel_info nouveau_in = {
> + .type = hwmon_in,
> + .config = nouveau_config_in,
> +};
> +
> +static const struct hwmon_channel_info nouveau_pwm = {
> + .type = hwmon_pwm,
> + .config = nouveau_config_pwm,
> +};
> +
> +static const struct hwmon_channel_info nouveau_power = {
> + .type = hwmon_power,
> + .config = nouveau_config_power,
> +};
> +
> +static const struct hwmon_channel_info *nouveau_info[] = {
> + &nouveau_chip,
> + &nouveau_temp,
> + &nouveau_fan,
> + &nouveau_in,
> + &nouveau_pwm,
> + &nouveau_power,
> + NULL
> +};
> #endif
>
> int
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 21/22] mmc: tifm_sd: Make use of the new sg_map helper function
This conversion is a bit complicated. We modiy the read_fifo,
write_fifo and copy_page functions to take a scatterlist instead of a
page. Thus we can use sg_map instead of kmap_atomic. There's a bit of
accounting that needed to be done for the offset for this to work.
(Seeing sg_map takes care of the offset but it's already added and
used earlier in the code.
There's also no error path, so if unmappable memory finds its way into
the sgl we can only WARN.
Signed-off-by: Logan Gunthorpe
---
drivers/mmc/host/tifm_sd.c | 88 +++---
1 file changed, 67 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/host/tifm_sd.c b/drivers/mmc/host/tifm_sd.c
index 93c4b40..75b0d74 100644
--- a/drivers/mmc/host/tifm_sd.c
+++ b/drivers/mmc/host/tifm_sd.c
@@ -111,14 +111,26 @@ struct tifm_sd {
};
/* for some reason, host won't respond correctly to readw/writew */
-static void tifm_sd_read_fifo(struct tifm_sd *host, struct page *pg,
+static void tifm_sd_read_fifo(struct tifm_sd *host, struct scatterlist *sg,
unsigned int off, unsigned int cnt)
{
struct tifm_dev *sock = host->dev;
unsigned char *buf;
unsigned int pos = 0, val;
- buf = kmap_atomic(pg) + off;
+ buf = sg_map_offset(sg, off - sg->offset, SG_KMAP_ATOMIC);
+ if (IS_ERR(buf)) {
+ /*
+* This should really never happen unless
+* the code is changed to use memory that is
+* not mappable in the sg. Seeing there doesn't
+* seem to be any error path out of here,
+* we can only WARN.
+*/
+ WARN(1, "Non-mappable memory used in sg!");
+ return;
+ }
+
if (host->cmd_flags & DATA_CARRY) {
buf[pos++] = host->bounce_buf_data[0];
host->cmd_flags &= ~DATA_CARRY;
@@ -134,17 +146,29 @@ static void tifm_sd_read_fifo(struct tifm_sd *host,
struct page *pg,
}
buf[pos++] = (val >> 8) & 0xff;
}
- kunmap_atomic(buf - off);
+ sg_unmap_offset(sg, buf, off - sg->offset, SG_KMAP_ATOMIC);
}
-static void tifm_sd_write_fifo(struct tifm_sd *host, struct page *pg,
+static void tifm_sd_write_fifo(struct tifm_sd *host, struct scatterlist *sg,
unsigned int off, unsigned int cnt)
{
struct tifm_dev *sock = host->dev;
unsigned char *buf;
unsigned int pos = 0, val;
- buf = kmap_atomic(pg) + off;
+ buf = sg_map_offset(sg, off - sg->offset, SG_KMAP_ATOMIC);
+ if (IS_ERR(buf)) {
+ /*
+* This should really never happen unless
+* the code is changed to use memory that is
+* not mappable in the sg. Seeing there doesn't
+* seem to be any error path out of here,
+* we can only WARN.
+*/
+ WARN(1, "Non-mappable memory used in sg!");
+ return;
+ }
+
if (host->cmd_flags & DATA_CARRY) {
val = host->bounce_buf_data[0] | ((buf[pos++] << 8) & 0xff00);
writel(val, sock->addr + SOCK_MMCSD_DATA);
@@ -161,7 +185,7 @@ static void tifm_sd_write_fifo(struct tifm_sd *host, struct
page *pg,
val |= (buf[pos++] << 8) & 0xff00;
writel(val, sock->addr + SOCK_MMCSD_DATA);
}
- kunmap_atomic(buf - off);
+ sg_unmap_offset(sg, buf, off - sg->offset, SG_KMAP_ATOMIC);
}
static void tifm_sd_transfer_data(struct tifm_sd *host)
@@ -170,7 +194,6 @@ static void tifm_sd_transfer_data(struct tifm_sd *host)
struct scatterlist *sg = r_data->sg;
unsigned int off, cnt, t_size = TIFM_MMCSD_FIFO_SIZE * 2;
unsigned int p_off, p_cnt;
- struct page *pg;
if (host->sg_pos == host->sg_len)
return;
@@ -192,33 +215,57 @@ static void tifm_sd_transfer_data(struct tifm_sd *host)
}
off = sg[host->sg_pos].offset + host->block_pos;
- pg = nth_page(sg_page(&sg[host->sg_pos]), off >> PAGE_SHIFT);
p_off = offset_in_page(off);
p_cnt = PAGE_SIZE - p_off;
p_cnt = min(p_cnt, cnt);
p_cnt = min(p_cnt, t_size);
if (r_data->flags & MMC_DATA_READ)
- tifm_sd_read_fifo(host, pg, p_off, p_cnt);
+ tifm_sd_read_fifo(host, &sg[host->sg_pos], p_off,
+ p_cnt);
else if (r_data->flags & MMC_DATA_WRITE)
- tifm_sd_write_fifo(host, pg, p_off, p_cnt);
+ tifm_sd_write_fifo(host, &sg[host->sg_pos], p_off,
+ p_cnt);
t_size -= p_cnt;
host->block_pos += p_cnt;
}
}
-static void tifm_sd_copy_page(struct page *dst, unsigned
