imx-drm: flip_done timed out
Hi I see the following error over and over and as a result a black screen :/ [drm:drm_atomic_helper_commit_cleanup_done] *ERROR* [CRTC:24:crtc-0] flip_done timed out I am on latest longterm (4.9.31) with this four imx-drm patches atop: https://pastebin.com/mCGkw8H8 https://pastebin.com/BmbbZSHA https://pastebin.com/r1RxsEjk https://pastebin.com/wjD9LR6r Maybe my patches got replaced by a newer version or are there other patches I need to fix this? It would also quite nice if fixes for this problem could land in 4.9.x series. greets -- Christian Gmeiner, MSc https://www.youtube.com/user/AloryOFFICIAL https://soundcloud.com/christian-gmeiner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[bug report] gma500/cdv: Add eDP support
[ This is a warning about very old code. -dan ]
Hello Zhao Yakui,
The patch d112a8163f83: "gma500/cdv: Add eDP support" from Aug 8,
2012, leads to the following static checker warnings:
drivers/gpu/drm/gma500/intel_bios.c:77 parse_edp()
warn: right shifting more than type allows 32 vs 510
drivers/gpu/drm/gma500/intel_bios.c:90 parse_edp()
warn: buffer overflow 'edp->power_seqs' 16 <= 255
drivers/gpu/drm/gma500/intel_bios.c
75
76 panel_type = dev_priv->panel_type;
^
panel_type can be 0xff. It get's set in parse_lfp_panel_data(). If
it's 0xff we return early but the error handling seems not very complete
because here we are with it still set to 0xff.
77 switch ((edp->color_depth >> (panel_type * 2)) & 3) {
shift to zero.
78 case EDP_18BPP:
79 dev_priv->edp.bpp = 18;
80 break;
81 case EDP_24BPP:
82 dev_priv->edp.bpp = 24;
83 break;
84 case EDP_30BPP:
85 dev_priv->edp.bpp = 30;
86 break;
87 }
88
89 /* Get the eDP sequencing and link info */
90 edp_pps = &edp->power_seqs[panel_type];
^^^
buffer overflow.
91 edp_link_params = &edp->link_params[panel_type];
92
regards,
dan carpenter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v2 01/11] dt-bindings: update the binding for Allwinner H3 TVE support
On Sat, Jun 10, 2017 at 12:51:02AM +0800, Icenowy Zheng wrote: > > > 于 2017年6月10日 GMT+08:00 上午12:49:15, Maxime Ripard > 写到: > >On Wed, Jun 07, 2017 at 04:48:50PM +0800, Icenowy Zheng wrote: > >> >> @@ -189,6 +211,8 @@ supported. > >> >> Required properties: > >> >>- compatible: value must be one of: > >> >> * allwinner,sun8i-v3s-de2-mixer > >> >> +* allwinner,sun8i-h3-de2-mixer0 > >> >> +* allwinner,sun8i-h3-de2-mixer1 > >> > > >> >Again, please explain why we need to have different compatibles > >> >here. If it's only about the number of planes, this should be dealt > >> >with a property, not a compatible. > >> > >> Only mixer0 has "VEP" and write-back support, at least on H3. > > > >What is that VEP? writeback support can also be expressed by a > >property. > > I don't know what VEP is... Ok. Let's forget about it at the moment then, especially if it's optional, we can add support for it later. > But we are really facing different cores, like sun50i-a64-mmc > and sun50i-a64-emmc. Not really. The eMMC and MMC controllers are *very* different. They behave (slightly) differently, the eMMC controller has more signals (8-bit bus, data strobe), can run at a higher frequency. You cannot have exactly the same driver (or rather code path) to handle both. Therefore the need for some other compatible. This is not the case for the mixer here. The thing that differs between instances is not behaviour but data. And we provide most of the data through DT. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/11] drm: sun4i: add support for the TV encoder in H3 SoC
On Sun, Jun 11, 2017 at 02:43:42PM +0800, icen...@aosc.io wrote:
> 在 2017-06-07 17:38，Maxime Ripard 写道：
> > On Mon, Jun 05, 2017 at 12:01:45AM +0800, Icenowy Zheng wrote:
> > > Allwinner H3 features a TV encoder similar to the one in earlier SoCs,
> > > but has a internal fixed clock divider that divides the TCON1 clock
> > > (called TVE clock in datasheet) by 11.
> > >
> > > Add support for it.
> > >
> > > Signed-off-by: Icenowy Zheng
> > > ---
> > > Changes in v2:
> > > - Quirk part rewritten.
> > >
> > > drivers/gpu/drm/sun4i/sun4i_tv.c | 35
> > > ++-
> > > 1 file changed, 34 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c
> > > b/drivers/gpu/drm/sun4i/sun4i_tv.c
> > > index 338b9e5bb2a3..b9ff6d5ea67a 100644
> > > --- a/drivers/gpu/drm/sun4i/sun4i_tv.c
> > > +++ b/drivers/gpu/drm/sun4i/sun4i_tv.c
> > > @@ -13,6 +13,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > >
> > > @@ -169,14 +170,21 @@ struct tv_mode {
> > > const struct resync_parameters *resync_params;
> > > };
> > >
> > > +struct sun4i_tv_quirks {
> > > + int fixed_divider;
> > > +};
> > > +
> > > struct sun4i_tv {
> > > struct drm_connectorconnector;
> > > struct drm_encoder encoder;
> > >
> > > struct clk *clk;
> > > + struct clk *mod_clk;
> > > struct regmap *regs;
> > > struct reset_control*reset;
> > >
> > > + const struct sun4i_tv_quirks *quirks;
> > > +
> > > struct sun4i_drv*drv;
> > > };
> > >
> > > @@ -391,6 +399,12 @@ static void sun4i_tv_mode_set(struct
> > > drm_encoder *encoder,
> > > struct sun4i_tcon *tcon = crtc->tcon;
> > > const struct tv_mode *tv_mode = sun4i_tv_find_tv_by_mode(mode);
> > >
> > > + if (tv->quirks->fixed_divider) {
> > > + DRM_DEBUG_DRIVER("Applying fixed divider %d on TVE clock\n",
> > > + tv->quirks->fixed_divider);
> > > + mode->crtc_clock *= tv->quirks->fixed_divider;
> > > + }
> > > +
> >
> > You're not allowed to change the mode in mode_set, and you shouldn't
> > even change it. The output pixel clock is still 27MHz.
> >
> > You should implement that using the states, as we discussed already.
>
> After reading the comments at include/drm/drm_modeset_helper_vtables.h,
> I think the atomic_check function is allowed to directly change
> the adjust_mode of crtc_state.
>
> And according to other comments at include/drm/drm_modes.h, the
> crtc_clock in adjust_mode should be the clock to be really feed
> to the hardware.
>
> So I think I can just change this in atomic_check.
>
> However, the mode_set function of sun4i_tv seems to be not
> regarding adjusted_mode and still use original mode.
>
> So my current design is:
> - Multiply adjusted_mode in atomic_check.
> - Feed adjust_mode to TCON code in mode_set function.
>
> Is this proper?
>
> (From my own understanding to the comments I think so.)
No, it's not. The pixel clock in the mode is the pixel clock output
physically by the connector. You want to use it for an intermediate
clock in your pipeline.
This is not the same clock, and not the same frequency.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mediatek: check for memory allocation failure
Hi, Christophe:
Applied to my branch mediatek-drm-next-4.13, thanks.
Regards,
CK
On Fri, 2017-06-09 at 21:27 +0200, Christophe JAILLET wrote:
> If 'devm_kmalloc_array' returns NULL, we should return -ENOMEM as already
> done a few lines above instead of deferencing a NULL pointer a few lines
> below.
>
> Signed-off-by: Christophe JAILLET
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 6582e1f56d37..cb32c9369f3a 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -559,6 +559,8 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> mtk_crtc->ddp_comp = devm_kmalloc_array(dev, mtk_crtc->ddp_comp_nr,
> sizeof(*mtk_crtc->ddp_comp),
> GFP_KERNEL);
> + if (!mtk_crtc->ddp_comp)
> + return -ENOMEM;
>
> mtk_crtc->mutex = mtk_disp_mutex_get(priv->mutex_dev, pipe);
> if (IS_ERR(mtk_crtc->mutex)) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/vc4: Add get/set tiling ioctls.
Hi Eric,
On Wed, 7 Jun 2017 17:13:36 -0700
Eric Anholt wrote:
> This allows mesa to set the tiling format for a BO and have that
> tiling format be respected by mesa on the other side of an
> import/export (and by vc4 scanout in the kernel), without defining a
> protocol to pass the tiling through userspace.
>
> Signed-off-by: Eric Anholt
> ---
>
> igt tests (which caught two edge cases) submitted to intel-gfx.
>
> Mesa code: https://github.com/anholt/mesa/commits/drm-vc4-tiling
>
> drivers/gpu/drm/vc4/vc4_bo.c | 83
> +++
> drivers/gpu/drm/vc4/vc4_drv.c | 2 ++
> drivers/gpu/drm/vc4/vc4_drv.h | 6
> drivers/gpu/drm/vc4/vc4_kms.c | 41 -
> include/uapi/drm/vc4_drm.h| 16 +
> 5 files changed, 147 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> index 80b2f9e55c5c..21649109fd4f 100644
> --- a/drivers/gpu/drm/vc4/vc4_bo.c
> +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> @@ -347,6 +347,7 @@ void vc4_free_object(struct drm_gem_object *gem_bo)
> bo->validated_shader = NULL;
> }
>
> + bo->t_format = false;
> bo->free_time = jiffies;
> list_add(&bo->size_head, cache_list);
> list_add(&bo->unref_head, &vc4->bo_cache.time_list);
> @@ -572,6 +573,88 @@ vc4_create_shader_bo_ioctl(struct drm_device *dev, void
> *data,
> return ret;
> }
>
> +/**
> + * vc4_set_tiling_ioctl() - Sets the tiling modifier for a BO.
> + * @dev: DRM device
> + * @data: ioctl argument
> + * @file_priv: DRM file for this fd
> + *
> + * The tiling state of the BO decides the default modifier of an fb if
> + * no specific modifier was set by userspace, and the return value of
> + * vc4_get_tiling_ioctl() (so that userspace can treat a BO it
> + * received from dmabuf as the same tiling format as the producer
> + * used).
> + */
> +int vc4_set_tiling_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> +{
> + struct drm_vc4_set_tiling *args = data;
> + struct drm_gem_object *gem_obj;
> + struct vc4_bo *bo;
> + bool t_format;
> +
> + if (args->flags != 0)
> + return -EINVAL;
> +
> + switch (args->modifier) {
> + case DRM_FORMAT_MOD_NONE:
> + t_format = false;
> + break;
> + case DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED:
> + t_format = true;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + gem_obj = drm_gem_object_lookup(file_priv, args->handle);
> + if (!gem_obj) {
> + DRM_ERROR("Failed to look up GEM BO %d\n", args->handle);
> + return -ENOENT;
> + }
> + bo = to_vc4_bo(gem_obj);
> + bo->t_format = t_format;
> +
> + drm_gem_object_unreference_unlocked(gem_obj);
> +
> + return 0;
> +}
> +
> +/**
> + * vc4_get_tiling_ioctl() - Gets the tiling modifier for a BO.
> + * @dev: DRM device
> + * @data: ioctl argument
> + * @file_priv: DRM file for this fd
> + *
> + * Returns the tiling modifier for a BO as set by vc4_set_tiling_ioctl().
> + */
> +int vc4_get_tiling_ioctl(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> +{
> + struct drm_vc4_get_tiling *args = data;
> + struct drm_gem_object *gem_obj;
> + struct vc4_bo *bo;
> +
> + if (args->flags != 0 || args->modifier != 0)
> + return -EINVAL;
> +
> + gem_obj = drm_gem_object_lookup(file_priv, args->handle);
> + if (!gem_obj) {
> + DRM_ERROR("Failed to look up GEM BO %d\n", args->handle);
> + return -ENOENT;
> + }
> + bo = to_vc4_bo(gem_obj);
> +
> + if (bo->t_format)
> + args->modifier = DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED;
> + else
> + args->modifier = DRM_FORMAT_MOD_NONE;
> +
> + drm_gem_object_unreference_unlocked(gem_obj);
> +
> + return 0;
> +}
> +
> void vc4_bo_cache_init(struct drm_device *dev)
> {
> struct vc4_dev *vc4 = to_vc4_dev(dev);
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 136bb4213dc0..c6b487c3d2b7 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -138,6 +138,8 @@ static const struct drm_ioctl_desc vc4_drm_ioctls[] = {
> DRM_IOCTL_DEF_DRV(VC4_GET_HANG_STATE, vc4_get_hang_state_ioctl,
> DRM_ROOT_ONLY),
> DRM_IOCTL_DEF_DRV(VC4_GET_PARAM, vc4_get_param_ioctl, DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(VC4_SET_TILING, vc4_set_tiling_ioctl,
> DRM_RENDER_ALLOW),
> + DRM_IOCTL_DEF_DRV(VC4_GET_TILING, vc4_get_tiling_ioctl,
> DRM_RENDER_ALLOW),
> };
>
> static struct drm_driver vc4_drm_driver = {
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index a5bf2e5e0b57..df22698d62ee 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -148,6 +148,8 @@ struct vc
Re: [PATCH 1/2] drm/vc4: Add T-format scanout support.
On Wed, 7 Jun 2017 17:13:35 -0700
Eric Anholt wrote:
> The T tiling format is what V3D uses for textures, with no raster
> support at all until later revisions of the hardware (and always at a
> large 3D performance penalty). If we can't scan out V3D's format,
> then we often need to do a relayout at some stage of the pipeline,
> either right before texturing from the scanout buffer (common in X11
> without a compositor) or between a tiled screen buffer right before
> scanout (an option I've considered in trying to resolve this
> inconsistency, but which means needing to use the dirty fb ioctl and
> having some update policy).
>
> T-format scanout lets us avoid either of those shadow copies, for a
> massive, obvious performance improvement to X11 window dragging
> without a compositor. Unfortunately, enabling a compositor to work
> around the discrepancy has turned out to be too costly in memory
> consumption for the Raspbian distribution.
>
> Because the HVS operates a scanline at a time, compositing from T does
> increase the memory bandwidth cost of scanout. On my 1920x1080@32bpp
> display on a RPi3, we go from about 15% of system memory bandwidth
> with linear to about 20% with tiled. However, for X11 this still ends
> up being a huge performance win in active usage.
>
> This patch doesn't yet handle src_x/src_y offsetting within the tiled
> buffer. However, we fail to do so for untiled buffers already.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/vc4/vc4_plane.c | 31 +++
> drivers/gpu/drm/vc4/vc4_regs.h | 19 +++
> include/uapi/drm/drm_fourcc.h | 23 ++-
> 3 files changed, 68 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
> index da18dec21696..fa6809d8b0fe 100644
> --- a/drivers/gpu/drm/vc4/vc4_plane.c
> +++ b/drivers/gpu/drm/vc4/vc4_plane.c
> @@ -500,8 +500,8 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> u32 ctl0_offset = vc4_state->dlist_count;
> const struct hvs_format *format =
> vc4_get_hvs_format(fb->format->format);
> int num_planes = drm_format_num_planes(format->drm);
> - u32 scl0, scl1;
> - u32 lbm_size;
> + u32 scl0, scl1, pitch0;
> + u32 lbm_size, tiling;
> unsigned long irqflags;
> int ret, i;
>
> @@ -542,11 +542,31 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> scl1 = vc4_get_scl_field(state, 0);
> }
>
> + switch (fb->modifier) {
> + case DRM_FORMAT_MOD_LINEAR:
> + tiling = SCALER_CTL0_TILING_LINEAR;
> + pitch0 = VC4_SET_FIELD(fb->pitches[0], SCALER_SRC_PITCH);
> + break;
> + case DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED:
> + tiling = SCALER_CTL0_TILING_256B_OR_T;
> +
> + pitch0 = (VC4_SET_FIELD(0, SCALER_PITCH0_TILE_Y_OFFSET),
> + VC4_SET_FIELD(0, SCALER_PITCH0_TILE_WIDTH_L),
> + VC4_SET_FIELD((vc4_state->src_w[0] + 31) >> 5,
> + SCALER_PITCH0_TILE_WIDTH_R));
> + break;
> + default:
> + DRM_DEBUG_KMS("Unsupported FB tiling flag 0x%16llx",
> + (long long)fb->modifier);
> + return -EINVAL;
> + }
> +
> /* Control word */
> vc4_dlist_write(vc4_state,
> SCALER_CTL0_VALID |
> (format->pixel_order << SCALER_CTL0_ORDER_SHIFT) |
> (format->hvs << SCALER_CTL0_PIXEL_FORMAT_SHIFT) |
> + VC4_SET_FIELD(tiling, SCALER_CTL0_TILING) |
> (vc4_state->is_unity ? SCALER_CTL0_UNITY : 0) |
> VC4_SET_FIELD(scl0, SCALER_CTL0_SCL0) |
> VC4_SET_FIELD(scl1, SCALER_CTL0_SCL1));
> @@ -600,8 +620,11 @@ static int vc4_plane_mode_set(struct drm_plane *plane,
> for (i = 0; i < num_planes; i++)
> vc4_dlist_write(vc4_state, 0xc0c0c0c0);
>
> - /* Pitch word 0/1/2 */
> - for (i = 0; i < num_planes; i++) {
> + /* Pitch word 0 */
> + vc4_dlist_write(vc4_state, pitch0);
> +
> + /* Pitch word 1/2 */
> + for (i = 1; i < num_planes; i++) {
> vc4_dlist_write(vc4_state,
> VC4_SET_FIELD(fb->pitches[i],
> SCALER_SRC_PITCH));
> }
> diff --git a/drivers/gpu/drm/vc4/vc4_regs.h b/drivers/gpu/drm/vc4/vc4_regs.h
> index 932093936178..d382c34c1b9e 100644
> --- a/drivers/gpu/drm/vc4/vc4_regs.h
> +++ b/drivers/gpu/drm/vc4/vc4_regs.h
> @@ -709,6 +709,13 @@ enum hvs_pixel_format {
> #define SCALER_CTL0_SIZE_MASKVC4_MASK(29, 24)
> #define SCALER_CTL0_SIZE_SHIFT 24
>
> +#define SCALER_CTL0_TILING_MASK VC4_MASK(21, 20)
> +#define SCALER_CTL0_TILING_SHIFT 20
> +#define SCALER_CTL0_TILING_LINEAR0
> +#def
[Bug 101387] amdgpu display corruption and hang on AMD A10-9620P
https://bugs.freedesktop.org/show_bug.cgi?id=101387 --- Comment #3 from Carlo Caione --- > Looks like amdgpu_atombios_crtc_powergate_init scribbles over the stack. Yeah, and while this is causing the panic this is not related to the display corruption. The garbage lines we see at boot seem to be displayed at the same time when in the log we have: [drm] amdgpu atom DIG backlight initialized [drm] AMDGPU Display Connectors [drm] Connector 0: [drm] eDP-1 [drm] HPD1 [drm] DDC: 0x4868 0x4868 0x4869 0x4869 0x486a 0x486a 0x486b 0x486b [drm] Encoders: [drm] LCD1: INTERNAL_UNIPHY [drm] Connector 1: [drm] HDMI-A-1 [drm] HPD2 [drm] DDC: 0x486c 0x486c 0x486d 0x486d 0x486e 0x486e 0x486f 0x486f [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY [drm] amdgpu atom DIG backlight initialized [drm] AMDGPU Display Connectors [drm] Connector 0: [drm] eDP-1 [drm] HPD1 [drm] DDC: 0x4868 0x4868 0x4869 0x4869 0x486a 0x486a 0x486b 0x486b [drm] Encoders: [drm] LCD1: INTERNAL_UNIPHY [drm] Connector 1: [drm] HDMI-A-1 [drm] HPD2 [drm] DDC: 0x486c 0x486c 0x486d 0x486d 0x486e 0x486e 0x486f 0x486f [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY > What kind of artifacts in plymouth? https://pasteboard.co/hWu18yPj0.jpg > Does e.g. X work correctly? Yes, disabling the stack protection xorg works fine (no panic, but I still have the display corruption at boot and on poweroff/reboot) -- 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 101224] texelFetch(usampler) returns black color
https://bugs.freedesktop.org/show_bug.cgi?id=101224 --- Comment #4 from Nicolai Hähnle --- Hi Pierre-Marc! Conceptually, glTextureStorage can't take care of the sampler settings unfortuantely because of the possibility of having separate sampler objects. I agree with you though that having a debug message on incomplete textures would be useful. -- 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: [linux-sunxi] Re: [PATCH v2 10/11] ARM: sun8i: h3: add display engine pipeline for TVE
On Sun, Jun 11, 2017 at 02:58:47PM +0800, icen...@aosc.io wrote:
> 在 2017-06-07 17:42，Maxime Ripard 写道：
> > On Mon, Jun 05, 2017 at 12:01:48AM +0800, Icenowy Zheng wrote:
> > > + soc {
> > > + display_clocks: clock@100 {
> > > + compatible = "allwinner,sun8i-a83t-de2-clk";
> > > + reg = <0x0100 0x10>;
> > > + clocks = <&ccu CLK_BUS_DE>,
> > > + <&ccu CLK_DE>;
> > > + clock-names = "bus",
> > > + "mod";
> > > + resets = <&ccu RST_BUS_DE>;
> > > + #clock-cells = <1>;
> > > + #reset-cells = <1>;
> > > + assigned-clocks = <&ccu CLK_DE>;
> > > + assigned-clock-parents = <&ccu CLK_PLL_DE>;
> > > + assigned-clock-rates = <43200>;
> > > + };
> >
> > We discussed that already a few times, but there's no reason to do
> > so. If you need a downstream clock at a particular rate, call
> > clk_set_rate on it, period.
> >
> > Whether its parent will be coming from PLL_DE or some other more
> > appriopriate clock is not relevant and doesn't make any difference.
>
> The clock framework is not so smart to deal with these infomations:
> - CLK_PLL_PERIPH should always be 600MHz
> - CLK_TVE should always be 216MHz
> - CLK_DE (in fact CLK_MIXER{0,1}) should be larger than 300MHz (for 4K)
None of what you're doing guarantees what you state above, so I'm not
really sure what your point is.
> So we have to specify CLK_DE to be 432MHz, and then it will set
> CLK_PLL_DE to this value, then the CLK_TVE can be set to 216MHz with
> divider 2.
Yes, but it works by accident. Any clock change somewhere in the same
clock-tree might break whatever you have set in the DT.
Hence why you want to do it within the clock framework and your
driver, not here.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/vc4: Add get/set tiling ioctls.
Hi Eric, On 8 June 2017 at 01:13, Eric Anholt wrote: > This allows mesa to set the tiling format for a BO and have that > tiling format be respected by mesa on the other side of an > import/export (and by vc4 scanout in the kernel), without defining a > protocol to pass the tiling through userspace. I posted a DRI3 v1.1 patch series which can advertise and also transit modifiers directly under X11, and have also typed up the support for Wayland which is working just fine with Weston from git. If you implement DRIimage v15 to advertise and import modifiers, then you can transit them for free without a magic-back-channel ioctl. Would that be enough to convince you to drop this series? Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101387] amdgpu display corruption and hang on AMD A10-9620P
https://bugs.freedesktop.org/show_bug.cgi?id=101387 --- Comment #4 from Michel Dänzer --- (In reply to Carlo Caione from comment #3) > > What kind of artifacts in plymouth? > https://pasteboard.co/hWu18yPj0.jpg That could be a plymouth bug. I've noticed that it doesn't seem to call drmModeCrtcSetGamma to make sure the display CLUTs are initialized to appropriate values. -- 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 101387] amdgpu display corruption and hang on AMD A10-9620P
https://bugs.freedesktop.org/show_bug.cgi?id=101387 --- Comment #5 from Carlo Caione --- > That could be a plymouth bug. I've noticed that it doesn't seem to call > drmModeCrtcSetGamma to make sure the display CLUTs are initialized to > appropriate values. Yeah, it could be, I'll investigate the plymouth issue later, right now the kernel panic situation is the top priority on my list :D Any idea what's triggering the stack corruption? I'm still investigating but right now my bet is on casting args to (uint32_t *) in amdgpu_atom_execute_table(adev->mode_info.atom_context, index, (uint32_t *)&args); -- 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 101278] Severe slowdown on Shadow of Mordor between 17.1.0 and 17.1.1
https://bugs.freedesktop.org/show_bug.cgi?id=101278 nagrigoria...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #3 from nagrigoria...@gmail.com --- Thanks Nicolai for your quick action. I first built the latest git master: 2e28e8b199abab76fa9509d3247b44a2cb31921d But everything was green, and the game would crash in the menu. I then built 391673af7ad1565a5f6ac8fc2f8c9fcdd1fe9908 And it worked, but performance is still in the regressed state :-( The thing is, tessellation was off this whole time. Please advise? -- 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 0/3] drm/omap: misc fixes
Hi, Here's three fixes for omapdrm: - fix synclost flood on omap3 - fix analog tv-out videomode check - fix DSI PLL setup Tony, Aaro, Nikolaus, can you see if these fix the issues you're seeing? Tomi Tomi Valkeinen (3): drm/omap: work-around for omap3 display enable drm/omap: fix analog tv-out modecheck drm/omap: fix i886 work-around drivers/gpu/drm/omapdrm/dss/dispc.c | 14 +++ drivers/gpu/drm/omapdrm/dss/dss.h | 3 ++ drivers/gpu/drm/omapdrm/dss/pll.c | 29 ++- drivers/gpu/drm/omapdrm/dss/venc.c | 65 ++--- drivers/gpu/drm/omapdrm/dss/video-pll.c | 2 + 5 files changed, 90 insertions(+), 23 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings
Hi,
Just spotted this thread.
On 06.06.2017 14:58, Tomi Valkeinen wrote:
> On 06/06/17 15:48, Boris Brezillon wrote:
>
>> Okay. Thanks for the clarification. Can you confirm that this version
>> is correct?
>>
>> dsi@xxx {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> dpi_in: port@0 {
>> reg = <0>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> endpoint@0 {
>> remote-endpoint = <&dpi_out>;
>> };
>> };
>>
>> dsi_out: port@1 {
>> reg = <1>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> dsi_out_vc0: endpoint@0 {
>> reg = <0>;
>> remote-endpoint = <&dsi_panel0_in>;
>> };
>>
>> dsi_out_vc1: endpoint@1 {
>> reg = <1>;
>> remote-endpoint = <&dsi_panel1_in>;
>> };
>> };
>> };
>>
>> panel@0 {
>> compatible = "...";
>> reg = <0>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> port@0 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> reg = <0>;
>>
>> dsi_panel0_in: endpoint@0 {
>> reg = <0>;
>> remote-endpoint = <&dsi_out_vc0>;
>> };
>> };
>> };
>>
>> panel@1 {
>> compatible = "...";
>> reg = <1>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> port@0 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> reg = <0>;
>>
>> dsi_panel1_in: endpoint@0 {
>> reg = <0>;
>> remote-endpoint = <&dsi_out_vc1>;
>> };
>> };
>> };
>> };
>>
> Looks correct to me. I think it can be a bit shorter though:
>
> - You don't need #address-cells and #size-cells for all. I think those
> are inherited from the parent.
> - If there's just one port and one endpoint, you can leave the 'reg'
> out, as it's considered to be 0 by default.
>
> So for the panel, you can have just:
>
> port {
> dsi_panel1_in: endpoint {
> remote-endpoint = <&dsi_out_vc1>;
> };
> };
In case DSI bus is used to both control and sending video signal you can
skip video links from dsi-host to dsi-child, so nodes can look like:
dsi@xxx {
#address-cells = <1>;
#size-cells = <0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
dpi_in: port@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
endpoint@0 {
remote-endpoint = <&dpi_out>;
};
};
};
panel@0 {
compatible = "...";
reg = <0>;
};
panel@1 {
compatible = "...";
reg = <1>;
};
};
Regards
Andrzej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/omap: fix analog tv-out modecheck
omapdrm rejects all venc (analog tv-out) videomodes, due to somewhat
strict checking of the values, making tv-out unusable.
We only support two videomodes, one for PAL and one for NTSC, so instead
of trying to check every field in the videomode struct, this patch makes
the driver check only the pixel clock and the size of the display.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/venc.c | 65 ++
1 file changed, 51 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/venc.c
b/drivers/gpu/drm/omapdrm/dss/venc.c
index 19d14957f566..68e73277719e 100644
--- a/drivers/gpu/drm/omapdrm/dss/venc.c
+++ b/drivers/gpu/drm/omapdrm/dss/venc.c
@@ -263,6 +263,12 @@ static const struct venc_config venc_config_pal_bdghi = {
.fid_ext_start_y__fid_ext_offset_y = 0x01380005,
};
+enum venc_videomode {
+ VENC_MODE_UNKNOWN,
+ VENC_MODE_PAL,
+ VENC_MODE_NTSC,
+};
+
const struct videomode omap_dss_pal_vm = {
.hactive= 720,
.vactive= 574,
@@ -299,6 +305,24 @@ const struct videomode omap_dss_ntsc_vm = {
};
EXPORT_SYMBOL(omap_dss_ntsc_vm);
+static enum venc_videomode venc_get_videomode(const struct videomode *vm)
+{
+ if (!(vm->flags & DISPLAY_FLAGS_INTERLACED))
+ return VENC_MODE_UNKNOWN;
+
+ if (vm->pixelclock == omap_dss_pal_vm.pixelclock &&
+ vm->hactive == omap_dss_pal_vm.hactive &&
+ vm->vactive == omap_dss_pal_vm.vactive)
+ return VENC_MODE_PAL;
+
+ if (vm->pixelclock == omap_dss_ntsc_vm.pixelclock &&
+ vm->hactive == omap_dss_ntsc_vm.hactive &&
+ vm->vactive == omap_dss_ntsc_vm.vactive)
+ return VENC_MODE_NTSC;
+
+ return VENC_MODE_UNKNOWN;
+}
+
static struct {
struct platform_device *pdev;
void __iomem *base;
@@ -424,14 +448,14 @@ static void venc_runtime_put(void)
static const struct venc_config *venc_timings_to_config(struct videomode *vm)
{
- if (memcmp(&omap_dss_pal_vm, vm, sizeof(*vm)) == 0)
+ switch (venc_get_videomode(vm)) {
+ default:
+ WARN_ON_ONCE(1);
+ case VENC_MODE_PAL:
return &venc_config_pal_trm;
-
- if (memcmp(&omap_dss_ntsc_vm, vm, sizeof(*vm)) == 0)
+ case VENC_MODE_NTSC:
return &venc_config_ntsc_trm;
-
- BUG();
- return NULL;
+ }
}
static int venc_power_on(struct omap_dss_device *dssdev)
@@ -542,15 +566,28 @@ static void venc_display_disable(struct omap_dss_device
*dssdev)
static void venc_set_timings(struct omap_dss_device *dssdev,
struct videomode *vm)
{
+ struct videomode actual_vm;
+
DSSDBG("venc_set_timings\n");
mutex_lock(&venc.venc_lock);
+ switch (venc_get_videomode(vm)) {
+ default:
+ WARN_ON_ONCE(1);
+ case VENC_MODE_PAL:
+ actual_vm = omap_dss_pal_vm;
+ break;
+ case VENC_MODE_NTSC:
+ actual_vm = omap_dss_ntsc_vm;
+ break;
+ }
+
/* Reset WSS data when the TV standard changes. */
- if (memcmp(&venc.vm, vm, sizeof(*vm)))
+ if (memcmp(&venc.vm, &actual_vm, sizeof(actual_vm)))
venc.wss_data = 0;
- venc.vm = *vm;
+ venc.vm = actual_vm;
dispc_set_tv_pclk(1350);
@@ -562,13 +599,13 @@ static int venc_check_timings(struct omap_dss_device
*dssdev,
{
DSSDBG("venc_check_timings\n");
- if (memcmp(&omap_dss_pal_vm, vm, sizeof(*vm)) == 0)
+ switch (venc_get_videomode(vm)) {
+ case VENC_MODE_PAL:
+ case VENC_MODE_NTSC:
return 0;
-
- if (memcmp(&omap_dss_ntsc_vm, vm, sizeof(*vm)) == 0)
- return 0;
-
- return -EINVAL;
+ default:
+ return -EINVAL;
+ }
}
static void venc_get_timings(struct omap_dss_device *dssdev,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/omap: work-around for omap3 display enable
Seems that on omap3 enabling a crtc without any planes causes a sync
lost flood. This only happens on the first enable, and after that it
works. This looks like an HW issue.
It's unclear why this is happening or how to fix it, but as a quick
work-around, this patch enables i734 errata work-around for omap2 and
omap3 too. The errata work-around enables and disables the LCD output
with a plane once when waking up the DSS IP, and it seems to resolve the
omap3 problem too. It is unclear if omap2 has the same issue, but it
probably has and the WA should have no side effects so it should be safe
to enable on omap2 too.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
b/drivers/gpu/drm/omapdrm/dss/dispc.c
index 5ac0145fbae6..75e89707a70a 100644
--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
+++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
@@ -4004,6 +4004,11 @@ static const struct dispc_features omap24xx_dispc_feats
= {
.no_framedone_tv= true,
.set_max_preload= false,
.last_pixel_inc_missing = true,
+ /*
+* HACK: see comment in omap34xx_rev1_0_dispc_feats. OMAP2 probably
+* has the same issue.
+*/
+ .has_gamma_i734_bug = true,
};
static const struct dispc_features omap34xx_rev1_0_dispc_feats = {
@@ -4025,6 +4030,13 @@ static const struct dispc_features
omap34xx_rev1_0_dispc_feats = {
.no_framedone_tv= true,
.set_max_preload= false,
.last_pixel_inc_missing = true,
+ /*
+* HACK: OMAP3 doesn't have i734, but enabling the lcd output without
+* planes causes synclost flood. This only happens on initial enable,
+* not after that.
+* Piggyback on i734 flag until we understand this better.
+*/
+ .has_gamma_i734_bug = true,
};
static const struct dispc_features omap34xx_rev3_0_dispc_feats = {
@@ -4046,6 +4058,8 @@ static const struct dispc_features
omap34xx_rev3_0_dispc_feats = {
.no_framedone_tv= true,
.set_max_preload= false,
.last_pixel_inc_missing = true,
+ /* HACK: see comment in omap34xx_rev1_0_dispc_feats */
+ .has_gamma_i734_bug = true,
};
static const struct dispc_features omap44xx_dispc_feats = {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/omap: fix i886 work-around
7d267f068a8b4944d52e8b0ae4c8fcc1c1c5c5ba ("drm/omap: work-around for
errata i886") changed how the PLL dividers and multipliers are
calculated. While the new way should work fine for all the PLLs, it
breaks omap5 PLLs. The issues seen are rather odd: seemed that the
output clock rate is half of what we asked. It is unclear what's causing
there issues.
As a work-around this patch adds a "errata_i886" flag, which is set only
for DRA7's PLLs, and the PLL setup is done according to that flag.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dss.h | 3 +++
drivers/gpu/drm/omapdrm/dss/pll.c | 29 -
drivers/gpu/drm/omapdrm/dss/video-pll.c | 2 ++
3 files changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dss.h
b/drivers/gpu/drm/omapdrm/dss/dss.h
index 5dd29c98143a..8ea3daa9aed9 100644
--- a/drivers/gpu/drm/omapdrm/dss/dss.h
+++ b/drivers/gpu/drm/omapdrm/dss/dss.h
@@ -174,6 +174,9 @@ struct dss_pll_hw {
bool has_freqsel;
bool has_selfreqdco;
bool has_refsel;
+
+ /* DRA7 errata i886: use high N & M to avoid jitter */
+ bool errata_i886;
};
struct dss_pll {
diff --git a/drivers/gpu/drm/omapdrm/dss/pll.c
b/drivers/gpu/drm/omapdrm/dss/pll.c
index 5e221302768b..9d9d9d42009b 100644
--- a/drivers/gpu/drm/omapdrm/dss/pll.c
+++ b/drivers/gpu/drm/omapdrm/dss/pll.c
@@ -215,8 +215,8 @@ bool dss_pll_calc_a(const struct dss_pll *pll, unsigned
long clkin,
dss_pll_calc_func func, void *data)
{
const struct dss_pll_hw *hw = pll->hw;
- int n, n_min, n_max;
- int m, m_min, m_max;
+ int n, n_start, n_stop, n_inc;
+ int m, m_start, m_stop, m_inc;
unsigned long fint, clkdco;
unsigned long pll_hw_max;
unsigned long fint_hw_min, fint_hw_max;
@@ -226,22 +226,33 @@ bool dss_pll_calc_a(const struct dss_pll *pll, unsigned
long clkin,
fint_hw_min = hw->fint_min;
fint_hw_max = hw->fint_max;
- n_min = max(DIV_ROUND_UP(clkin, fint_hw_max), 1ul);
- n_max = min((unsigned)(clkin / fint_hw_min), hw->n_max);
+ n_start = max(DIV_ROUND_UP(clkin, fint_hw_max), 1ul);
+ n_stop = min((unsigned)(clkin / fint_hw_min), hw->n_max);
+ n_inc = 1;
+
+ if (hw->errata_i886) {
+ swap(n_start, n_stop);
+ n_inc = -1;
+ }
pll_max = pll_max ? pll_max : ULONG_MAX;
- /* Try to find high N & M to avoid jitter (DRA7 errata i886) */
- for (n = n_max; n >= n_min; --n) {
+ for (n = n_start; n != n_stop; n += n_inc) {
fint = clkin / n;
- m_min = max(DIV_ROUND_UP(DIV_ROUND_UP(pll_min, fint), 2),
+ m_start = max(DIV_ROUND_UP(DIV_ROUND_UP(pll_min, fint), 2),
1ul);
- m_max = min3((unsigned)(pll_max / fint / 2),
+ m_stop = min3((unsigned)(pll_max / fint / 2),
(unsigned)(pll_hw_max / fint / 2),
hw->m_max);
+ m_inc = 1;
+
+ if (hw->errata_i886) {
+ swap(m_start, m_stop);
+ m_inc = -1;
+ }
- for (m = m_max; m >= m_min; --m) {
+ for (m = m_start; m != m_stop; m += m_inc) {
clkdco = 2 * m * fint;
if (func(n, m, fint, clkdco, data))
diff --git a/drivers/gpu/drm/omapdrm/dss/video-pll.c
b/drivers/gpu/drm/omapdrm/dss/video-pll.c
index 7429de928d4e..8201ecf826d9 100644
--- a/drivers/gpu/drm/omapdrm/dss/video-pll.c
+++ b/drivers/gpu/drm/omapdrm/dss/video-pll.c
@@ -131,6 +131,8 @@ static const struct dss_pll_hw dss_dra7_video_pll_hw = {
.mX_lsb[3] = 5,
.has_refsel = true,
+
+ .errata_i886 = true,
};
struct dss_pll *dss_video_pll_init(struct platform_device *pdev, int id,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: hibmc: Use set_busid function from drm core
Hi Daniel,
On 9 June 2017 at 07:57, Daniel Axtens wrote:
> Currently, calling drmGetBusid from libdrm on a hibmc VGA
> card returns a string like "0007:a1:00.0".
>
> The busid reported by most cards begins with "pci:". For
> example, on an amd64 system, a VGA card reported
> "pci::00:02.0".
>
> The missing "pci:" prefix confuses Xorg and leads to crashes
> and other misbehaviour.[0]
>
> Use the standard helper from the drm core to set the busid to
> include the "pci:" prefix. This is done by many other drivers.
>
> With this patch, Xorg can be run successfully.
>
> [0]: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991
>
> Cc: Xinliang Liu
> Cc: Rongrong Zou
> Signed-off-by: Daniel Axtens
> ---
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> index 2ffdbf9801bd..9663a633897a 100644
> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
> @@ -69,6 +69,7 @@ static struct drm_driver hibmc_driver = {
> .dumb_map_offset= hibmc_dumb_mmap_offset,
> .dumb_destroy = drm_gem_dumb_destroy,
> .irq_handler= hibmc_drm_interrupt,
> + .set_busid = drm_pci_set_busid,
Daniel V has been working very hard on cleaning all the set_busid
"chaos" and even has some patches which remove it completely [1].
While your patch is correct, it would be nicer if we can remove the
code so that nobody else gets bitten ;-)
Can you be so kind and re-spin your patch with the cleanups (2-4) on top?
IIRC your fix should be CC kernel-stable.
Thanks
Emil
[1] https://lists.freedesktop.org/archives/dri-devel/2017-May/142670.html
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101401] [REGRESSION][BISECTED] GDM fails to start after 8ec4975cd83365c791a1
https://bugs.freedesktop.org/show_bug.cgi?id=101401 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Michel Dänzer --- Thanks for the report, fixed in Git: Module: Mesa Branch: master Commit: 6d8a387f78cdeedc8c404a1b4c116a19023f2e19 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=6d8a387f78cdeedc8c404a1b4c116a19023f2e19 Author: Samuel Pitoiset Date: Tue Jun 13 10:03:52 2017 +0200 st_glsl_to_tgsi: init index to 0 before get_deref_offsets() -- 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] drm/exynos/dsi: Remove error handling for bridge_node DT parsing
2017년 06월 09일 18:23에 Hoegeun Kwon 이(가) 쓴 글: > The bridge_node is unnecessary between FIMD and DSIM. If don't remove > error handling, it will not work between FIMD and DSIM. So remove > error handling. Please make sure to describe why bridge_node is unnecessary. For example, In case of Exynos SoC, a bridge device such as mDNIe and MIC could be placed between Display Controller and MIPI DSI device but the bridge device is required optionally. Thanks, Inki Dae > > Signed-off-by: Hoegeun Kwon > --- > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c > b/drivers/gpu/drm/exynos/exynos_drm_dsi.c > index a11b795..6ee0dac 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c > @@ -1651,8 +1651,6 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi) > return ret; > > dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0); > - if (!dsi->bridge_node) > - return -EINVAL; > > return 0; > } > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2
On Sat, Jun 10, 2017 at 10:57:28PM +0800, icen...@aosc.io wrote: > 在 2017-06-09 22:46，Maxime Ripard 写道： > > On Thu, Jun 08, 2017 at 01:01:53PM +0800, icen...@aosc.io wrote: > > > 在 2017-06-07 22:38，Maxime Ripard 写道： > > > > On Wed, Jun 07, 2017 at 06:01:02PM +0800, Icenowy Zheng wrote: > > > > > >I have no idea what this is supposed to be doing either. > > > > > > > > > > > >I might be wrong, but I really feel like there's a big mismatch > > > > > >between your commit log, and what you actually implement. > > > > > > > > > > > >In your commit log, you should state: > > > > > > > > > > > >A) What is the current behaviour > > > > > >B) Why that is a problem > > > > > >C) How do you address it > > > > > > > > > > > >And you don't. > > > > > > > > > > > >However, after discussing it with Chen-Yu, it seems like you're > > > > > >trying > > > > > >to have all the mixers probed before the TCONs. If that is so, > > > > > >there's > > > > > >nothing specific to the H3 here, and we also have the same issue on > > > > > >dual-pipeline DE1 (A10, A20, A31). Chen-Yu worked on that a bit, but > > > > > >the easiest solution would be to move from a DFS algorithm to walk > > > > > >down the graph to a BFS one. > > > > > > > > > > > >That way, we would add all mixers first, then the TCONs, then the > > > > > >encoders, and the component framework will probe them in order. > > > > > > > > > > No. I said that they're swappable, however, I don't want to > > > > > implement the swap now, but hardcode 0-0 1-1 connection. > > > > > > > > We're on the same page, it's definitely not what I was mentionning > > > > here. This would require a significant rework, and the usecase is > > > > still unclear for now. > > > > > > > > > However, as you and Chen-Yu said, device tree should reflect the > > > > > real hardware, there will be bonus endpoints for the swapped > > > > > connection. > > > > > > > > If by bonus you mean connections from mixer 0 to tcon 1 and mixer 1 to > > > > tcon 0, then yes, we're going to need it. > > > > > > > > > What I want to do is to ignore the bonus connection, in order to > > > > > prevent them from confusing the code. > > > > > > > > > > If you just change the bind sequence, I think it cannot be > > > > > prevented that wrong connections will be bound. > > > > > > > > This is where I don't follow you anymore. The component framework > > > > doesn't list connections but devices. The swapped connections do not > > > > matter here, we have the same set of devices: mixer0, mixer1, tcon0 > > > > and tcon1. > > > > > > > > The thing that does change with your patch is that before, the binding > > > > sequence would have been mixer0, tcon0, tcon1, mixer1. With your > > > > patch, it's mixer0, tcon0, mixer1, tcon1. > > > > > > > > So, again, stating what issue you were seeing before making this patch > > > > would be very helpful to see what you're trying to do / fix. > > > > > > So maybe I can drop the forward search (searching output) code, and > > > keep > > > only the backward search (search input) code in TCON? > > > > > > Forward search code is only used when binding, but backward search > > > is used > > > for TCON to find connected mixer. > > > > It is hard to talk about a solution, when it's not clear what the > > issue is. > > > > So please state > > > > > >A) What is the current behaviour > > > > > >B) Why that is a problem > > > > > >C) How do you address it > > > > We'll talk about a solution once this is done. > > (All those things are based on the assumption that mixer0, mixer1, tcon0 > and tcon1 are all enabled in DT. If one group of mixer-tcon pair is fully > disabled in DT it will behave properly.) > > For the backward search: > > A) The current behaviour is to take the first engine found, which will be > wrong in the situation of tcon1 if mixer0 and mixer1 are both enabled: > mixer0 is taken for tcon1 instead of mixer1. > > B) It takes mixer0 as it matches the first endpoint of tcon0's input. > > C) It's a logic failure in the backward search, as it only considered > the DE1 situation, in which TCONs will only have one engine as input. That's not true. DE1's can output to several TCONs (or rather, TCONs can select multiple engines as their input). The A31 for example is in this case. I think what Chen-Yu did so far is that he only enables one engine and TCON for now. That will leave us some time to rework and improve things gradually. It would probably be easier (and faster) for you too. > For the bind process: > > A) The current behaviour is to try to bind all output endpoints of the > engine, during binding all outputs of mixer0, these will happen: > 1. tcon1 is bound with mixer0 as its engine if backward searching > is not fixed. > 2. tcon1 fails to be bound as its engine is not yet bound when > backward searching works properly, then sun4i_drv will refuse > to continue as a component is not properly bound. So this is the ordering issue I was mentionning earlier. Th
Re: [PATCH v2 03/11] drm: sun4i: ignore swapped mixer<->tcon connection for DE2
On Sat, Jun 10, 2017 at 11:16:35PM +0800, icen...@aosc.io wrote: > 在 2017-06-10 22:57，icen...@aosc.io 写道： > > 在 2017-06-09 22:46，Maxime Ripard 写道： > > > On Thu, Jun 08, 2017 at 01:01:53PM +0800, icen...@aosc.io wrote: > > > > 在 2017-06-07 22:38，Maxime Ripard 写道： > > > > > On Wed, Jun 07, 2017 at 06:01:02PM +0800, Icenowy Zheng wrote: > > > > > > >I have no idea what this is supposed to be doing either. > > > > > > > > > > > > > >I might be wrong, but I really feel like there's a big mismatch > > > > > > >between your commit log, and what you actually implement. > > > > > > > > > > > > > >In your commit log, you should state: > > > > > > > > > > > > > >A) What is the current behaviour > > > > > > >B) Why that is a problem > > > > > > >C) How do you address it > > > > > > > > > > > > > >And you don't. > > > > > > > > > > > > > >However, after discussing it with Chen-Yu, it seems like you're > > > > > > >trying > > > > > > >to have all the mixers probed before the TCONs. If that is so, > > > > > > >there's > > > > > > >nothing specific to the H3 here, and we also have the same issue on > > > > > > >dual-pipeline DE1 (A10, A20, A31). Chen-Yu worked on that a bit, > > > > > > >but > > > > > > >the easiest solution would be to move from a DFS algorithm to walk > > > > > > >down the graph to a BFS one. > > > > > > > > > > > > > >That way, we would add all mixers first, then the TCONs, then the > > > > > > >encoders, and the component framework will probe them in order. > > > > > > > > > > > > No. I said that they're swappable, however, I don't want to > > > > > > implement the swap now, but hardcode 0-0 1-1 connection. > > > > > > > > > > We're on the same page, it's definitely not what I was mentionning > > > > > here. This would require a significant rework, and the usecase is > > > > > still unclear for now. > > > > > > > > > > > However, as you and Chen-Yu said, device tree should reflect the > > > > > > real hardware, there will be bonus endpoints for the swapped > > > > > > connection. > > > > > > > > > > If by bonus you mean connections from mixer 0 to tcon 1 and mixer 1 to > > > > > tcon 0, then yes, we're going to need it. > > > > > > > > > > > What I want to do is to ignore the bonus connection, in order to > > > > > > prevent them from confusing the code. > > > > > > > > > > > > If you just change the bind sequence, I think it cannot be > > > > > > prevented that wrong connections will be bound. > > > > > > > > > > This is where I don't follow you anymore. The component framework > > > > > doesn't list connections but devices. The swapped connections do not > > > > > matter here, we have the same set of devices: mixer0, mixer1, tcon0 > > > > > and tcon1. > > > > > > > > > > The thing that does change with your patch is that before, the binding > > > > > sequence would have been mixer0, tcon0, tcon1, mixer1. With your > > > > > patch, it's mixer0, tcon0, mixer1, tcon1. > > > > > > > > > > So, again, stating what issue you were seeing before making this patch > > > > > would be very helpful to see what you're trying to do / fix. > > > > > > > > So maybe I can drop the forward search (searching output) code, > > > > and keep > > > > only the backward search (search input) code in TCON? > > > > > > > > Forward search code is only used when binding, but backward > > > > search is used > > > > for TCON to find connected mixer. > > > > > > It is hard to talk about a solution, when it's not clear what the > > > issue is. > > > > > > So please state > > > > > > >A) What is the current behaviour > > > > > > >B) Why that is a problem > > > > > > >C) How do you address it > > > > > > We'll talk about a solution once this is done. > > > > (All those things are based on the assumption that mixer0, mixer1, tcon0 > > and tcon1 are all enabled in DT. If one group of mixer-tcon pair is > > fully > > disabled in DT it will behave properly.) > > So there's a temporary workaround -- only enable one pipeline and disable > the unused mixer and tcon totally. As a short-term workaround, while we rework the code to enable both pipelines, it definitely works for me. Maxim -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm v8] amdgpu: move asic id table to a separate file
From: Xiaojie Yuan
v2: fix an off by one error and leading white spaces
v3: use thread safe strtok_r(); initialize len before calling getline();
change printf() to drmMsg(); add initial amdgpu.ids
v4: integrate some recent internal changes, including format changes
v5: fix line number for empty/commented lines; realloc to save memory;
indentation changes
v6: remove a line error
v7: [Michel Dänzer]
* Move amdgpu.ids to new data directory
* Remove placeholder entries from amdgpu.ids
* Set libdrmdatadir variable in configure.ac instead of Makefile.am
[Emil Velikov]
* Use isblank() instead of open-coding it [Emil Velikov]
* Don't leak asic_id_table memory if realloc fails [Emil Velikov]
* Check and bump table_max_size at the beginning of the while loop [Emil
Velikov]
* Initialize table_max_size to the number of entries in data/amdgpu.ids
v8: [Michel Dänzer]
* Make sure amdgpu_asic_id.c gets rebuilt when amdgpu.ids changes
Reviewed-by: Alex Deucher # v7
Signed-off-by: Samuel Li
Signed-off-by: Michel Dänzer
---
Makefile.am | 1 +
amdgpu/Makefile.am | 7 ++
amdgpu/Makefile.sources | 2 +-
amdgpu/amdgpu_asic_id.c | 219 +++
amdgpu/amdgpu_asic_id.h | 165 ---
amdgpu/amdgpu_device.c | 28 --
amdgpu/amdgpu_internal.h | 10 +++
configure.ac | 4 +
data/Makefile.am | 23 +
data/amdgpu.ids | 159 ++
10 files changed, 445 insertions(+), 173 deletions(-)
create mode 100644 amdgpu/amdgpu_asic_id.c
delete mode 100644 amdgpu/amdgpu_asic_id.h
create mode 100644 data/Makefile.am
create mode 100644 data/amdgpu.ids
diff --git a/Makefile.am b/Makefile.am
index dfb8fcdb..7b86214e 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -109,6 +109,7 @@ SUBDIRS = \
$(TEGRA_SUBDIR) \
$(VC4_SUBDIR) \
$(ETNAVIV_SUBDIR) \
+ data \
tests \
$(MAN_SUBDIR)
diff --git a/amdgpu/Makefile.am b/amdgpu/Makefile.am
index cf7bc1ba..66f6f676 100644
--- a/amdgpu/Makefile.am
+++ b/amdgpu/Makefile.am
@@ -30,12 +30,19 @@ AM_CFLAGS = \
$(PTHREADSTUBS_CFLAGS) \
-I$(top_srcdir)/include/drm
+libdrmdatadir = @libdrmdatadir@
+ASIC_ID_TABLE_NUM_ENTRIES := $(shell egrep -ci '^[0-9a-f]{4},.*[0-9a-f]+,' \
+ $(top_srcdir)/data/amdgpu.ids)
+AM_CPPFLAGS = -DAMDGPU_ASIC_ID_TABLE=\"${libdrmdatadir}/amdgpu.ids\" \
+ -DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=$(ASIC_ID_TABLE_NUM_ENTRIES)
+
libdrm_amdgpu_la_LTLIBRARIES = libdrm_amdgpu.la
libdrm_amdgpu_ladir = $(libdir)
libdrm_amdgpu_la_LDFLAGS = -version-number 1:0:0 -no-undefined
libdrm_amdgpu_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
libdrm_amdgpu_la_SOURCES = $(LIBDRM_AMDGPU_FILES)
+amdgpu_asic_id.lo: $(top_srcdir)/data/amdgpu.ids
libdrm_amdgpuincludedir = ${includedir}/libdrm
libdrm_amdgpuinclude_HEADERS = $(LIBDRM_AMDGPU_H_FILES)
diff --git a/amdgpu/Makefile.sources b/amdgpu/Makefile.sources
index 487b9e0a..bc3abaa6 100644
--- a/amdgpu/Makefile.sources
+++ b/amdgpu/Makefile.sources
@@ -1,5 +1,5 @@
LIBDRM_AMDGPU_FILES := \
- amdgpu_asic_id.h \
+ amdgpu_asic_id.c \
amdgpu_bo.c \
amdgpu_cs.c \
amdgpu_device.c \
diff --git a/amdgpu/amdgpu_asic_id.c b/amdgpu/amdgpu_asic_id.c
new file mode 100644
index ..3a88896b
--- /dev/null
+++ b/amdgpu/amdgpu_asic_id.c
@@ -0,0 +1,219 @@
+/*
+ * Copyright © 2017 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "xf86drm.h"
+#include "amdgpu_drm.h"
+#include "amdgpu_internal.h"
+
+static int parse_one_line(const char *line, struct amdgpu_asic_id *id)
+{
+ char *buf, *saveptr;
+ char *s_did;
+ char *s_rid;
+ char *s_
Re: [PATCH 3/7] drm/vc4: Mimic drm_atomic_helper_commit() behavior
+Gustavo On Tue, 06 Jun 2017 13:27:09 -0700 Eric Anholt wrote: > Boris Brezillon writes: > > > The VC4 KMS driver is implementing its own ->atomic_commit() but there > > are a few generic helpers we can use instead of open-coding the logic. > > > > Signed-off-by: Boris Brezillon > > --- > > drivers/gpu/drm/vc4/vc4_kms.c | 38 -- > > 1 file changed, 12 insertions(+), 26 deletions(-) > > > > diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c > > index ad7925a9e0ea..f229abc0991b 100644 > > --- a/drivers/gpu/drm/vc4/vc4_kms.c > > +++ b/drivers/gpu/drm/vc4/vc4_kms.c > > @@ -42,6 +42,10 @@ vc4_atomic_complete_commit(struct vc4_commit *c) > > struct drm_device *dev = state->dev; > > struct vc4_dev *vc4 = to_vc4_dev(dev); > > > > + drm_atomic_helper_wait_for_fences(dev, state, false); > > + > > + drm_atomic_helper_wait_for_dependencies(state); > > With this wait_for_fences() addition and the reservation stuff that > landed, I think we can rip out the "seqno cb" in vc4, and just use > drm_atomic_helper_commit() and drm_atomic_hepler_commit_tail(). Do you > see anything missing, with that? We can probably get rid of "seqno cb", but I'm not sure we have everything in place to use drm_atomic_helper_commit_tail() and drm_atomic_helper_commit() yet. What about async page flips? The async_modeset semaphore is taken in vc4_atomic_commit() to prevent races with async page flips. Can we safely get rid of this? Would Gustavo's work on async plane update help us get rid of this semaphore? Also note that patch 4 replaces the call to drm_atomic_helper_wait_for_vblanks() by one to drm_atomic_helper_wait_for_flip_done(), and we haven't decided yet if this is something we want to make generic. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/exynos/dsi: Remove error handling for bridge_node DT parsing
On 06/13/2017 06:25 PM, Inki Dae wrote: 2017년 06월 09일 18:23에 Hoegeun Kwon 이(가) 쓴 글: The bridge_node is unnecessary between FIMD and DSIM. If don't remove error handling, it will not work between FIMD and DSIM. So remove error handling. Please make sure to describe why bridge_node is unnecessary. For example, In case of Exynos SoC, a bridge device such as mDNIe and MIC could be placed between Display Controller and MIPI DSI device but the bridge device is required optionally. Thanks, Inki Dae Remove the error handling for bridge_node because the bridge_node is required optionally. It has already been described in commit message. For example, In case of Exynos 3250 SoC, no bridge_node is required between FIMD and MIPI DSI. Best regards, Hoegeun Signed-off-by: Hoegeun Kwon --- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c index a11b795..6ee0dac 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c @@ -1651,8 +1651,6 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi) return ret; dsi->bridge_node = of_graph_get_remote_node(node, DSI_PORT_IN, 0); - if (!dsi->bridge_node) - return -EINVAL; return 0; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] drm/vc4: Add support for the TXP (transposer) block
Hi Boris,
Sorry lost track of this thread.
On Tue, Jun 06, 2017 at 09:13:00PM +0200, Boris Brezillon wrote:
Hi Brian,
Le Mon, 5 Jun 2017 12:25:50 +0100,
Brian Starkey a écrit :
Hi Boris,
I can't speak for the HW-specific details, but the writeback part
looks pretty good (and familiar ;-) to me. There certainly seems to be
some scope for code-sharing there, but I think it's fine not to do it
yet.
Agreed.
I've a further query below about the handling of CRTC events.
[...]
>+
>+void vc4_txp_atomic_commit(struct drm_device *dev,
>+ struct drm_atomic_state *old_state)
>+{
>+ struct vc4_dev *vc4 = to_vc4_dev(dev);
>+ struct vc4_txp *txp = vc4->txp;
>+ struct drm_connector_state *conn_state = txp->connector.base.state;
>+ struct drm_display_mode *mode;
>+ struct drm_gem_cma_object *gem;
>+ struct drm_framebuffer *fb;
>+ u32 ctrl = TXP_GO | TXP_EI;
>+
>+ /* Writeback connector is disabled, nothing to do. */
>+ if (!conn_state->crtc)
>+ return;
>+
>+ /* Writeback connector is enabled, but has no FB assigned to it. Fake a
>+* vblank event to complete ->flip_done.
>+*/
>+ if (!conn_state->writeback_job || !conn_state->writeback_job->fb) {
>+ vc4_crtc_eof_event(conn_state->crtc);
I'm not sure about hiding away the one-shot thing like this. If the
CRTC remains "active" from the API point of view, I'd expect it to be
able to keep generating VBLANK events.
I don't know how to do if, but if there were some notion of
"auto-disabling" CRTCs then this quirk would go away, and you'd also
be able to enforce that the CRTC can't be enabled without a writeback
framebuffer.
I don't have a strong opinion on "auto-disabling CRTC" vs "fake VBLANK
events". Note that I'm already faking a VBLANK event when activating
writeback, because there's no such concept at the HVS/TXP level. We
do have EOF (End Of Frame) and writeback done events, but these are
quite independent from the VBLANK events generated by the pixelvalve
block (the block responsible for generating the HSYNC/VSYNC signals).
I'm also not sure how (if?) this works today with a CRTC driving a DSI
command-mode panel. Does the CRTC keep generating VBLANKs even when
there are no updates?
I don't know. Is this mandatory to have VBLANK events? I mean, the
core is using VBLANK events to detect when page flips have been done,
that is, when old framebuffers are unused and new ones started to be
fetched by the CRTC, but on some HW, VBLANK is not the only way to
detect such situations. The question is, are there other situations
where VBLANK events are required, or is there an implicit rule stating
that a CRTC has to generate VBLANK events at a vrefresh rate even when
the display is actually not updated when nothing changes?
I'm not sure how widely relied upon it is, but I'd expect that there's
a requirement to make sure DRM_IOCTL_WAIT_VBLANK works. I _think_ that
means the CRTC should generate events at vrefresh rate if there's a
wait request outstanding that depends on that.
It's not exactly documented though.
>+ return;
>+ }
>+
>+ fb = conn_state->writeback_job->fb;
>+
>+ switch (fb->format->format) {
>+ case DRM_FORMAT_ARGB:
>+ ctrl |= TXP_ALPHA_ENABLE;
>+ case DRM_FORMAT_XRGB:
>+ ctrl |= VC4_SET_FIELD(TXP_FORMAT_ARGB, TXP_FORMAT) |
>+ VC4_SET_FIELD(0xf, TXP_BYTE_ENABLE);
>+ break;
>+
>+ case DRM_FORMAT_ABGR:
>+ ctrl |= TXP_ALPHA_ENABLE;
>+ case DRM_FORMAT_XBGR:
>+ ctrl |= VC4_SET_FIELD(TXP_FORMAT_ABGR, TXP_FORMAT) |
>+ VC4_SET_FIELD(0xf, TXP_BYTE_ENABLE);
>+ break;
>+
>+ case DRM_FORMAT_RGBA:
>+ ctrl |= TXP_ALPHA_ENABLE;
>+ case DRM_FORMAT_RGBX:
>+ ctrl |= VC4_SET_FIELD(TXP_FORMAT_RGBA, TXP_FORMAT) |
>+ VC4_SET_FIELD(0xf, TXP_BYTE_ENABLE);
>+ break;
>+
>+ case DRM_FORMAT_BGRA:
>+ ctrl |= TXP_ALPHA_ENABLE;
>+ case DRM_FORMAT_BGRX:
>+ ctrl |= VC4_SET_FIELD(TXP_FORMAT_BGRA, TXP_FORMAT) |
>+ VC4_SET_FIELD(0xf, TXP_BYTE_ENABLE);
>+ break;
>+
>+ case DRM_FORMAT_BGR888:
>+ ctrl |= VC4_SET_FIELD(TXP_FORMAT_BGR888, TXP_FORMAT) |
>+ VC4_SET_FIELD(0xf, TXP_BYTE_ENABLE);
>+ break;
>+
>+ case DRM_FORMAT_RGB888:
>+ ctrl |= VC4_SET_FIELD(TXP_FORMAT_RGB888, TXP_FORMAT) |
>+ VC4_SET_FIELD(0xf, TXP_BYTE_ENABLE);
>+ break;
>+ default:
>+ WARN_ON(1);
>+ return;
>+ }
>+
>+ if (!(ctrl & TXP_ALPHA_ENABLE))
>+ ctrl |= TXP_ALPHA_INVERT;
>+
>+ mode = &conn_state->crtc->state->adjusted_mode;
>+ gem = drm_fb_cma_get_gem_obj(fb, 0);
>+ TXP_WRITE(TXP_DST_PTR, gem->paddr + fb->offsets[0]);
>+ TXP_WRITE(TXP_DST_PITCH, fb->pitches[0]);
>+ TXP_WRITE(TXP_DIM,
>+ VC4_SET_FIELD(mode->hdisplay, TXP_WIDTH) |
>+
Re: [PATCH v2] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus
On Mon, Jun 12, 2017 at 03:52:35PM +1000, Jonathan Liu wrote:
> The drm_get_edid function should be used instead of drm_do_get_edid by
> exposing the DDC bus as an I2C adapter. Implement this for A10s.
>
> Signed-off-by: Jonathan Liu
Your commit log should explain *why* that function should be used
instead, and why it's better to expose it as an i2c adadpter.
> ---
> Changes for v2:
> - Rebased against Maxime's sunxi-drm/for-next branch
> - Fix up error paths in sun4i_hdmi_bind so that the I2C adapter is deleted if
>any of the calls after the I2C adapter is created fails
> - Remove unnecessary includes in sun4i_hdmi_i2c.c
>
> drivers/gpu/drm/sun4i/Makefile | 1 +
> drivers/gpu/drm/sun4i/sun4i_hdmi.h | 11 ++-
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 103 +++--
> drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c | 163
> +
> 4 files changed, 189 insertions(+), 89 deletions(-)
> create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c
>
> diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
> index e29fd3a2ba9c..43c753cafc88 100644
> --- a/drivers/gpu/drm/sun4i/Makefile
> +++ b/drivers/gpu/drm/sun4i/Makefile
> @@ -2,6 +2,7 @@ sun4i-drm-y += sun4i_drv.o
> sun4i-drm-y += sun4i_framebuffer.o
>
> sun4i-drm-hdmi-y += sun4i_hdmi_enc.o
> +sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
> sun4i-drm-hdmi-y += sun4i_hdmi_ddc_clk.o
> sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
You probably also need to depend on the I2C framework in order to
work, right?
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> index 2f2f2ff1ea63..4c01dbe89cd9 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
> @@ -97,6 +97,7 @@
> #define SUN4I_HDMI_DDC_CTRL_START_CMDBIT(30)
> #define SUN4I_HDMI_DDC_CTRL_FIFO_DIR_MASKBIT(8)
> #define SUN4I_HDMI_DDC_CTRL_FIFO_DIR_READ(0 << 8)
> +#define SUN4I_HDMI_DDC_CTRL_FIFO_DIR_WRITE (1 << 8)
All the other bit defines are ordered by descending orders, please
keep it consistent.
> #define SUN4I_HDMI_DDC_CTRL_RESETBIT(0)
>
> #define SUN4I_HDMI_DDC_ADDR_REG 0x504
> @@ -105,6 +106,10 @@
> #define SUN4I_HDMI_DDC_ADDR_OFFSET(off) (((off) & 0xff) << 8)
> #define SUN4I_HDMI_DDC_ADDR_SLAVE(addr) ((addr) & 0xff)
>
> +#define SUN4I_HDMI_DDC_INTERRUPT_STATUS_REG 0x50c
It is called INT_STATUS in the datasheet
> +#define SUN4I_HDMI_DDC_INTERRUPT_STATUS_FIFO_REQUEST BIT(4)
> +#define SUN4I_HDMI_DDC_INTERRUPT_STATUS_TRANSFER_COMPLETEBIT(0)
> +
> #define SUN4I_HDMI_DDC_FIFO_CTRL_REG 0x510
> #define SUN4I_HDMI_DDC_FIFO_CTRL_CLEAR BIT(31)
>
> @@ -112,7 +117,8 @@
> #define SUN4I_HDMI_DDC_BYTE_COUNT_REG0x51c
>
> #define SUN4I_HDMI_DDC_CMD_REG 0x520
> -#define SUN4I_HDMI_DDC_CMD_EXPLICIT_EDDC_READ6
> +#define SUN4I_HDMI_DDC_CMD_IMPLICIT_WRITE3
> +#define SUN4I_HDMI_DDC_CMD_IMPLICIT_READ 5
Same remark here, and why do you remove the old one?
>
> #define SUN4I_HDMI_DDC_CLK_REG 0x528
> #define SUN4I_HDMI_DDC_CLK_M(m) (((m) & 0x7) << 3)
> @@ -146,6 +152,8 @@ struct sun4i_hdmi {
> struct clk *ddc_clk;
> struct clk *tmds_clk;
>
> + struct i2c_adapter *i2c;
> +
> struct sun4i_drv*drv;
>
> boolhdmi_monitor;
> @@ -153,5 +161,6 @@ struct sun4i_hdmi {
>
> int sun4i_ddc_create(struct sun4i_hdmi *hdmi, struct clk *clk);
> int sun4i_tmds_create(struct sun4i_hdmi *hdmi);
> +int sun4i_hdmi_i2c_create(struct sun4i_hdmi *hdmi);
>
> #endif /* _SUN4I_HDMI_H_ */
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> index d3398f6250ef..2a8c0b14eabc 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> @@ -29,8 +29,6 @@
> #include "sun4i_hdmi.h"
> #include "sun4i_tcon.h"
>
> -#define DDC_SEGMENT_ADDR 0x30
> -
> static inline struct sun4i_hdmi *
> drm_encoder_to_sun4i_hdmi(struct drm_encoder *encoder)
> {
> @@ -184,93 +182,13 @@ static const struct drm_encoder_funcs sun4i_hdmi_funcs
> = {
> .destroy= drm_encoder_cleanup,
> };
>
> -static int sun4i_hdmi_read_sub_block(struct sun4i_hdmi *hdmi,
> - unsigned int blk, unsigned int offset,
> - u8 *buf, unsigned int count)
> -{
> - unsigned long reg;
> - int i;
> -
> - reg = readl(hdmi->base + SUN4I_HDMI_DDC_CTRL_REG);
> - reg &= ~SUN4I_HDMI_DDC_CTRL_FIFO_DIR_MASK;
> - writel(reg | SUN4I_HDMI_DDC_CTRL_FIFO_DIR_READ,
> -hdmi->base + SUN4I_HDMI_DDC_CTRL_REG);
> -
> - writel(SUN4I_HDMI_DDC_ADDR_SEGMENT(offset >> 8) |
> -SUN4I_HDMI_DDC_ADDR_EDDC(DDC_SEGMENT_ADDR << 1) |
> -SUN4I_HDMI_DDC_ADDR_OFFSET(of
[Bug 101387] amdgpu display corruption and hang on AMD A10-9620P
https://bugs.freedesktop.org/show_bug.cgi?id=101387 --- Comment #6 from Carlo Caione --- Uhm, probably I have found something. In amdgpu_atombios_crtc_powergate_init() we are declaring ENABLE_DISP_POWER_GATING_PARAMETERS_V2_1 args; so that args is basically a 32byte struct. We are passing down this struct to amdgpu_atom_execute_table() casting it to (uint32_t *). This address is then assigned to (uint32_t *) ectx.ps in amdgpu_atom_execute_table_locked(). At a certain point during the execution of the code in the table with index = 75, atom_put_dst() is called with argument ATOM_ARG_PS and index == 1. So we are doing: ctx->ps[idx] = cpu_to_le32(val); but being idx == 1, we are accessing over the boundaries of args, so triggering the stack corruption. Is this analysis correct and if it is how can we fix this? -- 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 100070] Rocket League: grass gets rendered incorrectly
https://bugs.freedesktop.org/show_bug.cgi?id=100070 --- Comment #3 from Gregor Münch --- Thanks for your response, I will try to provide the trace by the end of the week. Im just curious, since Plagman can give you the steam key and the problem also exists on RX470 / RX480 according to the links provided above, which means it looks more like an general problem, wouldnt it speed up the process if yourself would just look into the problem? However Im happy to deliver that trace for you. -- 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 01/44] firmware/ivc: use dma_mapping_error
On Thu, Jun 08, 2017 at 03:25:26PM +0200, Christoph Hellwig wrote: > DMA_ERROR_CODE is not supposed to be used by drivers. > > Signed-off-by: Christoph Hellwig > --- > drivers/firmware/tegra/ivc.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Acked-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging
On Tue, Jun 13, 2017 at 01:50:16PM +0200, Michael Thayer wrote: > 12.06.2017 18:03, Greg Kroah-Hartman wrote: > > On Mon, Jun 12, 2017 at 05:40:21PM +0200, Hans de Goede wrote: > >> Hi, > >> > >> On 12-06-17 13:44, Greg Kroah-Hartman wrote: > >>> On Mon, Jun 12, 2017 at 12:07:41PM +0200, Hans de Goede wrote: > > The most important thing is for the driver to be atomic if it's KMS > > only, and it would be good to have someone review that properly. > > I believe it does not use the atomic APIs atm, so that would be one > of the first things to fix then. Another question is if people > (you and Daniel at least) can live with the non kernel-coding > style shared files under the osindependent dir ? > >>> > >>> Why not just spend a few days and fix up all of the kernel-style issues > >>> so it can be a "real" driver? It shouldn't take all that long, > >>> especially for someone with Linux kernel experience (hint, hint...) > >> > >> The intention of the stuff below the osindepedent dir is for it to > >> be shared 1:1 between vboxvideo driver implementations for different > >> operating-systems. IIRC during the AMD DAL discussion Daniel indicated > >> that some OS independent code was fine (and would be exempt from coding > >> style rules) as long as it had a reasonable clean interface and was not > >> re-implementing anything we already have in the kernel. > > > > In a quick glance at the code in there, there's lots of reimplementing > > happening :( > > > > Maybe keep the data structures around, but really, you write those once, > > and then that's it, they should never change, so it shouldn't matter > > what format they are in. > > > >> If Daniel's verdict is that this needs to be cleaned up, then sure I > >> can easily do that. As mentioned I already did a lot of cleanup, > >> including moving all the other files to the kernel coding-style and > >> removing about 43000 lines of portability cruft / abstraction layers, > >> what is left under the osindependent directory is just C-structure > >> definitions and a few small plain C helper functions, which VirtualBox > >> upstream would like to keep as is... > > > > wrappers for simple things should not be needed at all, come on, you > > know that. We don't like driver-specific malloc/free and in/out > > functions, or asserts, or other crap like that. This implies that this > > driver is an island in itself and somehow more "important" than the 12+ > > million other lines of code that it lives within. Which isn't true. > > > > Just clean it up, that will make it even smaller, which in the end, is > > what really matters, as that will make it easier to maintain, fix, port > > to new apis, and everything else. > > > > There's a good reason why we don't have "os abstraction" layers in > > drivers in Linux, please don't ignore our history and knowledge here for > > no good reason. > > I would appreciate getting Dave and/or Daniel's feedback here, if they > have time. In particular, they might have ideas about how to further > reduce the abstraction surface. In the end, the greater the difference > between the code in the kernel, the harder it is for people to pull > changes from our code to the kernel, and most of the changes in that > part are likely to come from our side. I don't think that converting > non-Linux-specific code in our tree to kernel style would go down well > in our team, so if the code as is is not acceptable, the next question > is, what would be? If we can come up with something which is alright > for both modulo a sed script that would still make people's lives > somewhat easier (though just the different brace style throws a bit of a > spanner in that). Once your code is accepted into the main kernel tree, why would you continue to work in an out-of-tree repo anyway? That's ripe for disaster, what's keeping you from just working with the in-tree version? Note, this isn't anything new. Hundreds of companies and thousands of developers do this every year with Linux, they don't have out-of-tree repos with different coding style rules, as consistent rules are there for good reason (hint, our brains, you want us to fix your bugs, and we want you to fix ours.) > > Remember, this code needs us, we don't need this code at all :) > > I assume that that was not meant that way, but that came over as > slightly unfriendly to me. It was meant that way as you are trying to do something that no other developer group gets away with in the kernel tree, why is this tiny 8k line driver so special? I agree it is special to you, that that's great, but please be aware of the larger picture here. You will benefit greatly from being in the kernel source tree (lines removed, bugs fixed, api changes happen automatically, etc.) All we ask is that you work on the same level play ground as everyone else is. To ask to use a special coding style and have an os-independant wrapper is not "level" at all, it insulates you
[Bug 101387] amdgpu display corruption and hang on AMD A10-9620P
https://bugs.freedesktop.org/show_bug.cgi?id=101387 --- Comment #7 from Carlo Caione --- Just to be clear. I have already verified that the address of &args and ctx->ps are the same, so this is definitely something we want to fix somehow. -- 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] drm/msm: fix locking inconsistency for gpu->hw_init()
Most, but not all, paths where calling the with struct_mutex held. The
fast-path in msm_gem_get_iova() (plus some sub-code-paths that only run
the first time) was masking this issue.
So lets just always hold struct_mutex for hw_init(). And sprinkle some
WARN_ON()'s and might_lock() to avoid this sort of problem in the
future.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 13 +
drivers/gpu/drm/msm/adreno/a5xx_power.c| 11 ---
drivers/gpu/drm/msm/adreno/adreno_device.c | 2 ++
drivers/gpu/drm/msm/adreno/adreno_gpu.c| 2 +-
drivers/gpu/drm/msm/msm_gem.c | 3 +++
drivers/gpu/drm/msm/msm_gpu.c | 2 ++
6 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index fc9a81a..d5d6198 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -386,31 +386,28 @@ static struct drm_gem_object *a5xx_ucode_load_bo(struct
msm_gpu *gpu,
struct drm_gem_object *bo;
void *ptr;
- mutex_lock(&drm->struct_mutex);
bo = msm_gem_new(drm, fw->size - 4, MSM_BO_UNCACHED);
- mutex_unlock(&drm->struct_mutex);
-
if (IS_ERR(bo))
return bo;
- ptr = msm_gem_get_vaddr(bo);
+ ptr = msm_gem_get_vaddr_locked(bo);
if (!ptr) {
- drm_gem_object_unreference_unlocked(bo);
+ drm_gem_object_unreference(bo);
return ERR_PTR(-ENOMEM);
}
if (iova) {
- int ret = msm_gem_get_iova(bo, gpu->id, iova);
+ int ret = msm_gem_get_iova_locked(bo, gpu->id, iova);
if (ret) {
- drm_gem_object_unreference_unlocked(bo);
+ drm_gem_object_unreference(bo);
return ERR_PTR(ret);
}
}
memcpy(ptr, &fw->data[4], fw->size - 4);
- msm_gem_put_vaddr(bo);
+ msm_gem_put_vaddr_locked(bo);
return bo;
}
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_power.c
b/drivers/gpu/drm/msm/adreno/a5xx_power.c
index 72d52c7..7838f5f 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_power.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_power.c
@@ -294,17 +294,14 @@ void a5xx_gpmu_ucode_init(struct msm_gpu *gpu)
*/
bosize = (cmds_size + (cmds_size / TYPE4_MAX_PAYLOAD) + 1) << 2;
- mutex_lock(&drm->struct_mutex);
a5xx_gpu->gpmu_bo = msm_gem_new(drm, bosize, MSM_BO_UNCACHED);
- mutex_unlock(&drm->struct_mutex);
-
if (IS_ERR(a5xx_gpu->gpmu_bo))
goto err;
- if (msm_gem_get_iova(a5xx_gpu->gpmu_bo, gpu->id, &a5xx_gpu->gpmu_iova))
+ if (msm_gem_get_iova_locked(a5xx_gpu->gpmu_bo, gpu->id,
&a5xx_gpu->gpmu_iova))
goto err;
- ptr = msm_gem_get_vaddr(a5xx_gpu->gpmu_bo);
+ ptr = msm_gem_get_vaddr_locked(a5xx_gpu->gpmu_bo);
if (!ptr)
goto err;
@@ -323,7 +320,7 @@ void a5xx_gpmu_ucode_init(struct msm_gpu *gpu)
cmds_size -= _size;
}
- msm_gem_put_vaddr(a5xx_gpu->gpmu_bo);
+ msm_gem_put_vaddr_locked(a5xx_gpu->gpmu_bo);
a5xx_gpu->gpmu_dwords = dwords;
goto out;
@@ -332,7 +329,7 @@ void a5xx_gpmu_ucode_init(struct msm_gpu *gpu)
if (a5xx_gpu->gpmu_iova)
msm_gem_put_iova(a5xx_gpu->gpmu_bo, gpu->id);
if (a5xx_gpu->gpmu_bo)
- drm_gem_object_unreference_unlocked(a5xx_gpu->gpmu_bo);
+ drm_gem_object_unreference(a5xx_gpu->gpmu_bo);
a5xx_gpu->gpmu_bo = NULL;
a5xx_gpu->gpmu_iova = 0;
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 7345a01..56fb59f 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -158,7 +158,9 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
int ret;
pm_runtime_get_sync(&pdev->dev);
+ mutex_lock(&dev->struct_mutex);
ret = msm_gpu_hw_init(gpu);
+ mutex_unlock(&dev->struct_mutex);
pm_runtime_put_sync(&pdev->dev);
if (ret) {
dev_err(dev->dev, "gpu hw init failed: %d\n", ret);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 5b63fc6..9e08b3e 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -64,7 +64,7 @@ int adreno_hw_init(struct msm_gpu *gpu)
DBG("%s", gpu->name);
- ret = msm_gem_get_iova(gpu->rb->bo, gpu->id, &gpu->rb_iova);
+ ret = msm_gem_get_iova_locked(gpu->rb->bo, gpu->id, &gpu->rb_iova);
if (ret) {
gpu->rb_iova = 0;
dev_err(gpu->dev->dev, "could not map ringbuffer: %d\n", ret);
diff --git a/drivers/gpu/drm/
[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=99851 --- Comment #49 from intermedi...@hotmail.com --- Hi Michel, can be, i have many kernel traces on Qoriq machine from latest kernels but for what i see look like a qman issue . i dont know if qman have something related to pci/pcie -- 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 07/22] drm/tegra: Remove module ownership from the tegra_fb_ops
On Tue, May 23, 2017 at 03:14:22AM +0300, Dmitry Osipenko wrote: > The framebuffers console fbcon_startup() increments the tegra_drm module > 'use' refcount via try_module_get(), causing an interlock of the DRM subsys > and the tegra_drm modules. In result, the tegra_drm module can't be unloaded > using rmmod. > > Signed-off-by: Dmitry Osipenko > --- > drivers/gpu/drm/tegra/fb.c | 1 - > 1 file changed, 1 deletion(-) That's done on purpose because otherwise you could just rip out the driver from under the framebuffer emulation and things would crash. My understanding is that the right way to unload a module is to unbind the driver first (which will cause the framebuffer to be removed and hence the reference to be dropped) before the rmmod. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/22] drm/tegra: dc: Drop the reset asserts to workaround a bug
On Tue, May 23, 2017 at 03:14:23AM +0300, Dmitry Osipenko wrote:
> Commit 33a8eb8 ("Implement runtime PM") introduced HW reset control. It
> causes a hang on Tegra20 if both display controllers are utilized (RGB
> panel and HDMI). The TRM suggests that each display controller has its own
> reset control, apparently it is not correct. Let's remove the interaction
> with the resets for now as a workaround.
>
> Fixes: 33a8eb8d40ee ("drm/tegra: dc: Implement runtime PM")
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/dc.c | 15 ---
> 1 file changed, 15 deletions(-)
Do you mind if I parameterize this to restrict omission of the assert
and deassert to Tegra20? I'm fairly sure that these resets are important
on later chips in order to properly reset the display controllers.
My proposal would be to add a field to struct tegra_dc_soc_info (maybe
.broken_reset) that will be set only on Tegra20 to still allow the DC to
be reset on later generations.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH][drm-next] drm/i915/cnl: make function cnl_ddi_dp_set_dpll_hw_state static
From: Colin Ian King
The function cnl_ddi_dp_set_dpll_hw_state does not need to be in global
scope, so make it static.
Cleans up sparse warning:
"symbol 'cnl_ddi_dp_set_dpll_hw_state' was not declared. Should it
be static?"
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel_dpll_mgr.c
index 8e669b6254ae..2f7b0e64f628 100644
--- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
+++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
@@ -2292,8 +2292,9 @@ static bool cnl_ddi_hdmi_pll_dividers(struct intel_crtc
*crtc,
return true;
}
-bool cnl_ddi_dp_set_dpll_hw_state(int clock,
- struct intel_dpll_hw_state *dpll_hw_state)
+static bool
+cnl_ddi_dp_set_dpll_hw_state(int clock,
+struct intel_dpll_hw_state *dpll_hw_state)
{
uint32_t cfgcr0;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging
On Tue, Jun 13, 2017 at 03:45:14PM +0200, Michael Thayer wrote: > 13.06.2017 14:48, Greg Kroah-Hartman wrote: > [Discussion of vboxvideo coding style.] > > Once your code is accepted into the main kernel tree, why would you > > continue to work in an out-of-tree repo anyway? That's ripe for > > disaster, what's keeping you from just working with the in-tree version? > > One of our use cases is customers running older operating systems, > including legacy Linux distributions. However those customers would > still like the most up-to-date guest drivers possible without updating > the kernel. Updating drivers without updating the kernel is not a > scenario of interest to upstream kernel developers, which is why we will > continue to maintain the out-of-tree repository (which is actually the > VirtualBox repository, where the OS-independent code is shared with > drivers for other platforms). The end result is not unlike what Red Hat > does when it does back-ports to its stable kernels. When Red Hat backports upstream drivers to older kernels, they do not do so in a way that is a different coding style or anything like that. They take the existing code, apply some rules and modifications to it, and complete the backport. Some drivers can be done "automagically" using some good transformation tools that people have developed. In fact, its even easier to do this if the code is upstream. Just keep a local copy of the latest upstream version, with a "linux_backport.h" type file to handle the api changes. Lots of people do that, and I myself did it for many years while working on different driver subsystems that had to ship in older kernels. Here's one example of this type of a file that I helped work on: https://github.com/gregkh/greybus/blob/master/kernel_ver.h that covered 5-6 different driver subsystems having to track all kernel versions from 3.10 to the latest 4.9 release (at that point in time, the code got merged upstream.) Feel free to copy the same idea for your code, if it's applicable, other drivers do this for their "customers" as well. Note, none of this requires "os abstractions" on the upstream code at all, nor does it require a different coding style at all, that would just hinder development and cause massive problems when trying to determine what changed upstream. This isn't the first time we've done this, some of us have a bit of experience in operating system development :) thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/22] gpu: host1x: Forbid unrelated SETCLASS opcode in the firewall
On Tue, May 23, 2017 at 02:39:33AM +0200, Erik Faye-Lund wrote:
> On Tue, May 23, 2017 at 2:14 AM, Dmitry Osipenko wrote:
> > Several channels could be made to write the same unit concurrently via the
> > SETCLASS opcode, trusting userspace is a bad idea. It should be possible to
> > drop the per-client channel reservation and add a per-unit locking by
> > inserting MLOCK's to the command stream to re-allow the SETCLASS opcode, but
> > it will be much more work. Let's forbid the unit-unrelated class changes for
> > now.
> >
> > Signed-off-by: Dmitry Osipenko
> > ---
> > drivers/gpu/drm/tegra/drm.c | 1 +
> > drivers/gpu/drm/tegra/drm.h | 1 +
> > drivers/gpu/drm/tegra/gr2d.c | 12
> > drivers/gpu/host1x/job.c | 24
> > include/linux/host1x.h | 5 -
> > 5 files changed, 38 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> > index cdb05d6efde4..17416e1c219a 100644
> > --- a/drivers/gpu/drm/tegra/drm.c
> > +++ b/drivers/gpu/drm/tegra/drm.c
> > @@ -531,6 +531,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
> > }
> >
> > job->is_addr_reg = context->client->ops->is_addr_reg;
> > + job->is_valid_class = context->client->ops->is_valid_class;
> > job->syncpt_incrs = syncpt.incrs;
> > job->syncpt_id = syncpt.id;
> > job->timeout = 1;
> > diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> > index 85aa2e3d9d4e..6d6da01282f3 100644
> > --- a/drivers/gpu/drm/tegra/drm.h
> > +++ b/drivers/gpu/drm/tegra/drm.h
> > @@ -83,6 +83,7 @@ struct tegra_drm_client_ops {
> > struct tegra_drm_context *context);
> > void (*close_channel)(struct tegra_drm_context *context);
> > int (*is_addr_reg)(struct device *dev, u32 class, u32 offset);
> > + int (*is_valid_class)(u32 class);
> > int (*submit)(struct tegra_drm_context *context,
> > struct drm_tegra_submit *args, struct drm_device *drm,
> > struct drm_file *file);
> > diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
> > index 02cd3e37a6ec..782231c41a1a 100644
> > --- a/drivers/gpu/drm/tegra/gr2d.c
> > +++ b/drivers/gpu/drm/tegra/gr2d.c
> > @@ -109,10 +109,22 @@ static int gr2d_is_addr_reg(struct device *dev, u32
> > class, u32 offset)
> > return 0;
> > }
> >
> > +static int gr2d_is_valid_class(u32 class)
> > +{
> > + switch (class) {
> > + case HOST1X_CLASS_GR2D:
> > + case HOST1X_CLASS_GR2D_SB:
> > + return 1;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static const struct tegra_drm_client_ops gr2d_ops = {
> > .open_channel = gr2d_open_channel,
> > .close_channel = gr2d_close_channel,
> > .is_addr_reg = gr2d_is_addr_reg,
> > + .is_valid_class = gr2d_is_valid_class,
> > .submit = tegra_drm_submit,
> > };
> >
> > diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
> > index cf335c5979e2..65e12219405a 100644
> > --- a/drivers/gpu/host1x/job.c
> > +++ b/drivers/gpu/host1x/job.c
> > @@ -358,6 +358,9 @@ struct host1x_firewall {
> >
> > static int check_register(struct host1x_firewall *fw, unsigned long offset)
> > {
> > + if (!fw->job->is_addr_reg)
> > + return 0;
> > +
> > if (fw->job->is_addr_reg(fw->dev, fw->class, offset)) {
> > if (!fw->num_relocs)
> > return -EINVAL;
> > @@ -372,6 +375,19 @@ static int check_register(struct host1x_firewall *fw,
> > unsigned long offset)
> > return 0;
> > }
> >
> > +static int check_class(struct host1x_firewall *fw, u32 class)
> > +{
> > + if (!fw->job->is_valid_class) {
> > + if (fw->class != class)
> > + return -EINVAL;
> > + } else {
> > + if (!fw->job->is_valid_class(fw->class))
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static int check_mask(struct host1x_firewall *fw)
> > {
> > u32 mask = fw->mask;
> > @@ -445,11 +461,9 @@ static int validate(struct host1x_firewall *fw, struct
> > host1x_job_gather *g)
> > {
> > u32 *cmdbuf_base = (u32 *)fw->job->gather_copy_mapped +
> > (g->offset / sizeof(u32));
> > + u32 job_class = fw->class;
> > int err = 0;
> >
> > - if (!fw->job->is_addr_reg)
> > - return 0;
> > -
> > fw->words = g->words;
> > fw->cmdbuf = g->bo;
> > fw->offset = 0;
> > @@ -469,7 +483,9 @@ static int validate(struct host1x_firewall *fw, struct
> > host1x_job_gather *g)
> > fw->class = word >> 6 & 0x3ff;
> > fw->mask = word & 0x3f;
> > fw->reg = word >> 16 & 0xfff;
> > - err = check_mask(fw);
> > + e
Re: [PATCH libdrm v8] amdgpu: move asic id table to a separate file
On Tue, Jun 13, 2017 at 5:45 AM, Michel Dänzer wrote:
> From: Xiaojie Yuan
>
> v2: fix an off by one error and leading white spaces
> v3: use thread safe strtok_r(); initialize len before calling getline();
> change printf() to drmMsg(); add initial amdgpu.ids
> v4: integrate some recent internal changes, including format changes
> v5: fix line number for empty/commented lines; realloc to save memory;
> indentation changes
> v6: remove a line error
> v7: [Michel Dänzer]
> * Move amdgpu.ids to new data directory
> * Remove placeholder entries from amdgpu.ids
> * Set libdrmdatadir variable in configure.ac instead of Makefile.am
> [Emil Velikov]
> * Use isblank() instead of open-coding it [Emil Velikov]
> * Don't leak asic_id_table memory if realloc fails [Emil Velikov]
> * Check and bump table_max_size at the beginning of the while loop [Emil
> Velikov]
> * Initialize table_max_size to the number of entries in data/amdgpu.ids
> v8: [Michel Dänzer]
> * Make sure amdgpu_asic_id.c gets rebuilt when amdgpu.ids changes
>
> Reviewed-by: Alex Deucher # v7
Reviewed-by: Alex Deucher
Alex
> Signed-off-by: Samuel Li
> Signed-off-by: Michel Dänzer
> ---
> Makefile.am | 1 +
> amdgpu/Makefile.am | 7 ++
> amdgpu/Makefile.sources | 2 +-
> amdgpu/amdgpu_asic_id.c | 219
> +++
> amdgpu/amdgpu_asic_id.h | 165 ---
> amdgpu/amdgpu_device.c | 28 --
> amdgpu/amdgpu_internal.h | 10 +++
> configure.ac | 4 +
> data/Makefile.am | 23 +
> data/amdgpu.ids | 159 ++
> 10 files changed, 445 insertions(+), 173 deletions(-)
> create mode 100644 amdgpu/amdgpu_asic_id.c
> delete mode 100644 amdgpu/amdgpu_asic_id.h
> create mode 100644 data/Makefile.am
> create mode 100644 data/amdgpu.ids
>
> diff --git a/Makefile.am b/Makefile.am
> index dfb8fcdb..7b86214e 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -109,6 +109,7 @@ SUBDIRS = \
> $(TEGRA_SUBDIR) \
> $(VC4_SUBDIR) \
> $(ETNAVIV_SUBDIR) \
> + data \
> tests \
> $(MAN_SUBDIR)
>
> diff --git a/amdgpu/Makefile.am b/amdgpu/Makefile.am
> index cf7bc1ba..66f6f676 100644
> --- a/amdgpu/Makefile.am
> +++ b/amdgpu/Makefile.am
> @@ -30,12 +30,19 @@ AM_CFLAGS = \
> $(PTHREADSTUBS_CFLAGS) \
> -I$(top_srcdir)/include/drm
>
> +libdrmdatadir = @libdrmdatadir@
> +ASIC_ID_TABLE_NUM_ENTRIES := $(shell egrep -ci '^[0-9a-f]{4},.*[0-9a-f]+,' \
> + $(top_srcdir)/data/amdgpu.ids)
> +AM_CPPFLAGS = -DAMDGPU_ASIC_ID_TABLE=\"${libdrmdatadir}/amdgpu.ids\" \
> + -DAMDGPU_ASIC_ID_TABLE_NUM_ENTRIES=$(ASIC_ID_TABLE_NUM_ENTRIES)
> +
> libdrm_amdgpu_la_LTLIBRARIES = libdrm_amdgpu.la
> libdrm_amdgpu_ladir = $(libdir)
> libdrm_amdgpu_la_LDFLAGS = -version-number 1:0:0 -no-undefined
> libdrm_amdgpu_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
>
> libdrm_amdgpu_la_SOURCES = $(LIBDRM_AMDGPU_FILES)
> +amdgpu_asic_id.lo: $(top_srcdir)/data/amdgpu.ids
>
> libdrm_amdgpuincludedir = ${includedir}/libdrm
> libdrm_amdgpuinclude_HEADERS = $(LIBDRM_AMDGPU_H_FILES)
> diff --git a/amdgpu/Makefile.sources b/amdgpu/Makefile.sources
> index 487b9e0a..bc3abaa6 100644
> --- a/amdgpu/Makefile.sources
> +++ b/amdgpu/Makefile.sources
> @@ -1,5 +1,5 @@
> LIBDRM_AMDGPU_FILES := \
> - amdgpu_asic_id.h \
> + amdgpu_asic_id.c \
> amdgpu_bo.c \
> amdgpu_cs.c \
> amdgpu_device.c \
> diff --git a/amdgpu/amdgpu_asic_id.c b/amdgpu/amdgpu_asic_id.c
> new file mode 100644
> index ..3a88896b
> --- /dev/null
> +++ b/amdgpu/amdgpu_asic_id.c
> @@ -0,0 +1,219 @@
> +/*
> + * Copyright © 2017 Advanced Micro Devices, Inc.
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + *
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#e
Re: [PATCH] drm/msm: fix locking inconsistency for gpu->hw_init()
On Tue, Jun 13, 2017 at 09:23:45AM -0400, Rob Clark wrote:
> Most, but not all, paths where calling the with struct_mutex held. The
> fast-path in msm_gem_get_iova() (plus some sub-code-paths that only run
> the first time) was masking this issue.
>
> So lets just always hold struct_mutex for hw_init(). And sprinkle some
> WARN_ON()'s and might_lock() to avoid this sort of problem in the
> future.
>
> Signed-off-by: Rob Clark
Acked-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 13 +
> drivers/gpu/drm/msm/adreno/a5xx_power.c| 11 ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 2 ++
> drivers/gpu/drm/msm/adreno/adreno_gpu.c| 2 +-
> drivers/gpu/drm/msm/msm_gem.c | 3 +++
> drivers/gpu/drm/msm/msm_gpu.c | 2 ++
> 6 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index fc9a81a..d5d6198 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -386,31 +386,28 @@ static struct drm_gem_object *a5xx_ucode_load_bo(struct
> msm_gpu *gpu,
> struct drm_gem_object *bo;
> void *ptr;
>
> - mutex_lock(&drm->struct_mutex);
> bo = msm_gem_new(drm, fw->size - 4, MSM_BO_UNCACHED);
> - mutex_unlock(&drm->struct_mutex);
> -
> if (IS_ERR(bo))
> return bo;
>
> - ptr = msm_gem_get_vaddr(bo);
> + ptr = msm_gem_get_vaddr_locked(bo);
> if (!ptr) {
> - drm_gem_object_unreference_unlocked(bo);
> + drm_gem_object_unreference(bo);
> return ERR_PTR(-ENOMEM);
> }
>
> if (iova) {
> - int ret = msm_gem_get_iova(bo, gpu->id, iova);
> + int ret = msm_gem_get_iova_locked(bo, gpu->id, iova);
>
> if (ret) {
> - drm_gem_object_unreference_unlocked(bo);
> + drm_gem_object_unreference(bo);
> return ERR_PTR(ret);
> }
> }
>
> memcpy(ptr, &fw->data[4], fw->size - 4);
>
> - msm_gem_put_vaddr(bo);
> + msm_gem_put_vaddr_locked(bo);
> return bo;
> }
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_power.c
> b/drivers/gpu/drm/msm/adreno/a5xx_power.c
> index 72d52c7..7838f5f 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_power.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_power.c
> @@ -294,17 +294,14 @@ void a5xx_gpmu_ucode_init(struct msm_gpu *gpu)
>*/
> bosize = (cmds_size + (cmds_size / TYPE4_MAX_PAYLOAD) + 1) << 2;
>
> - mutex_lock(&drm->struct_mutex);
> a5xx_gpu->gpmu_bo = msm_gem_new(drm, bosize, MSM_BO_UNCACHED);
> - mutex_unlock(&drm->struct_mutex);
> -
> if (IS_ERR(a5xx_gpu->gpmu_bo))
> goto err;
>
> - if (msm_gem_get_iova(a5xx_gpu->gpmu_bo, gpu->id, &a5xx_gpu->gpmu_iova))
> + if (msm_gem_get_iova_locked(a5xx_gpu->gpmu_bo, gpu->id,
> &a5xx_gpu->gpmu_iova))
> goto err;
>
> - ptr = msm_gem_get_vaddr(a5xx_gpu->gpmu_bo);
> + ptr = msm_gem_get_vaddr_locked(a5xx_gpu->gpmu_bo);
> if (!ptr)
> goto err;
>
> @@ -323,7 +320,7 @@ void a5xx_gpmu_ucode_init(struct msm_gpu *gpu)
> cmds_size -= _size;
> }
>
> - msm_gem_put_vaddr(a5xx_gpu->gpmu_bo);
> + msm_gem_put_vaddr_locked(a5xx_gpu->gpmu_bo);
> a5xx_gpu->gpmu_dwords = dwords;
>
> goto out;
> @@ -332,7 +329,7 @@ void a5xx_gpmu_ucode_init(struct msm_gpu *gpu)
> if (a5xx_gpu->gpmu_iova)
> msm_gem_put_iova(a5xx_gpu->gpmu_bo, gpu->id);
> if (a5xx_gpu->gpmu_bo)
> - drm_gem_object_unreference_unlocked(a5xx_gpu->gpmu_bo);
> + drm_gem_object_unreference(a5xx_gpu->gpmu_bo);
>
> a5xx_gpu->gpmu_bo = NULL;
> a5xx_gpu->gpmu_iova = 0;
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 7345a01..56fb59f 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -158,7 +158,9 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
> int ret;
>
> pm_runtime_get_sync(&pdev->dev);
> + mutex_lock(&dev->struct_mutex);
> ret = msm_gpu_hw_init(gpu);
> + mutex_unlock(&dev->struct_mutex);
> pm_runtime_put_sync(&pdev->dev);
> if (ret) {
> dev_err(dev->dev, "gpu hw init failed: %d\n", ret);
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 5b63fc6..9e08b3e 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -64,7 +64,7 @@ int adreno_hw_init(struct msm_gpu *gpu)
>
> DBG("%s", gpu->name);
>
> - ret = msm_gem_get_iova(gpu->rb->bo, gpu->id, &gpu->rb_iova);
> + ret = msm_g
Re: [PATCH 08/22] drm/tegra: dc: Drop the reset asserts to workaround a bug
On Tue, Jun 13, 2017 at 05:18:37PM +0300, Dmitry Osipenko wrote:
> On 13.06.2017 16:45, Thierry Reding wrote:
> > On Tue, May 23, 2017 at 03:14:23AM +0300, Dmitry Osipenko wrote:
> >> Commit 33a8eb8 ("Implement runtime PM") introduced HW reset control. It
> >> causes a hang on Tegra20 if both display controllers are utilized (RGB
> >> panel and HDMI). The TRM suggests that each display controller has its own
> >> reset control, apparently it is not correct. Let's remove the interaction
> >> with the resets for now as a workaround.
> >>
> >> Fixes: 33a8eb8d40ee ("drm/tegra: dc: Implement runtime PM")
> >> Signed-off-by: Dmitry Osipenko
> >> ---
> >> drivers/gpu/drm/tegra/dc.c | 15 ---
> >> 1 file changed, 15 deletions(-)
> >
> > Do you mind if I parameterize this to restrict omission of the assert
> > and deassert to Tegra20? I'm fairly sure that these resets are important
> > on later chips in order to properly reset the display controllers.
>
> I don't mind at all, I can parameterize it in the next rev myself if you wish.
Sure, why not.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/22] drm/tegra: Remove module ownership from the tegra_fb_ops
On Tue, Jun 13, 2017 at 05:00:28PM +0300, Dmitry Osipenko wrote: > On 13.06.2017 16:43, Thierry Reding wrote: > > On Tue, May 23, 2017 at 03:14:22AM +0300, Dmitry Osipenko wrote: > >> The framebuffers console fbcon_startup() increments the tegra_drm module > >> 'use' refcount via try_module_get(), causing an interlock of the DRM subsys > >> and the tegra_drm modules. In result, the tegra_drm module can't be > >> unloaded > >> using rmmod. > >> > >> Signed-off-by: Dmitry Osipenko > >> --- > >> drivers/gpu/drm/tegra/fb.c | 1 - > >> 1 file changed, 1 deletion(-) > > > > That's done on purpose because otherwise you could just rip out the > > driver from under the framebuffer emulation and things would crash. > > > > My understanding is that the right way to unload a module is to unbind > > the driver first (which will cause the framebuffer to be removed and > > hence the reference to be dropped) before the rmmod. > > > > Thierry > > > > Aha, interesting. I'll try the unbinding and will drop this patch from the > series, thank you for the clarification. I haven't observed any crashes on a > module reloading (framebuffer detached/attached just fine), maybe I was lucky > then. It's possible that it works by accident. The driver removes the framebuffer as part of the driver removal process, so technically nothing should crash. However, if, for any reason, anyone was holding on to a reference to the framebuffer (not sure if that is even possible) the module needs to stay around long enough as well, otherwise the function pointers would become dangling. The module reference makes sure that this doesn't happen (as long as a framebuffer exists, the ops will stick around). So even if there isn't a way to make it crash today, the code is still correct in taking the reference. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: Add driver for Seiko 43WVF1G panel
Thierry/Rob, On Mon, May 8, 2017 at 10:54 AM, Fabio Estevam wrote: > On Tue, Apr 25, 2017 at 1:18 PM, Marco Franchi wrote: >> Add driver for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) >> TFT with Touch-Panel. >> >> Datasheet available at: >> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf >> >> Seiko 43WVF1G panel has two power supplies: AVDD and DVDD and they >> require a specific power on/down sequence. >> For this reason the simple panel driver cannot be used to drive this >> panel, so create a new one heavily based on simple panel. >> >> Based on initial patch submission from Breno Lima. >> >> Signed-off-by: Marco Franchi > > Works fine on a imx6sx-sdb board: > > Tested-by: Fabio Estevam Does this look good for you? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Color lookup support for the atmel-hlcdc driver
Hi Peter, On Tue, 13 Jun 2017 16:34:25 +0200 Peter Rosin wrote: > Hi! > > I need color lookup support for the atmel-hlcdc driver, and had a peek > at the code. I also looked at the drivers/gpu/drm/stm driver and came > up with the below diff. It compiles, but I have not booted it for the > simple reason that I can't imagine it will work. > > Sure, the code fills the clut registers in the .load_lut helper function > and I think it might even do the right thing when setting up the mode. > I'm less sure DMA will work correctly? It might, but I haven't looked at > it for many seconds... > > The big question is how the color info gets into the new clut array > I created in atmel_hlcdc_crtc? When I look at the stm driver, which does > it just like this AFAICT I just don't see it. So, what I'm I missing? You should look at drm_atomic_helper_legacy_gamma_set() and its users. Regards, Boris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging
On Tue, Jun 13, 2017 at 05:00:15PM +0200, Michael Thayer wrote: > 13.06.2017 15:59, Greg Kroah-Hartman wrote: > > On Tue, Jun 13, 2017 at 03:45:14PM +0200, Michael Thayer wrote: > >> 13.06.2017 14:48, Greg Kroah-Hartman wrote: > >> [Discussion of vboxvideo coding style.] > >>> Once your code is accepted into the main kernel tree, why would you > >>> continue to work in an out-of-tree repo anyway? That's ripe for > >>> disaster, what's keeping you from just working with the in-tree version? > >> > >> One of our use cases is customers running older operating systems, > >> including legacy Linux distributions. However those customers would > >> still like the most up-to-date guest drivers possible without updating > >> the kernel. Updating drivers without updating the kernel is not a > >> scenario of interest to upstream kernel developers, which is why we will > >> continue to maintain the out-of-tree repository (which is actually the > >> VirtualBox repository, where the OS-independent code is shared with > >> drivers for other platforms). The end result is not unlike what Red Hat > >> does when it does back-ports to its stable kernels. > > > > When Red Hat backports upstream drivers to older kernels, they do not do > > so in a way that is a different coding style or anything like that. > > They take the existing code, apply some rules and modifications to it, > > and complete the backport. Some drivers can be done "automagically" > > using some good transformation tools that people have developed. > > > > In fact, its even easier to do this if the code is upstream. Just keep > > a local copy of the latest upstream version, with a "linux_backport.h" > > type file to handle the api changes. Lots of people do that, and I > > myself did it for many years while working on different driver > > subsystems that had to ship in older kernels. > > > > Here's one example of this type of a file that I helped work on: > > https://github.com/gregkh/greybus/blob/master/kernel_ver.h > > that covered 5-6 different driver subsystems having to track all kernel > > versions from 3.10 to the latest 4.9 release (at that point in time, the > > code got merged upstream.) > > > > Feel free to copy the same idea for your code, if it's applicable, other > > drivers do this for their "customers" as well. > > > > Note, none of this requires "os abstractions" on the upstream code at > > all, nor does it require a different coding style at all, that would > > just hinder development and cause massive problems when trying to > > determine what changed upstream. > > The reason we have OS abstraction is that we share code between drivers > for different platforms. There is always going to be code in a driver - > mainly the actual programming of the hardware - which needs to work the > same way on different platforms, but which is not likely to be shared > with other drivers on the same platform. I personally think that this > is a sensible thing to do, and a discussion that is worth having, in > this case how to reap the benefits (for Linux too) of sharing among > platforms without imposing significant costs on the Linux kernel; but I > do agree that this driver is too small to be worth having a long > argument about. Yes, please look at the size, you have 7k lines total for the whole thing, how many could you possibly be sharing? 7k is really a trivial number of lines for a driver, well under half of the size of the 8250 UART driver[1], making your driver 1/2 as complex and difficult to maintain as a serial port driver :) It's really not that much code at all you are quibbling over here, it could have all been converted already to the correct format by either one of us with all of the time we have spent writing emails back and forth... And why is the closed vbox-devel list still on the cc: here, the bounces from it are getting annoying. thanks, greg k-h [1] My standard unit of measurement, I need a short name for it one of these days as I use it all the time. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/vc4: Add get/set tiling ioctls.
Daniel Stone writes: > Hi Eric, > > On 8 June 2017 at 01:13, Eric Anholt wrote: >> This allows mesa to set the tiling format for a BO and have that >> tiling format be respected by mesa on the other side of an >> import/export (and by vc4 scanout in the kernel), without defining a >> protocol to pass the tiling through userspace. > > I posted a DRI3 v1.1 patch series which can advertise and also transit > modifiers directly under X11, and have also typed up the support for > Wayland which is working just fine with Weston from git. If you > implement DRIimage v15 to advertise and import modifiers, then you can > transit them for free without a magic-back-channel ioctl. Would that > be enough to convince you to drop this series? Not really -- this patch is pretty small, and doesn't require updating the entire world. I've been delaying writing this patch since, what, XDC last year, waiting for the modifiers pipeline to materialize, and I'm not convinced that this One Last Patchset is going to land soon enough. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 196037] Installing Nvidia driver causes fan to run at full speed
https://bugzilla.kernel.org/show_bug.cgi?id=196037 --- Comment #3 from Mansoor Ahmed (m89...@outlook.com) --- Contacting Nvidia did little help. It just resolved my problem, but still the bug is there. www.devtalk.nvidia.com was the only solution I got. When Nivida was contacted officially they utterly refused to resolve the problem and referred me to devtalk, their forum. It's absolutely ridiculous. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101325] UE4Editor crash after pressing "play" with radeon southern island card (7850 HD)
https://bugs.freedesktop.org/show_bug.cgi?id=101325 --- Comment #10 from Julien Isorce --- Hi Luke, I can reproduce the ring stalled issue using your apitrace 100% of the time. In apitrace output I could notice: warning: extension `GL_EXT_gpu_shader4' unsupported in fragment shader message: api issue 4: FBO incomplete: no attachments and default width or height is 0 [-1] message: api performance issue 5: using glBufferSubData(buffer 1599, offset 0, size 288) to update a GL_STATIC_DRAW buffer message: shader compiler issue 2: LLVM diagnostic (remark): :0:0: 895 instructions in function message: shader compiler issue 3: too many identical messages; ignoring Using GALLIUM_DDEBUG and check_vm I could get some msg like: [1;32mPS - Constant buffer slot 4 (GPU list):ESC[0m ESC[1;33mSQ_BUF_RSRC_WORD0ESC[0m <- 0x000de0e0 ESC[1;33mSQ_BUF_RSRC_WORD1ESC[0m <- BASE_ADDRESS_HI = 0 STRIDE = 7200 (0x1c20) CACHE_SWIZZLE = 0 SWIZZLE_ENABLE = 0 ESC[1;33mSQ_BUF_RSRC_WORD2ESC[0m <- 0x4000c007 ESC[1;33mSQ_BUF_RSRC_WORD3ESC[0m <- DST_SEL_X = SQ_SEL_X DST_SEL_Y = SQ_SEL_0 DST_SEL_Z = SQ_SEL_0 DST_SEL_W = SQ_SEL_1 NUM_FORMAT = BUF_NUM_FORMAT_UNORM DATA_FORMAT = BUF_DATA_FORMAT_INVALID ELEMENT_SIZE = 2 INDEX_STRIDE = 2 ADD_TID_ENABLE = 1 ATC = 0 HASH_ENABLE = 0 HEAP = 0 MTYPE = 2 TYPE = SQ_RSRC_BUF_RSVD_2 USER_VM_ENABLE = 0 USER_VM_MODE = 1 NV = 0 ! This slot was corrupted in GPU memory ! I am using lastest git mesa, xserver, ddx, llvm and amd-staging-4.9 kernel. Similar result with amdgpu though it does not detect the gpu hang, all I can see is with radeontop, the graphic pipe is stuck at 100% for ever, but no error in dmesg. And indeed R600_DEBUG=nowc does not help in that case. I have the feeling that this is a llvm issue due to exotic shaders but only maintainers will be able to help you at this point. Providing this is 100% reproductible on SI chip class (at least) on both radeon and amdgpu drivers, it would be intersting to know if it happens on a more recent graphic card too. -- 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 196037] Installing Nvidia driver causes fan to run at full speed
https://bugzilla.kernel.org/show_bug.cgi?id=196037 --- Comment #4 from Len Brown (l...@kernel.org) --- > It's absolutely ridiculous. I think the word you are searching for us "unsupported". -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/7] drm/vc4: Add support for the TXP (transposer) block
Brian Starkey writes:
> Hi Boris,
>
> Sorry lost track of this thread.
>
>
> On Tue, Jun 06, 2017 at 09:13:00PM +0200, Boris Brezillon wrote:
>>Hi Brian,
>>
>>Le Mon, 5 Jun 2017 12:25:50 +0100,
>>Brian Starkey a écrit :
>>
>>> Hi Boris,
>>>
>>> I can't speak for the HW-specific details, but the writeback part
>>> looks pretty good (and familiar ;-) to me. There certainly seems to be
>>> some scope for code-sharing there, but I think it's fine not to do it
>>> yet.
>>
>>Agreed.
>>
>>>
>>> I've a further query below about the handling of CRTC events.
>>>
>>
>>[...]
>>
>>> >+
>>> >+void vc4_txp_atomic_commit(struct drm_device *dev,
>>> >+ struct drm_atomic_state *old_state)
>>> >+{
>>> >+ struct vc4_dev *vc4 = to_vc4_dev(dev);
>>> >+ struct vc4_txp *txp = vc4->txp;
>>> >+ struct drm_connector_state *conn_state = txp->connector.base.state;
>>> >+ struct drm_display_mode *mode;
>>> >+ struct drm_gem_cma_object *gem;
>>> >+ struct drm_framebuffer *fb;
>>> >+ u32 ctrl = TXP_GO | TXP_EI;
>>> >+
>>> >+ /* Writeback connector is disabled, nothing to do. */
>>> >+ if (!conn_state->crtc)
>>> >+ return;
>>> >+
>>> >+ /* Writeback connector is enabled, but has no FB assigned to it. Fake a
>>> >+ * vblank event to complete ->flip_done.
>>> >+ */
>>> >+ if (!conn_state->writeback_job || !conn_state->writeback_job->fb) {
>>> >+ vc4_crtc_eof_event(conn_state->crtc);
>>>
>>> I'm not sure about hiding away the one-shot thing like this. If the
>>> CRTC remains "active" from the API point of view, I'd expect it to be
>>> able to keep generating VBLANK events.
>>>
>>> I don't know how to do if, but if there were some notion of
>>> "auto-disabling" CRTCs then this quirk would go away, and you'd also
>>> be able to enforce that the CRTC can't be enabled without a writeback
>>> framebuffer.
>>
>>I don't have a strong opinion on "auto-disabling CRTC" vs "fake VBLANK
>>events". Note that I'm already faking a VBLANK event when activating
>>writeback, because there's no such concept at the HVS/TXP level. We
>>do have EOF (End Of Frame) and writeback done events, but these are
>>quite independent from the VBLANK events generated by the pixelvalve
>>block (the block responsible for generating the HSYNC/VSYNC signals).
>>
>>>
>>> I'm also not sure how (if?) this works today with a CRTC driving a DSI
>>> command-mode panel. Does the CRTC keep generating VBLANKs even when
>>> there are no updates?
>>
>>I don't know. Is this mandatory to have VBLANK events? I mean, the
>>core is using VBLANK events to detect when page flips have been done,
>>that is, when old framebuffers are unused and new ones started to be
>>fetched by the CRTC, but on some HW, VBLANK is not the only way to
>>detect such situations. The question is, are there other situations
>>where VBLANK events are required, or is there an implicit rule stating
>>that a CRTC has to generate VBLANK events at a vrefresh rate even when
>>the display is actually not updated when nothing changes?
>
> I'm not sure how widely relied upon it is, but I'd expect that there's
> a requirement to make sure DRM_IOCTL_WAIT_VBLANK works. I _think_ that
> means the CRTC should generate events at vrefresh rate if there's a
> wait request outstanding that depends on that.
In our case, there's no vrefresh rate, though. Just completion.
I've been trying to come up with a usecase for vblank events on
writeack, and the best I have is: to enable VNC-style capture of a
complete hardware rendering stack, we could run modesetting against the
writeback connector and do one-shot writebacks when damage comes in.
You would want GL apps to be throttled to the frame capture rate, so X
needs to implement waits for at least a swapinterval of 1 (I don't see
how greater than 1 would make any sense)
However, given that you'd be triggering writebacks on damage, and using
the fence to trigger the next wait for damage and writeback already, I
think you'd use that set of code for Present/DRI2 swapinterval support,
not the current vblank path.
My current inclination would be to throw -EINVAL for userspace vblank
requests on writeback conncetor pipes.
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging
On Tue, Jun 13, 2017 at 01:50:16PM +0200, Michael Thayer wrote: > 12.06.2017 18:03, Greg Kroah-Hartman wrote: > > On Mon, Jun 12, 2017 at 05:40:21PM +0200, Hans de Goede wrote: > >> Hi, > >> > >> On 12-06-17 13:44, Greg Kroah-Hartman wrote: > >>> On Mon, Jun 12, 2017 at 12:07:41PM +0200, Hans de Goede wrote: > > The most important thing is for the driver to be atomic if it's KMS > > only, and it would be good to have someone review that properly. > > I believe it does not use the atomic APIs atm, so that would be one > of the first things to fix then. Another question is if people > (you and Daniel at least) can live with the non kernel-coding > style shared files under the osindependent dir ? > >>> > >>> Why not just spend a few days and fix up all of the kernel-style issues > >>> so it can be a "real" driver? It shouldn't take all that long, > >>> especially for someone with Linux kernel experience (hint, hint...) > >> > >> The intention of the stuff below the osindepedent dir is for it to > >> be shared 1:1 between vboxvideo driver implementations for different > >> operating-systems. IIRC during the AMD DAL discussion Daniel indicated > >> that some OS independent code was fine (and would be exempt from coding > >> style rules) as long as it had a reasonable clean interface and was not > >> re-implementing anything we already have in the kernel. > > > > In a quick glance at the code in there, there's lots of reimplementing > > happening :( > > > > Maybe keep the data structures around, but really, you write those once, > > and then that's it, they should never change, so it shouldn't matter > > what format they are in. > > > >> If Daniel's verdict is that this needs to be cleaned up, then sure I > >> can easily do that. As mentioned I already did a lot of cleanup, > >> including moving all the other files to the kernel coding-style and > >> removing about 43000 lines of portability cruft / abstraction layers, > >> what is left under the osindependent directory is just C-structure > >> definitions and a few small plain C helper functions, which VirtualBox > >> upstream would like to keep as is... > > > > wrappers for simple things should not be needed at all, come on, you > > know that. We don't like driver-specific malloc/free and in/out > > functions, or asserts, or other crap like that. This implies that this > > driver is an island in itself and somehow more "important" than the 12+ > > million other lines of code that it lives within. Which isn't true. > > > > Just clean it up, that will make it even smaller, which in the end, is > > what really matters, as that will make it easier to maintain, fix, port > > to new apis, and everything else. > > > > There's a good reason why we don't have "os abstraction" layers in > > drivers in Linux, please don't ignore our history and knowledge here for > > no good reason. > > I would appreciate getting Dave and/or Daniel's feedback here, if they > have time. Given the size of the driver here, it seems like a good candidate for a drm-misc "small driver". So while I'm not named Dave or Daniel, I'll add my 2 cents. First, thank you for your submission. > In particular, they might have ideas about how to further > reduce the abstraction surface. In the end, the greater the difference > between the code in the kernel, the harder it is for people to pull > changes from our code to the kernel, and most of the changes in that > part are likely to come from our side. I don't think that converting > non-Linux-specific code in our tree to kernel style would go down well > in our team, so if the code as is is not acceptable, the next question > is, what would be? If we can come up with something which is alright > for both modulo a sed script that would still make people's lives > somewhat easier (though just the different brace style throws a bit of a > spanner in that). It's probably counterproductive to use AMD as a sterling example of getting a driver upstream. As you've mentioned, their driver is *much* larger than yours and there was still a fair amount of consternation about the os independent bits. I took a quick skim through your driver, and there doesn't seem to be much secret sauce there that will be tough to keep up-to-date across platforms. One other concern I have is that I noticed there are a few functions declared/defined in the osindependent code that are never used outside of it, so we have dead code off the hop. > > Please be clear, I am not trying to dictate to anyone. The code is GPL, > it is fine to include it with whatever modifications you deem > appropriate. Since individual distributions are already doing that, it > will still simplify our life somewhat if it is in the upstream kernel, > in whatever form, rather than in multiple forks. > > > Remember, this code needs us, we don't need this code at all :) > > I assume that that was not meant that way, but that came over as > slightly unf
[PATCH 1/6] drm/msm/mdp5: kill pipe_lock
It serves no purpose, things should be sufficiently synchronized already
by atomic framework. And it is somewhat awkward to be holding a spinlock
when msm_gem_iova() is going to start needing to grab a mutex.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 5e11653..c7ea5a0 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -22,8 +22,6 @@
struct mdp5_plane {
struct drm_plane base;
- spinlock_t pipe_lock; /* protect REG_MDP5_PIPE_* registers */
-
uint32_t nformats;
uint32_t formats[32];
};
@@ -875,7 +873,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
struct drm_rect *src, struct drm_rect *dest)
{
- struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
struct drm_plane_state *pstate = plane->state;
struct mdp5_hw_pipe *hwpipe = to_mdp5_plane_state(pstate)->hwpipe;
struct mdp5_kms *mdp5_kms = get_kms(plane);
@@ -896,7 +893,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
uint32_t src_img_w, src_img_h;
uint32_t src_x_r;
int crtc_x_r;
- unsigned long flags;
int ret;
nplanes = fb->format->num_planes;
@@ -975,8 +971,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
hflip = !!(rotation & DRM_REFLECT_X);
vflip = !!(rotation & DRM_REFLECT_Y);
- spin_lock_irqsave(&mdp5_plane->pipe_lock, flags);
-
mdp5_hwpipe_mode_set(mdp5_kms, hwpipe, fb, &step, &pe,
config, hdecm, vdecm, hflip, vflip,
crtc_x, crtc_y, crtc_w, crtc_h,
@@ -989,8 +983,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
src_img_w, src_img_h,
src_x_r, src_y, src_w, src_h);
- spin_unlock_irqrestore(&mdp5_plane->pipe_lock, flags);
-
plane->fb = fb;
return ret;
@@ -1132,8 +1124,6 @@ struct drm_plane *mdp5_plane_init(struct drm_device *dev,
mdp5_plane->nformats = mdp_get_formats(mdp5_plane->formats,
ARRAY_SIZE(mdp5_plane->formats), false);
- spin_lock_init(&mdp5_plane->pipe_lock);
-
if (type == DRM_PLANE_TYPE_CURSOR)
ret = drm_universal_plane_init(dev, plane, 0xff,
&mdp5_cursor_plane_funcs,
--
2.9.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/6] drm/msm: pass address-space to _get_iova() and friends
No functional change, that will come later. But this will make it
easier to deal with dynamically created address spaces (ie. per-
process pagetables for gpu).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 8
drivers/gpu/drm/msm/adreno/a5xx_power.c | 5 +++--
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 +++---
drivers/gpu/drm/msm/dsi/dsi_host.c| 4 ++--
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 6 +++---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 4 ++--
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 12 ++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 4 ++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 12 ++--
drivers/gpu/drm/msm/msm_drv.c | 5 -
drivers/gpu/drm/msm/msm_drv.h | 22 ++
drivers/gpu/drm/msm/msm_fb.c | 15 +--
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
drivers/gpu/drm/msm/msm_gem.c | 18 --
drivers/gpu/drm/msm/msm_gem.h | 1 +
drivers/gpu/drm/msm/msm_gem_submit.c | 4 ++--
drivers/gpu/drm/msm/msm_gpu.c | 6 +++---
17 files changed, 77 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index d5d6198..899f3dd 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -397,7 +397,7 @@ static struct drm_gem_object *a5xx_ucode_load_bo(struct
msm_gpu *gpu,
}
if (iova) {
- int ret = msm_gem_get_iova_locked(bo, gpu->id, iova);
+ int ret = msm_gem_get_iova_locked(bo, gpu->aspace, iova);
if (ret) {
drm_gem_object_unreference(bo);
@@ -765,19 +765,19 @@ static void a5xx_destroy(struct msm_gpu *gpu)
if (a5xx_gpu->pm4_bo) {
if (a5xx_gpu->pm4_iova)
- msm_gem_put_iova(a5xx_gpu->pm4_bo, gpu->id);
+ msm_gem_put_iova(a5xx_gpu->pm4_bo, gpu->aspace);
drm_gem_object_unreference_unlocked(a5xx_gpu->pm4_bo);
}
if (a5xx_gpu->pfp_bo) {
if (a5xx_gpu->pfp_iova)
- msm_gem_put_iova(a5xx_gpu->pfp_bo, gpu->id);
+ msm_gem_put_iova(a5xx_gpu->pfp_bo, gpu->aspace);
drm_gem_object_unreference_unlocked(a5xx_gpu->pfp_bo);
}
if (a5xx_gpu->gpmu_bo) {
if (a5xx_gpu->gpmu_iova)
- msm_gem_put_iova(a5xx_gpu->gpmu_bo, gpu->id);
+ msm_gem_put_iova(a5xx_gpu->gpmu_bo, gpu->aspace);
drm_gem_object_unreference_unlocked(a5xx_gpu->gpmu_bo);
}
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_power.c
b/drivers/gpu/drm/msm/adreno/a5xx_power.c
index 7838f5f..cff45c6 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_power.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_power.c
@@ -298,7 +298,8 @@ void a5xx_gpmu_ucode_init(struct msm_gpu *gpu)
if (IS_ERR(a5xx_gpu->gpmu_bo))
goto err;
- if (msm_gem_get_iova_locked(a5xx_gpu->gpmu_bo, gpu->id,
&a5xx_gpu->gpmu_iova))
+ if (msm_gem_get_iova_locked(a5xx_gpu->gpmu_bo, gpu->aspace,
+ &a5xx_gpu->gpmu_iova))
goto err;
ptr = msm_gem_get_vaddr_locked(a5xx_gpu->gpmu_bo);
@@ -327,7 +328,7 @@ void a5xx_gpmu_ucode_init(struct msm_gpu *gpu)
err:
if (a5xx_gpu->gpmu_iova)
- msm_gem_put_iova(a5xx_gpu->gpmu_bo, gpu->id);
+ msm_gem_put_iova(a5xx_gpu->gpmu_bo, gpu->aspace);
if (a5xx_gpu->gpmu_bo)
drm_gem_object_unreference(a5xx_gpu->gpmu_bo);
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 9e08b3e..b3dc704 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -64,7 +64,7 @@ int adreno_hw_init(struct msm_gpu *gpu)
DBG("%s", gpu->name);
- ret = msm_gem_get_iova_locked(gpu->rb->bo, gpu->id, &gpu->rb_iova);
+ ret = msm_gem_get_iova_locked(gpu->rb->bo, gpu->aspace, &gpu->rb_iova);
if (ret) {
gpu->rb_iova = 0;
dev_err(gpu->dev->dev, "could not map ringbuffer: %d\n", ret);
@@ -409,7 +409,7 @@ int adreno_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
return -ENOMEM;
}
- ret = msm_gem_get_iova(adreno_gpu->memptrs_bo, gpu->id,
+ ret = msm_gem_get_iova(adreno_gpu->memptrs_bo, gpu->aspace,
&adreno_gpu->memptrs_iova);
if (ret) {
dev_err(drm->dev, "could not map memptrs: %d\n", ret);
@@ -428,7 +428,7 @@ void adreno_gpu_cleanup(struct adreno_gpu *adreno_gpu)
msm_gem_put_vaddr(adreno_gpu->memptrs_bo);
if (adreno_gpu->memptrs_iova)
- msm_gem_put_iova(adreno_gpu->memptrs_bo, gpu->id);
+
[PATCH 4/6] drm/msm: refactor how we handle vram carveout buffers
Pull some of the logic out into msm_gem_new() (since we don't need to
care about the imported-bo case), and don't defer allocating pages. The
latter is generally a good idea, since if we are using VRAM carveout to
allocate contiguous buffers (ie. no IOMMU), the allocation is more
likely to fail. So failing at allocation time is a more sane option.
Plus this simplifies things in the next patch.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 48 ---
1 file changed, 27 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 2f470a6..754432c 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -324,12 +324,8 @@ int msm_gem_get_iova_locked(struct drm_gem_object *obj,
if (IS_ERR(pages))
return PTR_ERR(pages);
- if (iommu_present(&platform_bus_type)) {
- ret = msm_gem_map_vma(priv->aspace[id],
&msm_obj->domain[id],
- msm_obj->sgt, obj->size >> PAGE_SHIFT);
- } else {
- msm_obj->domain[id].iova = physaddr(obj);
- }
+ ret = msm_gem_map_vma(priv->aspace[id], &msm_obj->domain[id],
+ msm_obj->sgt, obj->size >> PAGE_SHIFT);
}
if (!ret)
@@ -765,7 +761,6 @@ static int msm_gem_new_impl(struct drm_device *dev,
{
struct msm_drm_private *priv = dev->dev_private;
struct msm_gem_object *msm_obj;
- bool use_vram = false;
switch (flags & MSM_BO_CACHE_MASK) {
case MSM_BO_UNCACHED:
@@ -778,21 +773,10 @@ static int msm_gem_new_impl(struct drm_device *dev,
return -EINVAL;
}
- if (!iommu_present(&platform_bus_type))
- use_vram = true;
- else if ((flags & MSM_BO_STOLEN) && priv->vram.size)
- use_vram = true;
-
- if (WARN_ON(use_vram && !priv->vram.size))
- return -EINVAL;
-
msm_obj = kzalloc(sizeof(*msm_obj), GFP_KERNEL);
if (!msm_obj)
return -ENOMEM;
- if (use_vram)
- msm_obj->vram_node = &msm_obj->domain[0].node;
-
msm_obj->flags = flags;
msm_obj->madv = MSM_MADV_WILLNEED;
@@ -814,13 +798,23 @@ static int msm_gem_new_impl(struct drm_device *dev,
struct drm_gem_object *msm_gem_new(struct drm_device *dev,
uint32_t size, uint32_t flags)
{
+ struct msm_drm_private *priv = dev->dev_private;
struct drm_gem_object *obj = NULL;
+ bool use_vram = false;
int ret;
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
size = PAGE_ALIGN(size);
+ if (!iommu_present(&platform_bus_type))
+ use_vram = true;
+ else if ((flags & MSM_BO_STOLEN) && priv->vram.size)
+ use_vram = true;
+
+ if (WARN_ON(use_vram && !priv->vram.size))
+ return ERR_PTR(-EINVAL);
+
/* Disallow zero sized objects as they make the underlying
* infrastructure grumpy
*/
@@ -831,12 +825,24 @@ struct drm_gem_object *msm_gem_new(struct drm_device *dev,
if (ret)
goto fail;
- if (use_pages(obj)) {
+ if (use_vram) {
+ struct msm_gem_object *msm_obj = to_msm_bo(obj);
+ struct page **pages;
+
+ msm_obj->vram_node = &msm_obj->domain[0].node;
+ drm_gem_private_object_init(dev, obj, size);
+
+ msm_obj->pages = get_pages(obj);
+ pages = get_pages(obj);
+ if (IS_ERR(pages)) {
+ ret = PTR_ERR(pages);
+ goto fail;
+ }
+ msm_obj->domain[0].iova = physaddr(obj);
+ } else {
ret = drm_gem_object_init(dev, obj, size);
if (ret)
goto fail;
- } else {
- drm_gem_private_object_init(dev, obj, size);
}
return obj;
--
2.9.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/msm/mdp4+5: move aspace/id to base class
Before we can shift to passing the address-space object to _get_iova(),
we need to fix a few places (dsi+fbdev) that were hard-coding the adress
space id. That gets somewhat easier if we just move these to the kms
base class.
Prep work for next patch.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/dsi/dsi_host.c| 10 --
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 9 ++---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 14 +++---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 4
drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 15 +--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 6 --
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 10 +-
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 4
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 16 ++--
drivers/gpu/drm/msm/msm_fbdev.c | 4 +++-
drivers/gpu/drm/msm/msm_kms.h | 4
11 files changed, 56 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 1fc07ce..81ddf42 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -32,6 +32,7 @@
#include "dsi.xml.h"
#include "sfpb.xml.h"
#include "dsi_cfg.h"
+#include "msm_kms.h"
static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)
{
@@ -975,6 +976,7 @@ static void dsi_wait4video_eng_busy(struct msm_dsi_host
*msm_host)
static int dsi_tx_buf_alloc(struct msm_dsi_host *msm_host, int size)
{
struct drm_device *dev = msm_host->dev;
+ struct msm_drm_private *priv = dev->dev_private;
const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
int ret;
uint64_t iova;
@@ -991,7 +993,8 @@ static int dsi_tx_buf_alloc(struct msm_dsi_host *msm_host,
int size)
return ret;
}
- ret = msm_gem_get_iova_locked(msm_host->tx_gem_obj, 0, &iova);
+ ret = msm_gem_get_iova_locked(msm_host->tx_gem_obj,
+ priv->kms->id, &iova);
mutex_unlock(&dev->struct_mutex);
if (ret) {
pr_err("%s: failed to get iova, %d\n", __func__, ret);
@@ -1141,12 +1144,15 @@ static int dsi_long_read_resp(u8 *buf, const struct
mipi_dsi_msg *msg)
static int dsi_cmd_dma_tx(struct msm_dsi_host *msm_host, int len)
{
const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
+ struct drm_device *dev = msm_host->dev;
+ struct msm_drm_private *priv = dev->dev_private;
int ret;
uint64_t dma_base;
bool triggered;
if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G) {
- ret = msm_gem_get_iova(msm_host->tx_gem_obj, 0, &dma_base);
+ ret = msm_gem_get_iova(msm_host->tx_gem_obj,
+ priv->kms->id, &dma_base);
if (ret) {
pr_err("%s: failed to get iova: %d\n", __func__, ret);
return ret;
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
index f29194a..36b0a09 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
@@ -126,8 +126,9 @@ static void unref_cursor_worker(struct drm_flip_work *work,
void *val)
struct mdp4_crtc *mdp4_crtc =
container_of(work, struct mdp4_crtc, unref_cursor_work);
struct mdp4_kms *mdp4_kms = get_kms(&mdp4_crtc->base);
+ struct msm_kms *kms = &mdp4_kms->base.base;
- msm_gem_put_iova(val, mdp4_kms->id);
+ msm_gem_put_iova(val, kms->id);
drm_gem_object_unreference_unlocked(val);
}
@@ -360,6 +361,7 @@ static void update_cursor(struct drm_crtc *crtc)
{
struct mdp4_crtc *mdp4_crtc = to_mdp4_crtc(crtc);
struct mdp4_kms *mdp4_kms = get_kms(crtc);
+ struct msm_kms *kms = &mdp4_kms->base.base;
enum mdp4_dma dma = mdp4_crtc->dma;
unsigned long flags;
@@ -372,7 +374,7 @@ static void update_cursor(struct drm_crtc *crtc)
if (next_bo) {
/* take a obj ref + iova ref when we start scanning
out: */
drm_gem_object_reference(next_bo);
- msm_gem_get_iova_locked(next_bo, mdp4_kms->id, &iova);
+ msm_gem_get_iova_locked(next_bo, kms->id, &iova);
/* enable cursor: */
mdp4_write(mdp4_kms, REG_MDP4_DMA_CURSOR_SIZE(dma),
@@ -409,6 +411,7 @@ static int mdp4_crtc_cursor_set(struct drm_crtc *crtc,
{
struct mdp4_crtc *mdp4_crtc = to_mdp4_crtc(crtc);
struct mdp4_kms *mdp4_kms = get_kms(crtc);
+ struct msm_kms *kms = &mdp4_kms->base.base;
struct drm_device *dev = crtc->dev;
struct drm_gem_object *cursor_bo, *old_bo;
unsigned long flags;
@@ -429,7 +432,7 @@ static int mdp4_crtc_cursor_set(struct drm_crtc *crtc,
[PATCH 0/6] drm/msm: support arbitrary number of vma's per gem bo
A step towards having per-process pagetables, we need to be able to map a given buffer into multiple address spaces. This is similar to Jordan's "drm/msm: get an iova from the address space instead of an id" patch, except split up into smaller steps, and fixing some issues with the non-IOMMU case. Rob Clark (6): drm/msm/mdp5: kill pipe_lock drm/msm/mdp4+5: move aspace/id to base class drm/msm: pass address-space to _get_iova() and friends drm/msm: refactor how we handle vram carveout buffers drm/msm: support for an arbitrary number of address spaces drm/msm: remove address-space id drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 8 +- drivers/gpu/drm/msm/adreno/a5xx_power.c | 5 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 +- drivers/gpu/drm/msm/dsi/dsi_host.c| 10 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 9 +- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 15 +-- drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 4 - drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 15 ++- drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 6 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 11 +- drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 4 - drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 ++--- drivers/gpu/drm/msm/msm_drv.c | 13 --- drivers/gpu/drm/msm/msm_drv.h | 33 +++--- drivers/gpu/drm/msm/msm_fb.c | 15 ++- drivers/gpu/drm/msm/msm_fbdev.c | 4 +- drivers/gpu/drm/msm/msm_gem.c | 184 -- drivers/gpu/drm/msm/msm_gem.h | 4 +- drivers/gpu/drm/msm/msm_gem_submit.c | 4 +- drivers/gpu/drm/msm/msm_gpu.c | 8 +- drivers/gpu/drm/msm/msm_gpu.h | 1 - drivers/gpu/drm/msm/msm_kms.h | 3 + 22 files changed, 215 insertions(+), 173 deletions(-) -- 2.9.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/6] drm/msm: remove address-space id
Now that the msm_gem supports an arbitrary number of vma's, we no longer
need to assign an id (index) to each address space. So rip out the
associated code.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 7 ---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 7 ---
drivers/gpu/drm/msm/msm_drv.c | 16
drivers/gpu/drm/msm/msm_drv.h | 11 ---
drivers/gpu/drm/msm/msm_gem.h | 1 -
drivers/gpu/drm/msm/msm_gpu.c | 2 --
drivers/gpu/drm/msm/msm_gpu.h | 1 -
drivers/gpu/drm/msm/msm_kms.h | 1 -
8 files changed, 46 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index d1f572f..c29eb1f 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -548,13 +548,6 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
aspace = NULL;
}
- kms->id = msm_register_address_space(dev, aspace);
- if (kms->id < 0) {
- ret = kms->id;
- dev_err(dev->dev, "failed to register mdp4 iommu: %d\n", ret);
- goto fail;
- }
-
ret = modeset_init(mdp4_kms);
if (ret) {
dev_err(dev->dev, "modeset_init failed: %d\n", ret);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 6d9d332..438badd 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -746,13 +746,6 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
aspace = NULL;;
}
- kms->id = msm_register_address_space(dev, aspace);
- if (kms->id < 0) {
- ret = kms->id;
- dev_err(&pdev->dev, "failed to register mdp5 iommu: %d\n", ret);
- goto fail;
- }
-
ret = modeset_init(mdp5_kms);
if (ret) {
dev_err(&pdev->dev, "modeset_init failed: %d\n", ret);
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index e938379..ea43816 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -51,22 +51,6 @@ static const struct drm_mode_config_funcs mode_config_funcs
= {
.atomic_state_free = msm_atomic_state_free,
};
-#include "msm_gem.h" /* temporary */
-int msm_register_address_space(struct drm_device *dev,
- struct msm_gem_address_space *aspace)
-{
- struct msm_drm_private *priv = dev->dev_private;
-
- if (WARN_ON(priv->num_aspaces >= ARRAY_SIZE(priv->aspace)))
- return -EINVAL;
-
- priv->aspace[priv->num_aspaces] = aspace;
-
- aspace->id = priv->num_aspaces++;
-
- return aspace->id;
-}
-
#ifdef CONFIG_DRM_MSM_REGISTER_LOGGING
static bool reglog = false;
MODULE_PARM_DESC(reglog, "Enable register read/write logging");
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index f3f5d6a..b48aa88 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -123,14 +123,6 @@ struct msm_drm_private {
uint32_t pending_crtcs;
wait_queue_head_t pending_crtcs_event;
- /* Registered address spaces.. currently this is fixed per # of
-* iommu's. Ie. one for display block and one for gpu block.
-* Eventually, to do per-process gpu pagetables, we'll want one
-* of these per-process.
-*/
- unsigned int num_aspaces;
- struct msm_gem_address_space *aspace[NUM_DOMAINS];
-
unsigned int num_planes;
struct drm_plane *planes[16];
@@ -183,9 +175,6 @@ struct drm_atomic_state *msm_atomic_state_alloc(struct
drm_device *dev);
void msm_atomic_state_clear(struct drm_atomic_state *state);
void msm_atomic_state_free(struct drm_atomic_state *state);
-int msm_register_address_space(struct drm_device *dev,
- struct msm_gem_address_space *aspace);
-
void msm_gem_unmap_vma(struct msm_gem_address_space *aspace,
struct msm_gem_vma *vma, struct sg_table *sgt);
int msm_gem_map_vma(struct msm_gem_address_space *aspace,
diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
index ff468da..112eb63 100644
--- a/drivers/gpu/drm/msm/msm_gem.h
+++ b/drivers/gpu/drm/msm/msm_gem.h
@@ -33,7 +33,6 @@ struct msm_gem_address_space {
struct drm_mm mm;
struct msm_mmu *mmu;
struct kref kref;
- int id;/* temporary */
};
struct msm_gem_vma {
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index de1d22c..bc6cd9e 100644
--- a/drivers/gpu/drm/msm/msm_gpu.c
+++ b/drivers/gpu/drm/msm/msm_gpu.c
@@ -660,8 +660,6 @@ int msm_gpu_init(struct drm_device *drm, struct
platform_device *pdev,
} else {
dev_info(drm->dev, "%s: no IOMMU, fallback to VRAM
carveout!\n", name);
}
- gpu->id = msm_register_address_space(drm, gpu->as
[PATCH 5/6] drm/msm: support for an arbitrary number of address spaces
It means we have to do a list traversal where we once had an index into
a table. But the list will normally have one or two entries.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 138 +-
drivers/gpu/drm/msm/msm_gem.h | 4 +-
2 files changed, 99 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index 754432c..410368f 100644
--- a/drivers/gpu/drm/msm/msm_gem.c
+++ b/drivers/gpu/drm/msm/msm_gem.c
@@ -283,21 +283,59 @@ uint64_t msm_gem_mmap_offset(struct drm_gem_object *obj)
return offset;
}
+static struct msm_gem_vma *add_vma(struct drm_gem_object *obj,
+ struct msm_gem_address_space *aspace)
+{
+ struct msm_gem_object *msm_obj = to_msm_bo(obj);
+ struct msm_gem_vma *vma;
+
+ vma = kzalloc(sizeof(*vma), GFP_KERNEL);
+ if (!vma)
+ return ERR_PTR(-ENOMEM);
+
+ vma->aspace = aspace;
+
+ list_add_tail(&vma->list, &msm_obj->vmas);
+
+ return vma;
+}
+
+static struct msm_gem_vma *lookup_vma(struct drm_gem_object *obj,
+ struct msm_gem_address_space *aspace)
+{
+ struct msm_gem_object *msm_obj = to_msm_bo(obj);
+ struct msm_gem_vma *vma;
+
+ WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
+
+ list_for_each_entry(vma, &msm_obj->vmas, list) {
+ if (vma->aspace == aspace)
+ return vma;
+ }
+
+ return NULL;
+}
+
+static void del_vma(struct msm_gem_vma *vma)
+{
+ if (!vma)
+ return;
+
+ list_del(&vma->list);
+ kfree(vma);
+}
+
static void
put_iova(struct drm_gem_object *obj)
{
- struct drm_device *dev = obj->dev;
- struct msm_drm_private *priv = obj->dev->dev_private;
struct msm_gem_object *msm_obj = to_msm_bo(obj);
- int id;
+ struct msm_gem_vma *vma, *tmp;
- WARN_ON(!mutex_is_locked(&dev->struct_mutex));
+ WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
- for (id = 0; id < ARRAY_SIZE(msm_obj->domain); id++) {
- if (!priv->aspace[id])
- continue;
- msm_gem_unmap_vma(priv->aspace[id],
- &msm_obj->domain[id], msm_obj->sgt);
+ list_for_each_entry_safe(vma, tmp, &msm_obj->vmas, list) {
+ msm_gem_unmap_vma(vma->aspace, vma, msm_obj->sgt);
+ del_vma(vma);
}
}
@@ -312,24 +350,37 @@ int msm_gem_get_iova_locked(struct drm_gem_object *obj,
struct msm_gem_address_space *aspace, uint64_t *iova)
{
struct msm_gem_object *msm_obj = to_msm_bo(obj);
- int id = aspace ? aspace->id : 0;
+ struct msm_gem_vma *vma;
int ret = 0;
WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
- if (!msm_obj->domain[id].iova) {
- struct msm_drm_private *priv = obj->dev->dev_private;
- struct page **pages = get_pages(obj);
+ vma = lookup_vma(obj, aspace);
- if (IS_ERR(pages))
- return PTR_ERR(pages);
+ if (!vma) {
+ struct page **pages;
+
+ vma = add_vma(obj, aspace);
+ if (IS_ERR(vma))
+ return PTR_ERR(vma);
+
+ pages = get_pages(obj);
+ if (IS_ERR(pages)) {
+ ret = PTR_ERR(pages);
+ goto fail;
+ }
- ret = msm_gem_map_vma(priv->aspace[id], &msm_obj->domain[id],
- msm_obj->sgt, obj->size >> PAGE_SHIFT);
+ ret = msm_gem_map_vma(aspace, vma, msm_obj->sgt,
+ obj->size >> PAGE_SHIFT);
+ if (ret)
+ goto fail;
}
- if (!ret)
- *iova = msm_obj->domain[id].iova;
+ *iova = vma->iova;
+ return 0;
+
+fail:
+ del_vma(vma);
return ret;
}
@@ -338,22 +389,12 @@ int msm_gem_get_iova_locked(struct drm_gem_object *obj,
int msm_gem_get_iova(struct drm_gem_object *obj,
struct msm_gem_address_space *aspace, uint64_t *iova)
{
- struct msm_gem_object *msm_obj = to_msm_bo(obj);
- int id = aspace ? aspace->id : 0;
int ret;
- /* this is safe right now because we don't unmap until the
-* bo is deleted:
-*/
- if (msm_obj->domain[id].iova) {
- might_lock(&obj->dev->struct_mutex);
- *iova = msm_obj->domain[id].iova;
- return 0;
- }
-
mutex_lock(&obj->dev->struct_mutex);
ret = msm_gem_get_iova_locked(obj, aspace, iova);
mutex_unlock(&obj->dev->struct_mutex);
+
return ret;
}
@@ -363,10 +404,14 @@ int msm_gem_get_iova(struct drm_gem_object *obj,
uint64_t msm_gem_iova(struct drm_gem_object *obj,
struct msm_gem_address_space *aspace)
{
- struct msm_gem_obj
Re: [PATCH 1/6] drm/msm/mdp5: kill pipe_lock
On Tue, Jun 13, 2017 at 02:49:43PM -0400, Rob Clark wrote:
> It serves no purpose, things should be sufficiently synchronized already
> by atomic framework. And it is somewhat awkward to be holding a spinlock
> when msm_gem_iova() is going to start needing to grab a mutex.
>
> Signed-off-by: Rob Clark
Acked-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> index 5e11653..c7ea5a0 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> @@ -22,8 +22,6 @@
> struct mdp5_plane {
> struct drm_plane base;
>
> - spinlock_t pipe_lock; /* protect REG_MDP5_PIPE_* registers */
> -
> uint32_t nformats;
> uint32_t formats[32];
> };
> @@ -875,7 +873,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
> struct drm_crtc *crtc, struct drm_framebuffer *fb,
> struct drm_rect *src, struct drm_rect *dest)
> {
> - struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
> struct drm_plane_state *pstate = plane->state;
> struct mdp5_hw_pipe *hwpipe = to_mdp5_plane_state(pstate)->hwpipe;
> struct mdp5_kms *mdp5_kms = get_kms(plane);
> @@ -896,7 +893,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
> uint32_t src_img_w, src_img_h;
> uint32_t src_x_r;
> int crtc_x_r;
> - unsigned long flags;
> int ret;
>
> nplanes = fb->format->num_planes;
> @@ -975,8 +971,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
> hflip = !!(rotation & DRM_REFLECT_X);
> vflip = !!(rotation & DRM_REFLECT_Y);
>
> - spin_lock_irqsave(&mdp5_plane->pipe_lock, flags);
> -
> mdp5_hwpipe_mode_set(mdp5_kms, hwpipe, fb, &step, &pe,
>config, hdecm, vdecm, hflip, vflip,
>crtc_x, crtc_y, crtc_w, crtc_h,
> @@ -989,8 +983,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
>src_img_w, src_img_h,
>src_x_r, src_y, src_w, src_h);
>
> - spin_unlock_irqrestore(&mdp5_plane->pipe_lock, flags);
> -
> plane->fb = fb;
>
> return ret;
> @@ -1132,8 +1124,6 @@ struct drm_plane *mdp5_plane_init(struct drm_device
> *dev,
> mdp5_plane->nformats = mdp_get_formats(mdp5_plane->formats,
> ARRAY_SIZE(mdp5_plane->formats), false);
>
> - spin_lock_init(&mdp5_plane->pipe_lock);
> -
> if (type == DRM_PLANE_TYPE_CURSOR)
> ret = drm_universal_plane_init(dev, plane, 0xff,
> &mdp5_cursor_plane_funcs,
> --
> 2.9.4
>
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/6] drm/msm/mdp4+5: move aspace/id to base class
On Tue, Jun 13, 2017 at 02:49:44PM -0400, Rob Clark wrote:
> Before we can shift to passing the address-space object to _get_iova(),
> we need to fix a few places (dsi+fbdev) that were hard-coding the adress
nit - adress -> address. Otherwise,
Acked-By: Jordan Crouse
> space id. That gets somewhat easier if we just move these to the kms
> base class.
>
> Prep work for next patch.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/dsi/dsi_host.c| 10 --
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 9 ++---
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 14 +++---
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.h | 4
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 15 +--
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 6 --
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 10 +-
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h | 4
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 16 ++--
> drivers/gpu/drm/msm/msm_fbdev.c | 4 +++-
> drivers/gpu/drm/msm/msm_kms.h | 4
> 11 files changed, 56 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 1fc07ce..81ddf42 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -32,6 +32,7 @@
> #include "dsi.xml.h"
> #include "sfpb.xml.h"
> #include "dsi_cfg.h"
> +#include "msm_kms.h"
>
> static int dsi_get_version(const void __iomem *base, u32 *major, u32 *minor)
> {
> @@ -975,6 +976,7 @@ static void dsi_wait4video_eng_busy(struct msm_dsi_host
> *msm_host)
> static int dsi_tx_buf_alloc(struct msm_dsi_host *msm_host, int size)
> {
> struct drm_device *dev = msm_host->dev;
> + struct msm_drm_private *priv = dev->dev_private;
> const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
> int ret;
> uint64_t iova;
> @@ -991,7 +993,8 @@ static int dsi_tx_buf_alloc(struct msm_dsi_host
> *msm_host, int size)
> return ret;
> }
>
> - ret = msm_gem_get_iova_locked(msm_host->tx_gem_obj, 0, &iova);
> + ret = msm_gem_get_iova_locked(msm_host->tx_gem_obj,
> + priv->kms->id, &iova);
> mutex_unlock(&dev->struct_mutex);
> if (ret) {
> pr_err("%s: failed to get iova, %d\n", __func__, ret);
> @@ -1141,12 +1144,15 @@ static int dsi_long_read_resp(u8 *buf, const struct
> mipi_dsi_msg *msg)
> static int dsi_cmd_dma_tx(struct msm_dsi_host *msm_host, int len)
> {
> const struct msm_dsi_cfg_handler *cfg_hnd = msm_host->cfg_hnd;
> + struct drm_device *dev = msm_host->dev;
> + struct msm_drm_private *priv = dev->dev_private;
> int ret;
> uint64_t dma_base;
> bool triggered;
>
> if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G) {
> - ret = msm_gem_get_iova(msm_host->tx_gem_obj, 0, &dma_base);
> + ret = msm_gem_get_iova(msm_host->tx_gem_obj,
> + priv->kms->id, &dma_base);
> if (ret) {
> pr_err("%s: failed to get iova: %d\n", __func__, ret);
> return ret;
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
> index f29194a..36b0a09 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
> @@ -126,8 +126,9 @@ static void unref_cursor_worker(struct drm_flip_work
> *work, void *val)
> struct mdp4_crtc *mdp4_crtc =
> container_of(work, struct mdp4_crtc, unref_cursor_work);
> struct mdp4_kms *mdp4_kms = get_kms(&mdp4_crtc->base);
> + struct msm_kms *kms = &mdp4_kms->base.base;
>
> - msm_gem_put_iova(val, mdp4_kms->id);
> + msm_gem_put_iova(val, kms->id);
> drm_gem_object_unreference_unlocked(val);
> }
>
> @@ -360,6 +361,7 @@ static void update_cursor(struct drm_crtc *crtc)
> {
> struct mdp4_crtc *mdp4_crtc = to_mdp4_crtc(crtc);
> struct mdp4_kms *mdp4_kms = get_kms(crtc);
> + struct msm_kms *kms = &mdp4_kms->base.base;
> enum mdp4_dma dma = mdp4_crtc->dma;
> unsigned long flags;
>
> @@ -372,7 +374,7 @@ static void update_cursor(struct drm_crtc *crtc)
> if (next_bo) {
> /* take a obj ref + iova ref when we start scanning
> out: */
> drm_gem_object_reference(next_bo);
> - msm_gem_get_iova_locked(next_bo, mdp4_kms->id, &iova);
> + msm_gem_get_iova_locked(next_bo, kms->id, &iova);
>
> /* enable cursor: */
> mdp4_write(mdp4_kms, REG_MDP4_DMA_CURSOR_SIZE(dma),
> @@ -409,6 +411,7 @@ static int mdp4_crtc_cursor_set(struct drm_crtc *crtc,
> {
> struct mdp4_crtc *mdp4_crtc = to_mdp4_crtc(crtc);
> struct mdp4_kms *mdp4_kms = get_kms(crtc);
>
Re: [PATCH 3/6] drm/msm: pass address-space to _get_iova() and friends
On Tue, Jun 13, 2017 at 02:49:45PM -0400, Rob Clark wrote:
> No functional change, that will come later. But this will make it
> easier to deal with dynamically created address spaces (ie. per-
> process pagetables for gpu).
>
> Signed-off-by: Rob Clark
Acked-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 8
> drivers/gpu/drm/msm/adreno/a5xx_power.c | 5 +++--
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 +++---
> drivers/gpu/drm/msm/dsi/dsi_host.c| 4 ++--
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 6 +++---
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 4 ++--
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 12 ++--
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 4 ++--
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 12 ++--
> drivers/gpu/drm/msm/msm_drv.c | 5 -
> drivers/gpu/drm/msm/msm_drv.h | 22 ++
> drivers/gpu/drm/msm/msm_fb.c | 15 +--
> drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
> drivers/gpu/drm/msm/msm_gem.c | 18 --
> drivers/gpu/drm/msm/msm_gem.h | 1 +
> drivers/gpu/drm/msm/msm_gem_submit.c | 4 ++--
> drivers/gpu/drm/msm/msm_gpu.c | 6 +++---
> 17 files changed, 77 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index d5d6198..899f3dd 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -397,7 +397,7 @@ static struct drm_gem_object *a5xx_ucode_load_bo(struct
> msm_gpu *gpu,
> }
>
> if (iova) {
> - int ret = msm_gem_get_iova_locked(bo, gpu->id, iova);
> + int ret = msm_gem_get_iova_locked(bo, gpu->aspace, iova);
>
> if (ret) {
> drm_gem_object_unreference(bo);
> @@ -765,19 +765,19 @@ static void a5xx_destroy(struct msm_gpu *gpu)
>
> if (a5xx_gpu->pm4_bo) {
> if (a5xx_gpu->pm4_iova)
> - msm_gem_put_iova(a5xx_gpu->pm4_bo, gpu->id);
> + msm_gem_put_iova(a5xx_gpu->pm4_bo, gpu->aspace);
> drm_gem_object_unreference_unlocked(a5xx_gpu->pm4_bo);
> }
>
> if (a5xx_gpu->pfp_bo) {
> if (a5xx_gpu->pfp_iova)
> - msm_gem_put_iova(a5xx_gpu->pfp_bo, gpu->id);
> + msm_gem_put_iova(a5xx_gpu->pfp_bo, gpu->aspace);
> drm_gem_object_unreference_unlocked(a5xx_gpu->pfp_bo);
> }
>
> if (a5xx_gpu->gpmu_bo) {
> if (a5xx_gpu->gpmu_iova)
> - msm_gem_put_iova(a5xx_gpu->gpmu_bo, gpu->id);
> + msm_gem_put_iova(a5xx_gpu->gpmu_bo, gpu->aspace);
> drm_gem_object_unreference_unlocked(a5xx_gpu->gpmu_bo);
> }
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_power.c
> b/drivers/gpu/drm/msm/adreno/a5xx_power.c
> index 7838f5f..cff45c6 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_power.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_power.c
> @@ -298,7 +298,8 @@ void a5xx_gpmu_ucode_init(struct msm_gpu *gpu)
> if (IS_ERR(a5xx_gpu->gpmu_bo))
> goto err;
>
> - if (msm_gem_get_iova_locked(a5xx_gpu->gpmu_bo, gpu->id,
> &a5xx_gpu->gpmu_iova))
> + if (msm_gem_get_iova_locked(a5xx_gpu->gpmu_bo, gpu->aspace,
> + &a5xx_gpu->gpmu_iova))
> goto err;
>
> ptr = msm_gem_get_vaddr_locked(a5xx_gpu->gpmu_bo);
> @@ -327,7 +328,7 @@ void a5xx_gpmu_ucode_init(struct msm_gpu *gpu)
>
> err:
> if (a5xx_gpu->gpmu_iova)
> - msm_gem_put_iova(a5xx_gpu->gpmu_bo, gpu->id);
> + msm_gem_put_iova(a5xx_gpu->gpmu_bo, gpu->aspace);
> if (a5xx_gpu->gpmu_bo)
> drm_gem_object_unreference(a5xx_gpu->gpmu_bo);
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 9e08b3e..b3dc704 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -64,7 +64,7 @@ int adreno_hw_init(struct msm_gpu *gpu)
>
> DBG("%s", gpu->name);
>
> - ret = msm_gem_get_iova_locked(gpu->rb->bo, gpu->id, &gpu->rb_iova);
> + ret = msm_gem_get_iova_locked(gpu->rb->bo, gpu->aspace, &gpu->rb_iova);
> if (ret) {
> gpu->rb_iova = 0;
> dev_err(gpu->dev->dev, "could not map ringbuffer: %d\n", ret);
> @@ -409,7 +409,7 @@ int adreno_gpu_init(struct drm_device *drm, struct
> platform_device *pdev,
> return -ENOMEM;
> }
>
> - ret = msm_gem_get_iova(adreno_gpu->memptrs_bo, gpu->id,
> + ret = msm_gem_get_iova(adreno_gpu->memptrs_bo, gpu->aspace,
> &adreno_gpu->memptrs_iova);
> if (ret) {
> dev_err(drm->dev, "could not map memptrs: %d\n", ret);
> @@ -428,7 +428,7 @@ void adreno_gpu_cleanup(struct adreno_gp
Re: [PATCH 4/6] drm/msm: refactor how we handle vram carveout buffers
On Tue, Jun 13, 2017 at 02:49:46PM -0400, Rob Clark wrote:
> Pull some of the logic out into msm_gem_new() (since we don't need to
> care about the imported-bo case), and don't defer allocating pages. The
> latter is generally a good idea, since if we are using VRAM carveout to
> allocate contiguous buffers (ie. no IOMMU), the allocation is more
> likely to fail. So failing at allocation time is a more sane option.
> Plus this simplifies things in the next patch.
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gem.c | 48
> ---
> 1 file changed, 27 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 2f470a6..754432c 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -324,12 +324,8 @@ int msm_gem_get_iova_locked(struct drm_gem_object *obj,
> if (IS_ERR(pages))
> return PTR_ERR(pages);
>
> - if (iommu_present(&platform_bus_type)) {
> - ret = msm_gem_map_vma(priv->aspace[id],
> &msm_obj->domain[id],
> - msm_obj->sgt, obj->size >> PAGE_SHIFT);
> - } else {
> - msm_obj->domain[id].iova = physaddr(obj);
> - }
> + ret = msm_gem_map_vma(priv->aspace[id], &msm_obj->domain[id],
> + msm_obj->sgt, obj->size >> PAGE_SHIFT);
> }
>
> if (!ret)
> @@ -765,7 +761,6 @@ static int msm_gem_new_impl(struct drm_device *dev,
> {
> struct msm_drm_private *priv = dev->dev_private;
> struct msm_gem_object *msm_obj;
> - bool use_vram = false;
>
> switch (flags & MSM_BO_CACHE_MASK) {
> case MSM_BO_UNCACHED:
> @@ -778,21 +773,10 @@ static int msm_gem_new_impl(struct drm_device *dev,
> return -EINVAL;
> }
>
> - if (!iommu_present(&platform_bus_type))
> - use_vram = true;
> - else if ((flags & MSM_BO_STOLEN) && priv->vram.size)
> - use_vram = true;
> -
> - if (WARN_ON(use_vram && !priv->vram.size))
> - return -EINVAL;
> -
> msm_obj = kzalloc(sizeof(*msm_obj), GFP_KERNEL);
> if (!msm_obj)
> return -ENOMEM;
>
> - if (use_vram)
> - msm_obj->vram_node = &msm_obj->domain[0].node;
> -
> msm_obj->flags = flags;
> msm_obj->madv = MSM_MADV_WILLNEED;
>
> @@ -814,13 +798,23 @@ static int msm_gem_new_impl(struct drm_device *dev,
> struct drm_gem_object *msm_gem_new(struct drm_device *dev,
> uint32_t size, uint32_t flags)
> {
> + struct msm_drm_private *priv = dev->dev_private;
> struct drm_gem_object *obj = NULL;
> + bool use_vram = false;
> int ret;
>
> WARN_ON(!mutex_is_locked(&dev->struct_mutex));
>
> size = PAGE_ALIGN(size);
>
> + if (!iommu_present(&platform_bus_type))
> + use_vram = true;
> + else if ((flags & MSM_BO_STOLEN) && priv->vram.size)
> + use_vram = true;
> +
> + if (WARN_ON(use_vram && !priv->vram.size))
> + return ERR_PTR(-EINVAL);
> +
I would say WARN_ONCE here but I guess if the first allocation fails we aren't
making any more. This might be worth a nastygram to the log.
> /* Disallow zero sized objects as they make the underlying
>* infrastructure grumpy
>*/
> @@ -831,12 +825,24 @@ struct drm_gem_object *msm_gem_new(struct drm_device
> *dev,
> if (ret)
> goto fail;
>
> - if (use_pages(obj)) {
> + if (use_vram) {
> + struct msm_gem_object *msm_obj = to_msm_bo(obj);
> + struct page **pages;
> +
> + msm_obj->vram_node = &msm_obj->domain[0].node;
> + drm_gem_private_object_init(dev, obj, size);
> +
> + msm_obj->pages = get_pages(obj);
> + pages = get_pages(obj);
> + if (IS_ERR(pages)) {
> + ret = PTR_ERR(pages);
> + goto fail;
> + }
> + msm_obj->domain[0].iova = physaddr(obj);
> + } else {
> ret = drm_gem_object_init(dev, obj, size);
> if (ret)
> goto fail;
> - } else {
> - drm_gem_private_object_init(dev, obj, size);
> }
>
> return obj;
> --
> 2.9.4
>
Otherwise,
Acked-by: Jordan Crouse
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm/msm: support for an arbitrary number of address spaces
On Tue, Jun 13, 2017 at 02:49:47PM -0400, Rob Clark wrote:
> It means we have to do a list traversal where we once had an index into
> a table. But the list will normally have one or two entries.
>
> Signed-off-by: Rob Clark
I dig the rename - makes more sense.
Acked-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/msm_gem.c | 138
> +-
> drivers/gpu/drm/msm/msm_gem.h | 4 +-
> 2 files changed, 99 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 754432c..410368f 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -283,21 +283,59 @@ uint64_t msm_gem_mmap_offset(struct drm_gem_object *obj)
> return offset;
> }
>
> +static struct msm_gem_vma *add_vma(struct drm_gem_object *obj,
> + struct msm_gem_address_space *aspace)
> +{
> + struct msm_gem_object *msm_obj = to_msm_bo(obj);
> + struct msm_gem_vma *vma;
> +
> + vma = kzalloc(sizeof(*vma), GFP_KERNEL);
> + if (!vma)
> + return ERR_PTR(-ENOMEM);
> +
> + vma->aspace = aspace;
> +
> + list_add_tail(&vma->list, &msm_obj->vmas);
> +
> + return vma;
> +}
> +
> +static struct msm_gem_vma *lookup_vma(struct drm_gem_object *obj,
> + struct msm_gem_address_space *aspace)
> +{
> + struct msm_gem_object *msm_obj = to_msm_bo(obj);
> + struct msm_gem_vma *vma;
> +
> + WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
> +
> + list_for_each_entry(vma, &msm_obj->vmas, list) {
> + if (vma->aspace == aspace)
> + return vma;
> + }
> +
> + return NULL;
> +}
> +
> +static void del_vma(struct msm_gem_vma *vma)
> +{
> + if (!vma)
> + return;
> +
> + list_del(&vma->list);
> + kfree(vma);
> +}
> +
> static void
> put_iova(struct drm_gem_object *obj)
> {
> - struct drm_device *dev = obj->dev;
> - struct msm_drm_private *priv = obj->dev->dev_private;
> struct msm_gem_object *msm_obj = to_msm_bo(obj);
> - int id;
> + struct msm_gem_vma *vma, *tmp;
>
> - WARN_ON(!mutex_is_locked(&dev->struct_mutex));
> + WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
>
> - for (id = 0; id < ARRAY_SIZE(msm_obj->domain); id++) {
> - if (!priv->aspace[id])
> - continue;
> - msm_gem_unmap_vma(priv->aspace[id],
> - &msm_obj->domain[id], msm_obj->sgt);
> + list_for_each_entry_safe(vma, tmp, &msm_obj->vmas, list) {
> + msm_gem_unmap_vma(vma->aspace, vma, msm_obj->sgt);
> + del_vma(vma);
> }
> }
>
> @@ -312,24 +350,37 @@ int msm_gem_get_iova_locked(struct drm_gem_object *obj,
> struct msm_gem_address_space *aspace, uint64_t *iova)
> {
> struct msm_gem_object *msm_obj = to_msm_bo(obj);
> - int id = aspace ? aspace->id : 0;
> + struct msm_gem_vma *vma;
> int ret = 0;
>
> WARN_ON(!mutex_is_locked(&obj->dev->struct_mutex));
>
> - if (!msm_obj->domain[id].iova) {
> - struct msm_drm_private *priv = obj->dev->dev_private;
> - struct page **pages = get_pages(obj);
> + vma = lookup_vma(obj, aspace);
>
> - if (IS_ERR(pages))
> - return PTR_ERR(pages);
> + if (!vma) {
> + struct page **pages;
> +
> + vma = add_vma(obj, aspace);
> + if (IS_ERR(vma))
> + return PTR_ERR(vma);
> +
> + pages = get_pages(obj);
> + if (IS_ERR(pages)) {
> + ret = PTR_ERR(pages);
> + goto fail;
> + }
>
> - ret = msm_gem_map_vma(priv->aspace[id], &msm_obj->domain[id],
> - msm_obj->sgt, obj->size >> PAGE_SHIFT);
> + ret = msm_gem_map_vma(aspace, vma, msm_obj->sgt,
> + obj->size >> PAGE_SHIFT);
> + if (ret)
> + goto fail;
> }
>
> - if (!ret)
> - *iova = msm_obj->domain[id].iova;
> + *iova = vma->iova;
> + return 0;
> +
> +fail:
> + del_vma(vma);
>
> return ret;
> }
> @@ -338,22 +389,12 @@ int msm_gem_get_iova_locked(struct drm_gem_object *obj,
> int msm_gem_get_iova(struct drm_gem_object *obj,
> struct msm_gem_address_space *aspace, uint64_t *iova)
> {
> - struct msm_gem_object *msm_obj = to_msm_bo(obj);
> - int id = aspace ? aspace->id : 0;
> int ret;
>
> - /* this is safe right now because we don't unmap until the
> - * bo is deleted:
> - */
> - if (msm_obj->domain[id].iova) {
> - might_lock(&obj->dev->struct_mutex);
> - *iova = msm_obj->domain[id].iova;
> - return 0;
> - }
> -
> mutex_lock(&obj->dev->struct_mutex);
> ret = msm_gem_get_iova_locked(obj, aspace, iova);
> mutex_unlock(&obj->dev
Re: [PATCH 6/6] drm/msm: remove address-space id
On Tue, Jun 13, 2017 at 02:49:48PM -0400, Rob Clark wrote:
> Now that the msm_gem supports an arbitrary number of vma's, we no longer
> need to assign an id (index) to each address space. So rip out the
> associated code.
>
> Signed-off-by: Rob Clark
Acked-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 7 ---
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 7 ---
> drivers/gpu/drm/msm/msm_drv.c | 16
> drivers/gpu/drm/msm/msm_drv.h | 11 ---
> drivers/gpu/drm/msm/msm_gem.h | 1 -
> drivers/gpu/drm/msm/msm_gpu.c | 2 --
> drivers/gpu/drm/msm/msm_gpu.h | 1 -
> drivers/gpu/drm/msm/msm_kms.h | 1 -
> 8 files changed, 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> index d1f572f..c29eb1f 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
> @@ -548,13 +548,6 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev)
> aspace = NULL;
> }
>
> - kms->id = msm_register_address_space(dev, aspace);
> - if (kms->id < 0) {
> - ret = kms->id;
> - dev_err(dev->dev, "failed to register mdp4 iommu: %d\n", ret);
> - goto fail;
> - }
> -
> ret = modeset_init(mdp4_kms);
> if (ret) {
> dev_err(dev->dev, "modeset_init failed: %d\n", ret);
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> index 6d9d332..438badd 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
> @@ -746,13 +746,6 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
> aspace = NULL;;
> }
>
> - kms->id = msm_register_address_space(dev, aspace);
> - if (kms->id < 0) {
> - ret = kms->id;
> - dev_err(&pdev->dev, "failed to register mdp5 iommu: %d\n", ret);
> - goto fail;
> - }
> -
> ret = modeset_init(mdp5_kms);
> if (ret) {
> dev_err(&pdev->dev, "modeset_init failed: %d\n", ret);
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index e938379..ea43816 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -51,22 +51,6 @@ static const struct drm_mode_config_funcs
> mode_config_funcs = {
> .atomic_state_free = msm_atomic_state_free,
> };
>
> -#include "msm_gem.h" /* temporary */
> -int msm_register_address_space(struct drm_device *dev,
> - struct msm_gem_address_space *aspace)
> -{
> - struct msm_drm_private *priv = dev->dev_private;
> -
> - if (WARN_ON(priv->num_aspaces >= ARRAY_SIZE(priv->aspace)))
> - return -EINVAL;
> -
> - priv->aspace[priv->num_aspaces] = aspace;
> -
> - aspace->id = priv->num_aspaces++;
> -
> - return aspace->id;
> -}
> -
> #ifdef CONFIG_DRM_MSM_REGISTER_LOGGING
> static bool reglog = false;
> MODULE_PARM_DESC(reglog, "Enable register read/write logging");
> diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
> index f3f5d6a..b48aa88 100644
> --- a/drivers/gpu/drm/msm/msm_drv.h
> +++ b/drivers/gpu/drm/msm/msm_drv.h
> @@ -123,14 +123,6 @@ struct msm_drm_private {
> uint32_t pending_crtcs;
> wait_queue_head_t pending_crtcs_event;
>
> - /* Registered address spaces.. currently this is fixed per # of
> - * iommu's. Ie. one for display block and one for gpu block.
> - * Eventually, to do per-process gpu pagetables, we'll want one
> - * of these per-process.
> - */
> - unsigned int num_aspaces;
> - struct msm_gem_address_space *aspace[NUM_DOMAINS];
> -
> unsigned int num_planes;
> struct drm_plane *planes[16];
>
> @@ -183,9 +175,6 @@ struct drm_atomic_state *msm_atomic_state_alloc(struct
> drm_device *dev);
> void msm_atomic_state_clear(struct drm_atomic_state *state);
> void msm_atomic_state_free(struct drm_atomic_state *state);
>
> -int msm_register_address_space(struct drm_device *dev,
> - struct msm_gem_address_space *aspace);
> -
> void msm_gem_unmap_vma(struct msm_gem_address_space *aspace,
> struct msm_gem_vma *vma, struct sg_table *sgt);
> int msm_gem_map_vma(struct msm_gem_address_space *aspace,
> diff --git a/drivers/gpu/drm/msm/msm_gem.h b/drivers/gpu/drm/msm/msm_gem.h
> index ff468da..112eb63 100644
> --- a/drivers/gpu/drm/msm/msm_gem.h
> +++ b/drivers/gpu/drm/msm/msm_gem.h
> @@ -33,7 +33,6 @@ struct msm_gem_address_space {
> struct drm_mm mm;
> struct msm_mmu *mmu;
> struct kref kref;
> - int id;/* temporary */
> };
>
> struct msm_gem_vma {
> diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
> index de1d22c..bc6cd9e 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.c
> +++ b/drivers/gpu/drm/msm/msm_gpu.c
> @@ -660,8 +660,6
[Bug 101368] Nouveau regression GT218M in Kernel 4.11 Won't Boot
https://bugs.freedesktop.org/show_bug.cgi?id=101368 --- Comment #6 from Ben Steel --- Created attachment 131935 --> https://bugs.freedesktop.org/attachment.cgi?id=131935&action=edit dmesg with debug=trace Thanks for your efforts. Boot with patched driver unsuccessful. Dmesg from rmmod and insmod with debug trace attached. Thanks also to Takashi Iwai for the build of the patched 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
[radeon-alex:amd-staging-4.11 1374/1377] drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:335:15: error: 'union bw_context' has no member named 'dcn'; did you mean 'dce'?
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.11 head: ee1356406141af842dcd7f689749fced30185cf4 commit: 42376247f5e6b8f95e70ae9caa8b1d799a836448 [1374/1377] drm/amd/display: add bw logging for dcn config: ia64-allmodconfig (attached as .config) compiler: ia64-linux-gcc (GCC) 6.2.0 reproduce: wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 42376247f5e6b8f95e70ae9caa8b1d799a836448 # save the attached .config to linux build tree make.cross ARCH=ia64 All errors (new ones prefixed by >>): drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c: In function 'context_clock_trace': >> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:335:15: error: >> 'union bw_context' has no member named 'dcn'; did you mean 'dce'? context->bw.dcn.calc_clk.dispclk_khz, ^ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:36:7: note: in definition of macro 'CLOCK_TRACE' ##__VA_ARGS__); \ ^~~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:336:15: error: 'union bw_context' has no member named 'dcn'; did you mean 'dce'? context->bw.dcn.calc_clk.dppclk_div, ^ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:36:7: note: in definition of macro 'CLOCK_TRACE' ##__VA_ARGS__); \ ^~~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:337:15: error: 'union bw_context' has no member named 'dcn'; did you mean 'dce'? context->bw.dcn.calc_clk.dcfclk_khz, ^ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:36:7: note: in definition of macro 'CLOCK_TRACE' ##__VA_ARGS__); \ ^~~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:338:15: error: 'union bw_context' has no member named 'dcn'; did you mean 'dce'? context->bw.dcn.calc_clk.dcfclk_deep_sleep_khz, ^ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:36:7: note: in definition of macro 'CLOCK_TRACE' ##__VA_ARGS__); \ ^~~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:339:15: error: 'union bw_context' has no member named 'dcn'; did you mean 'dce'? context->bw.dcn.calc_clk.fclk_khz, ^ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:36:7: note: in definition of macro 'CLOCK_TRACE' ##__VA_ARGS__); \ ^~~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:340:15: error: 'union bw_context' has no member named 'dcn'; did you mean 'dce'? context->bw.dcn.calc_clk.dram_ccm_us, ^ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:36:7: note: in definition of macro 'CLOCK_TRACE' ##__VA_ARGS__); \ ^~~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:341:15: error: 'union bw_context' has no member named 'dcn'; did you mean 'dce'? context->bw.dcn.calc_clk.min_active_dram_ccm_us); ^ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:36:7: note: in definition of macro 'CLOCK_TRACE' ##__VA_ARGS__); \ ^~~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:345:15: error: 'union bw_context' has no member named 'dcn'; did you mean 'dce'? context->bw.dcn.calc_clk.dispclk_khz, ^ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:36:7: note: in definition of macro 'CLOCK_TRACE' ##__VA_ARGS__); \ ^~~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:346:15: error: 'union bw_context' has no member named 'dcn'; did you mean 'dce'? context->bw.dcn.calc_clk.dppclk_div, ^ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:36:7: note: in definition of macro 'CLOCK_TRACE' ##__VA_ARGS__); \ ^~~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:347:15: error: 'union bw_context' has no member named 'dcn'; did you mean 'dce'? context->bw.dcn.calc_clk.dcfclk_khz, ^ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:36:7: note: in definition of macro 'CLOCK_TRACE' ##__VA_ARGS__); \ ^~~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:348:15: error: 'union bw_context' has no member named 'dcn'; did you mean 'dce'? context->bw.dcn.calc_clk.dcfclk_deep_sleep_khz, ^ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:36:7: note: in definition of macro 'CLOCK_TRACE' ##__VA_ARGS__); \ ^~~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.c:349:15: error: 'union bw_context' has no member named 'dcn'; did you mean 'dce'? context->bw.dcn.calc_clk.fclk_khz, ^ driv
[Bug 101368] Nouveau regression GT218M in Kernel 4.11 Won't Boot
https://bugs.freedesktop.org/show_bug.cgi?id=101368 --- Comment #7 from Ilia Mirkin --- Interesting. Dies in PMU preinit somewhere, which in turn calls nkvm_pmu_reset. I don't see an obvious reason for that to die except ... if PTIMER is somehow off? The only difference is from 1e2115d8c0c0da62405400316f5499d909e479bc which makes it so that nvkm_falcon_v1_new is now being called, although I can't imagine what would go wrong there. This will require someone who knows what they're doing to figure out ... i.e. not me. Hopefully Ben can take a look. -- 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] drm: adv7511_audio: Add .get_dai_id callback to map port number to dai id
ALSA SoC needs to know connected DAI ID for probing. Using
the new audio-card-graph approach, ports/endpoints are used
to describe how the links are connected. Unfortunately, since
ports/endpoints are used as well for video linkages, there
are some issues mixing the port ids to the two (video and
audio) namespaces.
To solve this issue, this patch adds new .get_dai_id callback
on hdmi_codec_ops.
The will assume that HDMI audio out will be connected to
reg = <2>. This will then be remapped to the ALSA SoC side will
as DAI 0. Allowing the adv7511's hdmi audio support to be used
with the audio-card-graph.
Credit to Kuninori Morimoto who's patch to dw-hdmi-i2s-audio.c
was what this was mostly copy-pasted from.
Cc: Kuninori Morimoto
Cc: Archit Taneja
Cc: Mark Brown
Cc: Rob Herring
Cc: David Airlie
Cc: Lars-Peter Clausen
Cc: Linux-ALSA
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: John Stultz
---
.../bindings/display/bridge/adi,adv7511.txt| 8
drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 22 ++
2 files changed, 30 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
index 00ea670..06668bc 100644
--- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
+++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
@@ -78,6 +78,7 @@ graph bindings specified in
Documentation/devicetree/bindings/graph.txt.
remote endpoint phandle should be a reference to a valid mipi_dsi_host device
node.
- Video port 1 for the HDMI output
+- Audio port 2 for the HDMI audio input
Example
@@ -112,5 +113,12 @@ Example
remote-endpoint = <&hdmi_connector_in>;
};
};
+
+ port@2 {
+ reg = <2>;
+ codec_endpoint: endpoint {
+ remote-endpoint = <&i2s0_cpu_endpoint>;
+ };
+ };
};
};
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
index cf92ebf..67469c2 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include "adv7511.h"
@@ -182,10 +183,31 @@ static void audio_shutdown(struct device *dev, void *data)
{
}
+static int adv7511_hdmi_i2s_get_dai_id(struct snd_soc_component *component,
+ struct device_node *endpoint)
+{
+ struct of_endpoint of_ep;
+ int ret;
+
+ ret = of_graph_parse_endpoint(endpoint, &of_ep);
+ if (ret < 0)
+ return ret;
+
+ /*
+* HDMI sound should be located as reg = <2>
+* Then, it is sound port 0
+*/
+ if (of_ep.port == 2)
+ return 0;
+
+ return -EINVAL;
+}
+
static const struct hdmi_codec_ops adv7511_codec_ops = {
.hw_params = adv7511_hdmi_hw_params,
.audio_shutdown = audio_shutdown,
.audio_startup = audio_startup,
+ .get_dai_id = adv7511_hdmi_i2s_get_dai_id,
};
static struct hdmi_codec_pdata codec_data = {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: adv7511_audio: Add .get_dai_id callback to map port number to dai id
On Tue, Jun 13, 2017 at 2:59 PM, John Stultz wrote: > ALSA SoC needs to know connected DAI ID for probing. Using > the new audio-card-graph approach, ports/endpoints are used > to describe how the links are connected. Unfortunately, since > ports/endpoints are used as well for video linkages, there > are some issues mixing the port ids to the two (video and > audio) namespaces. > > To solve this issue, this patch adds new .get_dai_id callback > on hdmi_codec_ops. > > The will assume that HDMI audio out will be connected to > reg = <2>. This will then be remapped to the ALSA SoC side will > as DAI 0. Allowing the adv7511's hdmi audio support to be used > with the audio-card-graph. > > Credit to Kuninori Morimoto who's patch to dw-hdmi-i2s-audio.c > was what this was mostly copy-pasted from. Forgot to note this has dependencies on patches in the ASoC tree in -next, so it probably should go in via that tree. thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101415] Error running clBLAS clblas-client: unsupported call to function mem_fence
https://bugs.freedesktop.org/show_bug.cgi?id=101415 Bug ID: 101415 Summary: Error running clBLAS clblas-client: unsupported call to function mem_fence Product: Mesa Version: 17.1 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: mast...@hotmail.com QA Contact: dri-devel@lists.freedesktop.org When I try to run the clblas-client from clBLAS I get an error: [miguel@antergos-mig staging]$ ./clBLAS-client Error: Failed makeGemmKernel: Creating program from source clBuildProgram Failed err = -11 Error: Failed to build program executable! Build Log: input.cl:107:5: warning: implicit declaration of function 'mem_fence' is invalid in C99 input.cl:37:3: note: expanded from macro 'MICRO_TILE' :0:0: in function sgemm_Col_NN_B1_MX016_NX016_KX16 void (float addrspace(1)*, float addrspace(1)*, float addrspace(1)*, float, float, i32, i32, i32, i32, i32, i32, i32, i32, i32): unsupported call to function mem_fence My system is antergos ARCH-Linux with configuration as follows: clinfo Number of platforms 1 Platform Name Clover Platform Vendor Mesa Platform VersionOpenCL 1.1 Mesa 17.1.2 Platform ProfileFULL_PROFILE Platform Extensions cl_khr_icd Platform Extensions function suffix MESA Platform Name Clover Number of devices 1 Device Name AMD TONGA (DRM 3.10.0 / 4.11.3-1-ARCH, LLVM 4.0.0) Device Vendor AMD Device Vendor ID0x1002 Device Version OpenCL 1.1 Mesa 17.1.2 Driver Version 17.1.2 Device OpenCL C Version OpenCL C 1.1 Device Type GPU Device AvailableYes Device Profile FULL_PROFILE Max compute units 28 Max clock frequency 990MHz Max work item dimensions3 Max work item sizes 256x256x256 Max work group size 256 Compiler Available Yes Preferred work group size multiple 64 Preferred / native vector sizes char16 / 16 short8 / 8 int 4 / 4 long 2 / 2 half 0 / 0(n/a) float4 / 4 double 2 / 2 (cl_khr_fp64) Half-precision Floating-point support (n/a) Single-precision Floating-point support (core) Denormals No Infinity and NANs Yes Round to nearest Yes Round to zero No Round to infinity No IEEE754-2008 fused multiply-add No Support is emulated in software No Correctly-rounded divide and sqrt operations No Double-precision Floating-point support (cl_khr_fp64) Denormals Yes Infinity and NANs Yes Round to nearest Yes Round to zero Yes Round to infinity Yes IEEE754-2008 fused multiply-add Yes Support is emulated in software No Correctly-rounded divide and sqrt operations No Address bits64, Little-Endian Global memory size 2145640448 (1.998GiB) Error Correction supportNo Max memory allocation 1501948313 (1.399GiB) Unified memory for Host and Device Yes Minimum alignment for any data type 128 bytes Alignment of base address 1024 bits (128 bytes) Global Memory cache typeNone Image support No Local memory type Local Local memory size
[radeon-alex:raven 340/1060] drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:556:16: note: in expansion of macro 'do_div'
tree: git://people.freedesktop.org/~agd5f/linux.git raven
head: c6ee08eda872bc7ac60ed0ba82a5d85e696a894c
commit: a1146cea5877c42e10858082cf9018fd63165a92 [340/1060] drm/amdgpu: handle
CPU access for split VRAM buffers (v2)
config: parisc-allyesconfig (attached as .config)
compiler: hppa-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout a1146cea5877c42e10858082cf9018fd63165a92
# save the attached .config to linux build tree
make.cross ARCH=parisc
All error/warnings (new ones prefixed by >>):
In file included from ./arch/parisc/include/generated/asm/div64.h:1:0,
from include/linux/kernel.h:149,
from include/linux/list.h:8,
from include/drm/drm_hashtab.h:38,
from include/drm/ttm/ttm_bo_api.h:34,
from drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:32:
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c: In function 'amdgpu_ttm_io_mem_pfn':
include/asm-generic/div64.h:207:28: warning: comparison of distinct pointer
types lacks a cast
(void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
^
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:556:16: note: in expansion of macro
>> 'do_div'
page_offset = do_div(offset, size);
^~
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/drm/drm_hashtab.h:38,
from include/drm/ttm/ttm_bo_api.h:34,
from drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:32:
include/asm-generic/div64.h:220:25: warning: right shift count >= width of
type [-Wshift-count-overflow]
} else if (likely(((n) >> 32) == 0)) { \
^
include/linux/compiler.h:178:40: note: in definition of macro 'likely'
# define likely(x) __builtin_expect(!!(x), 1)
^
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:556:16: note: in expansion of macro
>> 'do_div'
page_offset = do_div(offset, size);
^~
In file included from ./arch/parisc/include/generated/asm/div64.h:1:0,
from include/linux/kernel.h:149,
from include/linux/list.h:8,
from include/drm/drm_hashtab.h:38,
from include/drm/ttm/ttm_bo_api.h:34,
from drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:32:
>> include/asm-generic/div64.h:224:22: error: passing argument 1 of
>> '__div64_32' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
__rem = __div64_32(&(n), __base); \
^
>> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:556:16: note: in expansion of macro
>> 'do_div'
page_offset = do_div(offset, size);
^~
include/asm-generic/div64.h:198:17: note: expected 'uint64_t * {aka long
long unsigned int *}' but argument is of type 'long unsigned int *'
extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor);
^~
cc1: some warnings being treated as errors
--
In file included from ./arch/parisc/include/generated/asm/div64.h:1:0,
from include/linux/kernel.h:149,
from include/linux/list.h:8,
from include/drm/drm_hashtab.h:38,
from include/drm/ttm/ttm_bo_api.h:34,
from drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c:32:
drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c: In function
'amdgpu_ttm_io_mem_pfn':
include/asm-generic/div64.h:207:28: warning: comparison of distinct pointer
types lacks a cast
(void)(((typeof((n)) *)0) == ((uint64_t *)0)); \
^
drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c:556:16: note: in expansion of macro
'do_div'
page_offset = do_div(offset, size);
^~
In file included from include/uapi/linux/stddef.h:1:0,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/linux/list.h:4,
from include/drm/drm_hashtab.h:38,
from include/drm/ttm/ttm_bo_api.h:34,
from drivers/gpu//drm/amd/amdgpu/amdgpu_ttm.c:32:
include/asm-generic/div64.h:220:25: warning: right shift count >= width of
type [-Wshift-count-overflow]
} else if (likely(((n) >> 32) == 0)) { \
Re: [PATCH] drm/msm: Separate locking of buffer resources from struct_mutex
On Tue, Jun 13, 2017 at 6:52 PM, Sushmita Susheelendra
wrote:
> Buffer object specific resources like pages, domains, sg list
> need not be protected with struct_mutex. They can be protected
> with a buffer object level lock. This simplifies locking and
> makes it easier to avoid potential recursive locking scenarios
> for SVM involving mmap_sem and struct_mutex. This also removes
> unnecessary serialization when creating buffer objects, and also
> between buffer object creation and GPU command submission.
oh, cool.. this might be a bit conflicty w/ "drm/msm: fix locking
inconsistency for gpu->hw_init()" and possibly the patchset to support
arbitrary # of vma's per gem bo. But it is definitely the direction
we want to go. It should also help us move away from the
mutex_trylock_recursive() hack in the shrinker code.
I'll have a go at rebasing it, and in the process taking a closer
look, tomorrow since this is something that has been on the TODO list
for quite a while now and is pretty badly needed.
BR,
-R
> Change-Id: I4fba9f8c38a6cd13f80f660639d1e74d4336e3fb
> Signed-off-by: Sushmita Susheelendra
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c| 2 -
> drivers/gpu/drm/msm/adreno/a5xx_power.c | 2 -
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 -
> drivers/gpu/drm/msm/dsi/dsi_host.c | 5 +-
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 2 +-
> drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c | 2 -
> drivers/gpu/drm/msm/msm_drv.c| 1 +
> drivers/gpu/drm/msm/msm_drv.h| 7 +-
> drivers/gpu/drm/msm/msm_fbdev.c | 6 +-
> drivers/gpu/drm/msm/msm_gem.c| 190
> +++
> drivers/gpu/drm/msm/msm_gem.h| 2 +
> drivers/gpu/drm/msm/msm_gem_submit.c | 6 +-
> drivers/gpu/drm/msm/msm_gem_vma.c| 10 +-
> drivers/gpu/drm/msm/msm_gpu.c| 4 +-
> drivers/gpu/drm/msm/msm_rd.c | 4 +-
> drivers/gpu/drm/msm/msm_ringbuffer.c | 2 +-
> 16 files changed, 120 insertions(+), 127 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> index 31a9bce..7893de1 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
> @@ -235,9 +235,7 @@ static struct drm_gem_object *a5xx_ucode_load_bo(struct
> msm_gpu *gpu,
> struct drm_gem_object *bo;
> void *ptr;
>
> - mutex_lock(&drm->struct_mutex);
> bo = msm_gem_new(drm, fw->size - 4, MSM_BO_UNCACHED);
> - mutex_unlock(&drm->struct_mutex);
>
> if (IS_ERR(bo))
> return bo;
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_power.c
> b/drivers/gpu/drm/msm/adreno/a5xx_power.c
> index 72d52c7..eb88f44 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_power.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_power.c
> @@ -294,9 +294,7 @@ void a5xx_gpmu_ucode_init(struct msm_gpu *gpu)
> */
> bosize = (cmds_size + (cmds_size / TYPE4_MAX_PAYLOAD) + 1) << 2;
>
> - mutex_lock(&drm->struct_mutex);
> a5xx_gpu->gpmu_bo = msm_gem_new(drm, bosize, MSM_BO_UNCACHED);
> - mutex_unlock(&drm->struct_mutex);
>
> if (IS_ERR(a5xx_gpu->gpmu_bo))
> goto err;
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 5b63fc6..1162c15 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -392,10 +392,8 @@ int adreno_gpu_init(struct drm_device *drm, struct
> platform_device *pdev,
> return ret;
> }
>
> - mutex_lock(&drm->struct_mutex);
> adreno_gpu->memptrs_bo = msm_gem_new(drm,
> sizeof(*adreno_gpu->memptrs),
> MSM_BO_UNCACHED);
> - mutex_unlock(&drm->struct_mutex);
> if (IS_ERR(adreno_gpu->memptrs_bo)) {
> ret = PTR_ERR(adreno_gpu->memptrs_bo);
> adreno_gpu->memptrs_bo = NULL;
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 4f79b10..6a1b0da 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -980,19 +980,16 @@ static int dsi_tx_buf_alloc(struct msm_dsi_host
> *msm_host, int size)
> uint64_t iova;
>
> if (cfg_hnd->major == MSM_DSI_VER_MAJOR_6G) {
> - mutex_lock(&dev->struct_mutex);
> msm_host->tx_gem_obj = msm_gem_new(dev, size,
> MSM_BO_UNCACHED);
> if (IS_ERR(msm_host->tx_gem_obj)) {
> ret = PTR_ERR(msm_host->tx_gem_obj);
> pr_err("%s: failed to allocate gem, %d\n",
> __func__, ret);
> msm_host->tx_gem_obj = NULL;
> - mutex_unlock(&dev->struct_mutex);
> return ret;
> }
>
> - ret = msm_gem_get_iova_locked(msm_hos
[Bug 101368] Nouveau regression GT218M in Kernel 4.11 Won't Boot
https://bugs.freedesktop.org/show_bug.cgi?id=101368 Ilia Mirkin changed: What|Removed |Added QA Contact||xorg-t...@lists.x.org Product|DRI |xorg Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o |.org|rg Component|DRM/other |Driver/nouveau -- 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] drm: adv7511_audio: Add .get_dai_id callback to map port number to dai id
On Tue, Jun 13, 2017 at 02:59:49PM -0700, John Stultz wrote: > ALSA SoC needs to know connected DAI ID for probing. Using > the new audio-card-graph approach, ports/endpoints are used > to describe how the links are connected. Unfortunately, since Unless someone objects in the next week or so I intend to apply this. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 07/22] drm/tegra: dc: Apply clipping to the plane
On Tegra20 an overlay plane should be clipped, otherwise its output is
distorted once plane crosses display boundary.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 98ee6abb056c..a7a7cce1afd0 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -486,12 +486,25 @@ static int tegra_plane_state_add(struct tegra_plane
*plane,
{
struct drm_crtc_state *crtc_state;
struct tegra_dc_state *tegra;
+ struct drm_rect clip;
+ int err;
/* Propagate errors from allocation or locking failures. */
crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
if (IS_ERR(crtc_state))
return PTR_ERR(crtc_state);
+ clip.x1 = 0;
+ clip.y1 = 0;
+ clip.x2 = crtc_state->mode.hdisplay;
+ clip.y2 = crtc_state->mode.vdisplay;
+
+ /* Check plane state for visibility and calculate clipping bounds */
+ err = drm_plane_helper_check_state(state, &clip, 0, INT_MAX,
+ true, true);
+ if (err < 0)
+ return err;
+
tegra = to_dc_state(crtc_state);
tegra->planes |= WIN_A_ACT_REQ << plane->index;
@@ -561,14 +574,14 @@ static void tegra_plane_atomic_update(struct drm_plane
*plane,
return;
memset(&window, 0, sizeof(window));
- window.src.x = plane->state->src_x >> 16;
- window.src.y = plane->state->src_y >> 16;
- window.src.w = plane->state->src_w >> 16;
- window.src.h = plane->state->src_h >> 16;
- window.dst.x = plane->state->crtc_x;
- window.dst.y = plane->state->crtc_y;
- window.dst.w = plane->state->crtc_w;
- window.dst.h = plane->state->crtc_h;
+ window.src.x = plane->state->src.x1 >> 16;
+ window.src.y = plane->state->src.y1 >> 16;
+ window.src.w = drm_rect_width(&plane->state->src) >> 16;
+ window.src.h = drm_rect_height(&plane->state->src) >> 16;
+ window.dst.x = plane->state->dst.x1;
+ window.dst.y = plane->state->dst.y1;
+ window.dst.w = drm_rect_width(&plane->state->dst);
+ window.dst.h = drm_rect_height(&plane->state->dst);
window.bits_per_pixel = fb->format->cpp[0] * 8;
window.bottom_up = tegra_fb_is_bottom_up(fb);
--
2.13.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/22] gpu: host1x: Do not leak BO's phys address to userspace
On 13.06.2017 20:31, Mikko Perttunen wrote:
> On 05/23/2017 03:14 AM, Dmitry Osipenko wrote:
>> Do gathers coping before patching them, so the original gathers are left
>> untouched. That's not as bad as leaking a kernel addresses, but still
>> doesn't feel right.
>>
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/gpu/host1x/job.c | 44 ++--
>> 1 file changed, 30 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
>> index 14f3f957ffab..190353944d23 100644
>> --- a/drivers/gpu/host1x/job.c
>> +++ b/drivers/gpu/host1x/job.c
>> @@ -137,8 +137,9 @@ static void host1x_syncpt_patch_offset(struct
>> host1x_syncpt *sp,
>>* avoid a wrap condition in the HW).
>>*/
>> static int do_waitchks(struct host1x_job *job, struct host1x *host,
>> - struct host1x_bo *patch)
>> + struct host1x_job_gather *g)
>> {
>> +struct host1x_bo *patch = g->bo;
>> int i;
>> /* compare syncpt vs wait threshold */
>> @@ -165,7 +166,8 @@ static int do_waitchks(struct host1x_job *job, struct
>> host1x *host,
>> wait->syncpt_id, sp->name, wait->thresh,
>> host1x_syncpt_read_min(sp));
>> -host1x_syncpt_patch_offset(sp, patch, wait->offset);
>> +host1x_syncpt_patch_offset(sp, patch,
>> + g->offset + wait->offset);
>> }
>> wait->bo = NULL;
>> @@ -269,11 +271,12 @@ static unsigned int pin_job(struct host1x *host, struct
>> host1x_job *job)
>> return err;
>> }
>> -static int do_relocs(struct host1x_job *job, struct host1x_bo *cmdbuf)
>> +static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
>> {
>> int i = 0;
>> u32 last_page = ~0;
>> void *cmdbuf_page_addr = NULL;
>> +struct host1x_bo *cmdbuf = g->bo;
>> /* pin & patch the relocs for one gather */
>> for (i = 0; i < job->num_relocs; i++) {
>> @@ -286,7 +289,8 @@ static int do_relocs(struct host1x_job *job, struct
>> host1x_bo *cmdbuf)
>> if (cmdbuf != reloc->cmdbuf.bo)
>> continue;
>> -if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
>> +if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) &&
>> +last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
>> if (cmdbuf_page_addr)
>> host1x_bo_kunmap(cmdbuf, last_page,
>>cmdbuf_page_addr);
>> @@ -301,11 +305,20 @@ static int do_relocs(struct host1x_job *job, struct
>> host1x_bo *cmdbuf)
>> }
>> }
>> +if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL)) {
>> +cmdbuf_page_addr = job->gather_copy_mapped;
>> +cmdbuf_page_addr += g->offset;
>> +}
>> +
>> target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
>> +
>> +if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL))
>> +target += (reloc->cmdbuf.offset & PAGE_MASK) >> 2;
>> +
>> *target = reloc_addr;
>
> I think this logic would be cleaner like ..
>
> if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL)) {
> target = job->gather_copy_mapped + g->offset + reloc->cmdbuf.offset;
> ...
> } else {
> if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
> ...
> }
> target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
> }
> *target = reloc_addr
>
What about this variant?
-static int do_relocs(struct host1x_job *job, struct host1x_bo *cmdbuf)
+static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
{
int i = 0;
u32 last_page = ~0;
void *cmdbuf_page_addr = NULL;
+ struct host1x_bo *cmdbuf = g->bo;
/* pin & patch the relocs for one gather */
for (i = 0; i < job->num_relocs; i++) {
@@ -286,6 +289,12 @@ static int do_relocs(struct host1x_job *job, struct
host1x_bo *cmdbuf)
if (cmdbuf != reloc->cmdbuf.bo)
continue;
+ if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL)) {
+ cmdbuf_page_addr = job->gather_copy_mapped + g->offset;
+ target = cmdbuf_page_addr + reloc->cmdbuf.offset;
+ goto patch_reloc;
+ }
+
if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
if (cmdbuf_page_addr)
host1x_bo_kunmap(cmdbuf, last_page,
@@ -302,10 +311,11 @@ static int do_relocs(struct host1x_job *job, struct
host1x_bo *cmdbuf)
}
target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
+patch_reloc:
*target = reloc_addr;
}
- if (cmdbuf_page_addr)
+ if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && cmdbuf_page_addr)
host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
return 0;
>> }
>> -if (cmdbuf_page_addr)
[PATCH v2 06/22] drm/tegra: dc: Avoid reset asserts on Tegra20
Commit 33a8eb8 ("Implement runtime PM") introduced HW reset control. It
causes a hang on Tegra20 if both display controllers are utilized (RGB
panel and HDMI). The TRM suggests that each display controller has its own
reset control, apparently it is not correct.
Fixes: 33a8eb8d40ee ("drm/tegra: dc: Implement runtime PM")
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/dc.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 95b373f739f2..98ee6abb056c 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -30,6 +30,7 @@ struct tegra_dc_soc_info {
bool supports_block_linear;
unsigned int pitch_align;
bool has_powergate;
+ bool broken_reset;
};
struct tegra_plane {
@@ -1856,6 +1857,7 @@ static const struct tegra_dc_soc_info tegra20_dc_soc_info
= {
.supports_block_linear = false,
.pitch_align = 8,
.has_powergate = false,
+ .broken_reset = true,
};
static const struct tegra_dc_soc_info tegra30_dc_soc_info = {
@@ -1865,6 +1867,7 @@ static const struct tegra_dc_soc_info tegra30_dc_soc_info
= {
.supports_block_linear = false,
.pitch_align = 8,
.has_powergate = false,
+ .broken_reset = false,
};
static const struct tegra_dc_soc_info tegra114_dc_soc_info = {
@@ -1874,6 +1877,7 @@ static const struct tegra_dc_soc_info
tegra114_dc_soc_info = {
.supports_block_linear = false,
.pitch_align = 64,
.has_powergate = true,
+ .broken_reset = false,
};
static const struct tegra_dc_soc_info tegra124_dc_soc_info = {
@@ -1883,6 +1887,7 @@ static const struct tegra_dc_soc_info
tegra124_dc_soc_info = {
.supports_block_linear = true,
.pitch_align = 64,
.has_powergate = true,
+ .broken_reset = false,
};
static const struct tegra_dc_soc_info tegra210_dc_soc_info = {
@@ -1892,6 +1897,7 @@ static const struct tegra_dc_soc_info
tegra210_dc_soc_info = {
.supports_block_linear = true,
.pitch_align = 64,
.has_powergate = true,
+ .broken_reset = false,
};
static const struct of_device_id tegra_dc_of_match[] = {
@@ -1989,7 +1995,8 @@ static int tegra_dc_probe(struct platform_device *pdev)
return PTR_ERR(dc->rst);
}
- reset_control_assert(dc->rst);
+ if (!dc->soc->broken_reset)
+ reset_control_assert(dc->rst);
if (dc->soc->has_powergate) {
if (dc->pipe == 0)
@@ -2063,10 +2070,12 @@ static int tegra_dc_suspend(struct device *dev)
struct tegra_dc *dc = dev_get_drvdata(dev);
int err;
- err = reset_control_assert(dc->rst);
- if (err < 0) {
- dev_err(dev, "failed to assert reset: %d\n", err);
- return err;
+ if (!dc->soc->broken_reset) {
+ err = reset_control_assert(dc->rst);
+ if (err < 0) {
+ dev_err(dev, "failed to assert reset: %d\n", err);
+ return err;
+ }
}
if (dc->soc->has_powergate)
@@ -2096,10 +2105,13 @@ static int tegra_dc_resume(struct device *dev)
return err;
}
- err = reset_control_deassert(dc->rst);
- if (err < 0) {
- dev_err(dev, "failed to deassert reset: %d\n", err);
- return err;
+ if (!dc->soc->broken_reset) {
+ err = reset_control_deassert(dc->rst);
+ if (err < 0) {
+ dev_err(dev,
+ "failed to deassert reset: %d\n", err);
+ return err;
+ }
}
}
--
2.13.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 13/22] gpu: host1x: Do not leak BO's phys address to userspace
Perform gathers coping before patching them, so that original gathers are
left untouched. That's not as bad as leaking kernel addresses, but still
doesn't feel right.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Mikko Perttunen
---
drivers/gpu/host1x/job.c | 39 +++
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 14f3f957ffab..4208329ca2af 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -137,8 +137,9 @@ static void host1x_syncpt_patch_offset(struct host1x_syncpt
*sp,
* avoid a wrap condition in the HW).
*/
static int do_waitchks(struct host1x_job *job, struct host1x *host,
- struct host1x_bo *patch)
+ struct host1x_job_gather *g)
{
+ struct host1x_bo *patch = g->bo;
int i;
/* compare syncpt vs wait threshold */
@@ -165,7 +166,8 @@ static int do_waitchks(struct host1x_job *job, struct
host1x *host,
wait->syncpt_id, sp->name, wait->thresh,
host1x_syncpt_read_min(sp));
- host1x_syncpt_patch_offset(sp, patch, wait->offset);
+ host1x_syncpt_patch_offset(sp, patch,
+ g->offset + wait->offset);
}
wait->bo = NULL;
@@ -269,11 +271,12 @@ static unsigned int pin_job(struct host1x *host, struct
host1x_job *job)
return err;
}
-static int do_relocs(struct host1x_job *job, struct host1x_bo *cmdbuf)
+static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
{
int i = 0;
u32 last_page = ~0;
void *cmdbuf_page_addr = NULL;
+ struct host1x_bo *cmdbuf = g->bo;
/* pin & patch the relocs for one gather */
for (i = 0; i < job->num_relocs; i++) {
@@ -286,6 +289,13 @@ static int do_relocs(struct host1x_job *job, struct
host1x_bo *cmdbuf)
if (cmdbuf != reloc->cmdbuf.bo)
continue;
+ if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL)) {
+ target = (u32 *)job->gather_copy_mapped +
+ reloc->cmdbuf.offset / sizeof(u32) +
+ g->offset / sizeof(u32);
+ goto patch_reloc;
+ }
+
if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
if (cmdbuf_page_addr)
host1x_bo_kunmap(cmdbuf, last_page,
@@ -302,6 +312,7 @@ static int do_relocs(struct host1x_job *job, struct
host1x_bo *cmdbuf)
}
target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
+patch_reloc:
*target = reloc_addr;
}
@@ -573,6 +584,12 @@ int host1x_job_pin(struct host1x_job *job, struct device
*dev)
if (err)
goto out;
+ if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL)) {
+ err = copy_gathers(job, dev);
+ if (err)
+ goto out;
+ }
+
/* patch gathers */
for (i = 0; i < job->num_gathers; i++) {
struct host1x_job_gather *g = &job->gathers[i];
@@ -581,7 +598,9 @@ int host1x_job_pin(struct host1x_job *job, struct device
*dev)
if (g->handled)
continue;
- g->base = job->gather_addr_phys[i];
+ /* copy_gathers() sets gathers base if firewall is enabled */
+ if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL))
+ g->base = job->gather_addr_phys[i];
for (j = i + 1; j < job->num_gathers; j++) {
if (job->gathers[j].bo == g->bo) {
@@ -590,19 +609,15 @@ int host1x_job_pin(struct host1x_job *job, struct device
*dev)
}
}
- err = do_relocs(job, g->bo);
+ err = do_relocs(job, g);
if (err)
- goto out;
+ break;
- err = do_waitchks(job, host, g->bo);
+ err = do_waitchks(job, host, g);
if (err)
- goto out;
+ break;
}
- if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL))
- goto out;
-
- err = copy_gathers(job, dev);
out:
if (err)
host1x_job_unpin(job);
--
2.13.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 19/22] gpu: host1x: Remove unused 'struct host1x_cmdbuf'
The struct host1x_cmdbuf is unused, let's remove it.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Erik Faye-Lund
Reviewed-by: Mikko Perttunen
---
drivers/gpu/host1x/job.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/host1x/job.h b/drivers/gpu/host1x/job.h
index 0debd93a1849..4bda51d503ec 100644
--- a/drivers/gpu/host1x/job.h
+++ b/drivers/gpu/host1x/job.h
@@ -27,13 +27,6 @@ struct host1x_job_gather {
bool handled;
};
-struct host1x_cmdbuf {
- u32 handle;
- u32 offset;
- u32 words;
- u32 pad;
-};
-
struct host1x_job_unpin_data {
struct host1x_bo *bo;
struct sg_table *sgt;
--
2.13.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 15/22] gpu: host1x: Forbid RESTART opcode in the firewall
The RESTART opcode terminates the gather and restarts the CDMA fetching from a specified word << 2 relative to the CDMA start address. That shouldn't be allowed to be done by userspace. Signed-off-by: Dmitry Osipenko Reviewed-by: Erik Faye-Lund Reviewed-by: Mikko Perttunen --- drivers/gpu/host1x/job.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c index 7825643da324..3680b4b7dce9 100644 --- a/drivers/gpu/host1x/job.c +++ b/drivers/gpu/host1x/job.c @@ -515,7 +515,6 @@ static int validate(struct host1x_firewall *fw, struct host1x_job_gather *g) goto out; break; case 4: - case 5: case 14: break; default: -- 2.13.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/22] gpu: host1x: Do not leak BO's phys address to userspace
On 13.06.2017 22:03, Mikko Perttunen wrote:
>
>
> On 06/13/2017 09:21 PM, Dmitry Osipenko wrote:
>> On 13.06.2017 20:31, Mikko Perttunen wrote:
>>> On 05/23/2017 03:14 AM, Dmitry Osipenko wrote:
Do gathers coping before patching them, so the original gathers are left
untouched. That's not as bad as leaking a kernel addresses, but still
doesn't feel right.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/host1x/job.c | 44
++--
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 14f3f957ffab..190353944d23 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -137,8 +137,9 @@ static void host1x_syncpt_patch_offset(struct
host1x_syncpt *sp,
* avoid a wrap condition in the HW).
*/
static int do_waitchks(struct host1x_job *job, struct host1x *host,
- struct host1x_bo *patch)
+ struct host1x_job_gather *g)
{
+struct host1x_bo *patch = g->bo;
int i;
/* compare syncpt vs wait threshold */
@@ -165,7 +166,8 @@ static int do_waitchks(struct host1x_job *job, struct
host1x *host,
wait->syncpt_id, sp->name, wait->thresh,
host1x_syncpt_read_min(sp));
-host1x_syncpt_patch_offset(sp, patch, wait->offset);
+host1x_syncpt_patch_offset(sp, patch,
+ g->offset + wait->offset);
}
wait->bo = NULL;
@@ -269,11 +271,12 @@ static unsigned int pin_job(struct host1x *host,
struct
host1x_job *job)
return err;
}
-static int do_relocs(struct host1x_job *job, struct host1x_bo *cmdbuf)
+static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
{
int i = 0;
u32 last_page = ~0;
void *cmdbuf_page_addr = NULL;
+struct host1x_bo *cmdbuf = g->bo;
/* pin & patch the relocs for one gather */
for (i = 0; i < job->num_relocs; i++) {
@@ -286,7 +289,8 @@ static int do_relocs(struct host1x_job *job, struct
host1x_bo *cmdbuf)
if (cmdbuf != reloc->cmdbuf.bo)
continue;
-if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
+if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) &&
+last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
if (cmdbuf_page_addr)
host1x_bo_kunmap(cmdbuf, last_page,
cmdbuf_page_addr);
@@ -301,11 +305,20 @@ static int do_relocs(struct host1x_job *job, struct
host1x_bo *cmdbuf)
}
}
+if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL)) {
+cmdbuf_page_addr = job->gather_copy_mapped;
+cmdbuf_page_addr += g->offset;
+}
+
target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
+
+if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL))
+target += (reloc->cmdbuf.offset & PAGE_MASK) >> 2;
+
*target = reloc_addr;
>>>
>>> I think this logic would be cleaner like ..
>>>
>>> if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL)) {
>>>target = job->gather_copy_mapped + g->offset + reloc->cmdbuf.offset;
>>>...
>>> } else {
>>>if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
>>> ...
>>>}
>>>target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
>>> }
>>> *target = reloc_addr
>>>
>>
>> What about this variant?
>>
>> -static int do_relocs(struct host1x_job *job, struct host1x_bo *cmdbuf)
>> +static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
>> {
>> int i = 0;
>> u32 last_page = ~0;
>> void *cmdbuf_page_addr = NULL;
>> +struct host1x_bo *cmdbuf = g->bo;
>>
>> /* pin & patch the relocs for one gather */
>> for (i = 0; i < job->num_relocs; i++) {
>> @@ -286,6 +289,12 @@ static int do_relocs(struct host1x_job *job, struct
>> host1x_bo *cmdbuf)
>> if (cmdbuf != reloc->cmdbuf.bo)
>> continue;
>>
>> +if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL)) {
>> +cmdbuf_page_addr = job->gather_copy_mapped + g->offset;
>
> This no longer represents the address of a page, so I think it would be better
> to just assign the final value to target.
>
>> +target = cmdbuf_page_addr + reloc->cmdbuf.offset;
>> +goto patch_reloc;
>> +}
>> +
>> if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
>> if (cmdbuf_page_addr)
>> host1x_bo_kunmap(cmdbuf, last_page,
>> @@ -302,10 +311,11 @@ static int do_relocs(struct host1x_job *job,
Re: [PATCH 13/22] gpu: host1x: Do not leak BO's phys address to userspace
On 06/13/2017 09:21 PM, Dmitry Osipenko wrote:
On 13.06.2017 20:31, Mikko Perttunen wrote:
On 05/23/2017 03:14 AM, Dmitry Osipenko wrote:
Do gathers coping before patching them, so the original gathers are left
untouched. That's not as bad as leaking a kernel addresses, but still
doesn't feel right.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/host1x/job.c | 44 ++--
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 14f3f957ffab..190353944d23 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -137,8 +137,9 @@ static void host1x_syncpt_patch_offset(struct
host1x_syncpt *sp,
* avoid a wrap condition in the HW).
*/
static int do_waitchks(struct host1x_job *job, struct host1x *host,
- struct host1x_bo *patch)
+ struct host1x_job_gather *g)
{
+struct host1x_bo *patch = g->bo;
int i;
/* compare syncpt vs wait threshold */
@@ -165,7 +166,8 @@ static int do_waitchks(struct host1x_job *job, struct
host1x *host,
wait->syncpt_id, sp->name, wait->thresh,
host1x_syncpt_read_min(sp));
-host1x_syncpt_patch_offset(sp, patch, wait->offset);
+host1x_syncpt_patch_offset(sp, patch,
+ g->offset + wait->offset);
}
wait->bo = NULL;
@@ -269,11 +271,12 @@ static unsigned int pin_job(struct host1x *host, struct
host1x_job *job)
return err;
}
-static int do_relocs(struct host1x_job *job, struct host1x_bo *cmdbuf)
+static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
{
int i = 0;
u32 last_page = ~0;
void *cmdbuf_page_addr = NULL;
+struct host1x_bo *cmdbuf = g->bo;
/* pin & patch the relocs for one gather */
for (i = 0; i < job->num_relocs; i++) {
@@ -286,7 +289,8 @@ static int do_relocs(struct host1x_job *job, struct
host1x_bo *cmdbuf)
if (cmdbuf != reloc->cmdbuf.bo)
continue;
-if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
+if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) &&
+last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
if (cmdbuf_page_addr)
host1x_bo_kunmap(cmdbuf, last_page,
cmdbuf_page_addr);
@@ -301,11 +305,20 @@ static int do_relocs(struct host1x_job *job, struct
host1x_bo *cmdbuf)
}
}
+if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL)) {
+cmdbuf_page_addr = job->gather_copy_mapped;
+cmdbuf_page_addr += g->offset;
+}
+
target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
+
+if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL))
+target += (reloc->cmdbuf.offset & PAGE_MASK) >> 2;
+
*target = reloc_addr;
I think this logic would be cleaner like ..
if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL)) {
target = job->gather_copy_mapped + g->offset + reloc->cmdbuf.offset;
...
} else {
if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
...
}
target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
}
*target = reloc_addr
What about this variant?
-static int do_relocs(struct host1x_job *job, struct host1x_bo *cmdbuf)
+static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
{
int i = 0;
u32 last_page = ~0;
void *cmdbuf_page_addr = NULL;
+ struct host1x_bo *cmdbuf = g->bo;
/* pin & patch the relocs for one gather */
for (i = 0; i < job->num_relocs; i++) {
@@ -286,6 +289,12 @@ static int do_relocs(struct host1x_job *job, struct
host1x_bo *cmdbuf)
if (cmdbuf != reloc->cmdbuf.bo)
continue;
+ if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL)) {
+ cmdbuf_page_addr = job->gather_copy_mapped + g->offset;
This no longer represents the address of a page, so I think it would be
better to just assign the final value to target.
+ target = cmdbuf_page_addr + reloc->cmdbuf.offset;
+ goto patch_reloc;
+ }
+
if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
if (cmdbuf_page_addr)
host1x_bo_kunmap(cmdbuf, last_page,
@@ -302,10 +311,11 @@ static int do_relocs(struct host1x_job *job, struct
host1x_bo *cmdbuf)
}
target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
+patch_reloc:
*target = reloc_addr;
}
- if (cmdbuf_page_addr)
+ if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && cmdbuf_page_addr)
And then we wouldn't need the IS_ENABLED here
host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
return 0;
with that
Re: [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging
12.06.2017 18:03, Greg Kroah-Hartman wrote: > On Mon, Jun 12, 2017 at 05:40:21PM +0200, Hans de Goede wrote: >> Hi, >> >> On 12-06-17 13:44, Greg Kroah-Hartman wrote: >>> On Mon, Jun 12, 2017 at 12:07:41PM +0200, Hans de Goede wrote: > The most important thing is for the driver to be atomic if it's KMS > only, and it would be good to have someone review that properly. I believe it does not use the atomic APIs atm, so that would be one of the first things to fix then. Another question is if people (you and Daniel at least) can live with the non kernel-coding style shared files under the osindependent dir ? >>> >>> Why not just spend a few days and fix up all of the kernel-style issues >>> so it can be a "real" driver? It shouldn't take all that long, >>> especially for someone with Linux kernel experience (hint, hint...) >> >> The intention of the stuff below the osindepedent dir is for it to >> be shared 1:1 between vboxvideo driver implementations for different >> operating-systems. IIRC during the AMD DAL discussion Daniel indicated >> that some OS independent code was fine (and would be exempt from coding >> style rules) as long as it had a reasonable clean interface and was not >> re-implementing anything we already have in the kernel. > > In a quick glance at the code in there, there's lots of reimplementing > happening :( > > Maybe keep the data structures around, but really, you write those once, > and then that's it, they should never change, so it shouldn't matter > what format they are in. > >> If Daniel's verdict is that this needs to be cleaned up, then sure I >> can easily do that. As mentioned I already did a lot of cleanup, >> including moving all the other files to the kernel coding-style and >> removing about 43000 lines of portability cruft / abstraction layers, >> what is left under the osindependent directory is just C-structure >> definitions and a few small plain C helper functions, which VirtualBox >> upstream would like to keep as is... > > wrappers for simple things should not be needed at all, come on, you > know that. We don't like driver-specific malloc/free and in/out > functions, or asserts, or other crap like that. This implies that this > driver is an island in itself and somehow more "important" than the 12+ > million other lines of code that it lives within. Which isn't true. > > Just clean it up, that will make it even smaller, which in the end, is > what really matters, as that will make it easier to maintain, fix, port > to new apis, and everything else. > > There's a good reason why we don't have "os abstraction" layers in > drivers in Linux, please don't ignore our history and knowledge here for > no good reason. I would appreciate getting Dave and/or Daniel's feedback here, if they have time. In particular, they might have ideas about how to further reduce the abstraction surface. In the end, the greater the difference between the code in the kernel, the harder it is for people to pull changes from our code to the kernel, and most of the changes in that part are likely to come from our side. I don't think that converting non-Linux-specific code in our tree to kernel style would go down well in our team, so if the code as is is not acceptable, the next question is, what would be? If we can come up with something which is alright for both modulo a sed script that would still make people's lives somewhat easier (though just the different brace style throws a bit of a spanner in that). Please be clear, I am not trying to dictate to anyone. The code is GPL, it is fine to include it with whatever modifications you deem appropriate. Since individual distributions are already doing that, it will still simplify our life somewhat if it is in the upstream kernel, in whatever form, rather than in multiple forks. > Remember, this code needs us, we don't need this code at all :) I assume that that was not meant that way, but that came over as slightly unfriendly to me. I am assuming here that we are looking for the best way to do something which will be useful to a lot of people. Regards Michael > good luck! > > greg k-h > -- Michael Thayer | VirtualBox engineer ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 17/22] gpu: host1x: Correct swapped arguments in the is_addr_reg() definition
Arguments of the .is_addr_reg() are swapped in the definition of the
function, that is quite confusing.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Erik Faye-Lund
Reviewed-by: Mikko Perttunen
---
include/linux/host1x.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index 71a34774b56a..561d6bb6580d 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -233,7 +233,7 @@ struct host1x_job {
u8 *gather_copy_mapped;
/* Check if register is marked as an address reg */
- int (*is_addr_reg)(struct device *dev, u32 reg, u32 class);
+ int (*is_addr_reg)(struct device *dev, u32 class, u32 reg);
/* Check if class belongs to the unit */
int (*is_valid_class)(u32 class);
--
2.13.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/mgag200: Fix to always set HiPri for G200e4
From: Mathieu Larouche
- Changed the HiPri value for G200e4 to always be 0.
- Added Bandwith limitation to block resolution above 1920x1200x60Hz
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 6b21cb2..292e8eb 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1133,7 +1133,10 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
if (IS_G200_SE(mdev)) {
- if (mdev->unique_rev_id >= 0x02) {
+ if (mdev->unique_rev_id >= 0x04) {
+ WREG8(MGAREG_CRTCEXT_INDEX, 0x06);
+ WREG8(MGAREG_CRTCEXT_DATA, 0);
+ } else if (mdev->unique_rev_id >= 0x02) {
u8 hi_pri_lvl;
u32 bpp;
u32 mb;
@@ -1598,6 +1601,10 @@ static int mga_vga_mode_valid(struct drm_connector
*connector,
if (mga_vga_calculate_mode_bandwidth(mode, bpp)
> (30100 * 1024))
return MODE_BANDWIDTH;
+ } else {
+ if (mga_vga_calculate_mode_bandwidth(mode, bpp)
+ > (55000 * 1024))
+ return MODE_BANDWIDTH;
}
} else if (mdev->type == G200_WB) {
if (mode->hdisplay > 1280)
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 14/22] gpu: host1x: Forbid relocation address shifting in the firewall
Incorrectly shifted relocation address will cause a lower memory corruption
and likely a hang on a write or a read of an arbitrary data in case of IOMMU
absent. As of now there is no use for the address shifting (at least on
Tegra20) and adding a proper shifting / sizes validation is much more work.
Let's forbid it in the firewall till a proper validation is implemented.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Erik Faye-Lund
---
drivers/gpu/host1x/dev.c | 4
drivers/gpu/host1x/dev.h | 1 +
drivers/gpu/host1x/job.c | 24
3 files changed, 29 insertions(+)
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 6a805ed908c3..21da331ce092 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -72,6 +72,7 @@ static const struct host1x_info host1x01_info = {
.init = host1x01_init,
.sync_offset = 0x3000,
.dma_mask = DMA_BIT_MASK(32),
+ .version = 1,
};
static const struct host1x_info host1x02_info = {
@@ -82,6 +83,7 @@ static const struct host1x_info host1x02_info = {
.init = host1x02_init,
.sync_offset = 0x3000,
.dma_mask = DMA_BIT_MASK(32),
+ .version = 2,
};
static const struct host1x_info host1x04_info = {
@@ -92,6 +94,7 @@ static const struct host1x_info host1x04_info = {
.init = host1x04_init,
.sync_offset = 0x2100,
.dma_mask = DMA_BIT_MASK(34),
+ .version = 4,
};
static const struct host1x_info host1x05_info = {
@@ -102,6 +105,7 @@ static const struct host1x_info host1x05_info = {
.init = host1x05_init,
.sync_offset = 0x2100,
.dma_mask = DMA_BIT_MASK(34),
+ .version = 5,
};
static const struct of_device_id host1x_of_match[] = {
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index 229d08b6a45e..c6997651b336 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -100,6 +100,7 @@ struct host1x_info {
int (*init)(struct host1x *host1x); /* initialize per SoC ops */
unsigned int sync_offset; /* offset of syncpoint registers */
u64 dma_mask; /* mask of addressable memory */
+ unsigned int version; /* host1x's version */
};
struct host1x {
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 4208329ca2af..7825643da324 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -333,6 +333,27 @@ static bool check_reloc(struct host1x_reloc *reloc, struct
host1x_bo *cmdbuf,
return true;
}
+static bool check_reloc_shift(struct device *dev, struct host1x_reloc *reloc)
+{
+ struct host1x *host = dev_get_drvdata(dev->parent);
+
+ /* skip newer Tegra's since IOMMU is supposed to be used by
+* them and not all address registers with their shifts are
+* publicly documented */
+ if (host->info->version > 1)
+ return true;
+
+ /* skip Tegra30 with IOMMU enabled */
+ if (host->domain)
+ return true;
+
+ /* relocation shift value validation isn't implemented yet */
+ if (reloc->shift)
+ return false;
+
+ return true;
+}
+
struct host1x_firewall {
struct host1x_job *job;
struct device *dev;
@@ -359,6 +380,9 @@ static int check_register(struct host1x_firewall *fw,
unsigned long offset)
if (!check_reloc(fw->reloc, fw->cmdbuf, fw->offset))
return -EINVAL;
+ if (!check_reloc_shift(fw->dev, fw->reloc))
+ return -EINVAL;
+
fw->num_relocs--;
fw->reloc++;
}
--
2.13.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] staging: vboxvideo: Add vboxvideo to drivers/staging
13.06.2017 14:48, Greg Kroah-Hartman wrote: [Discussion of vboxvideo coding style.] > Once your code is accepted into the main kernel tree, why would you > continue to work in an out-of-tree repo anyway? That's ripe for > disaster, what's keeping you from just working with the in-tree version? One of our use cases is customers running older operating systems, including legacy Linux distributions. However those customers would still like the most up-to-date guest drivers possible without updating the kernel. Updating drivers without updating the kernel is not a scenario of interest to upstream kernel developers, which is why we will continue to maintain the out-of-tree repository (which is actually the VirtualBox repository, where the OS-independent code is shared with drivers for other platforms). The end result is not unlike what Red Hat does when it does back-ports to its stable kernels. Regards Michael [...] -- Michael Thayer | VirtualBox engineer ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | D-71384 Weinstadt ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/22] gpu: host1x: Forbid unrelated SETCLASS opcode in the firewall
On 13.06.2017 17:06, Thierry Reding wrote:
> On Tue, May 23, 2017 at 02:39:33AM +0200, Erik Faye-Lund wrote:
>> On Tue, May 23, 2017 at 2:14 AM, Dmitry Osipenko wrote:
>>> Several channels could be made to write the same unit concurrently via the
>>> SETCLASS opcode, trusting userspace is a bad idea. It should be possible to
>>> drop the per-client channel reservation and add a per-unit locking by
>>> inserting MLOCK's to the command stream to re-allow the SETCLASS opcode, but
>>> it will be much more work. Let's forbid the unit-unrelated class changes for
>>> now.
>>>
>>> Signed-off-by: Dmitry Osipenko
>>> ---
>>> drivers/gpu/drm/tegra/drm.c | 1 +
>>> drivers/gpu/drm/tegra/drm.h | 1 +
>>> drivers/gpu/drm/tegra/gr2d.c | 12
>>> drivers/gpu/host1x/job.c | 24
>>> include/linux/host1x.h | 5 -
>>> 5 files changed, 38 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
>>> index cdb05d6efde4..17416e1c219a 100644
>>> --- a/drivers/gpu/drm/tegra/drm.c
>>> +++ b/drivers/gpu/drm/tegra/drm.c
>>> @@ -531,6 +531,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
>>> }
>>>
>>> job->is_addr_reg = context->client->ops->is_addr_reg;
>>> + job->is_valid_class = context->client->ops->is_valid_class;
>>> job->syncpt_incrs = syncpt.incrs;
>>> job->syncpt_id = syncpt.id;
>>> job->timeout = 1;
>>> diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
>>> index 85aa2e3d9d4e..6d6da01282f3 100644
>>> --- a/drivers/gpu/drm/tegra/drm.h
>>> +++ b/drivers/gpu/drm/tegra/drm.h
>>> @@ -83,6 +83,7 @@ struct tegra_drm_client_ops {
>>> struct tegra_drm_context *context);
>>> void (*close_channel)(struct tegra_drm_context *context);
>>> int (*is_addr_reg)(struct device *dev, u32 class, u32 offset);
>>> + int (*is_valid_class)(u32 class);
>>> int (*submit)(struct tegra_drm_context *context,
>>> struct drm_tegra_submit *args, struct drm_device *drm,
>>> struct drm_file *file);
>>> diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
>>> index 02cd3e37a6ec..782231c41a1a 100644
>>> --- a/drivers/gpu/drm/tegra/gr2d.c
>>> +++ b/drivers/gpu/drm/tegra/gr2d.c
>>> @@ -109,10 +109,22 @@ static int gr2d_is_addr_reg(struct device *dev, u32
>>> class, u32 offset)
>>> return 0;
>>> }
>>>
>>> +static int gr2d_is_valid_class(u32 class)
>>> +{
>>> + switch (class) {
>>> + case HOST1X_CLASS_GR2D:
>>> + case HOST1X_CLASS_GR2D_SB:
>>> + return 1;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> static const struct tegra_drm_client_ops gr2d_ops = {
>>> .open_channel = gr2d_open_channel,
>>> .close_channel = gr2d_close_channel,
>>> .is_addr_reg = gr2d_is_addr_reg,
>>> + .is_valid_class = gr2d_is_valid_class,
>>> .submit = tegra_drm_submit,
>>> };
>>>
>>> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
>>> index cf335c5979e2..65e12219405a 100644
>>> --- a/drivers/gpu/host1x/job.c
>>> +++ b/drivers/gpu/host1x/job.c
>>> @@ -358,6 +358,9 @@ struct host1x_firewall {
>>>
>>> static int check_register(struct host1x_firewall *fw, unsigned long offset)
>>> {
>>> + if (!fw->job->is_addr_reg)
>>> + return 0;
>>> +
>>> if (fw->job->is_addr_reg(fw->dev, fw->class, offset)) {
>>> if (!fw->num_relocs)
>>> return -EINVAL;
>>> @@ -372,6 +375,19 @@ static int check_register(struct host1x_firewall *fw,
>>> unsigned long offset)
>>> return 0;
>>> }
>>>
>>> +static int check_class(struct host1x_firewall *fw, u32 class)
>>> +{
>>> + if (!fw->job->is_valid_class) {
>>> + if (fw->class != class)
>>> + return -EINVAL;
>>> + } else {
>>> + if (!fw->job->is_valid_class(fw->class))
>>> + return -EINVAL;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> static int check_mask(struct host1x_firewall *fw)
>>> {
>>> u32 mask = fw->mask;
>>> @@ -445,11 +461,9 @@ static int validate(struct host1x_firewall *fw, struct
>>> host1x_job_gather *g)
>>> {
>>> u32 *cmdbuf_base = (u32 *)fw->job->gather_copy_mapped +
>>> (g->offset / sizeof(u32));
>>> + u32 job_class = fw->class;
>>> int err = 0;
>>>
>>> - if (!fw->job->is_addr_reg)
>>> - return 0;
>>> -
>>> fw->words = g->words;
>>> fw->cmdbuf = g->bo;
>>> fw->offset = 0;
>>> @@ -469,7 +483,9 @@ static int validate(struct host1x_firewall *fw, struct
>>> host1x_job_gather *g)
>>> fw->class = word >> 6 & 0x3ff;
>>> fw->mask = word & 0x3f;
>>> fw->reg = word >> 16 & 0xfff;
>>> - err =
[PATCH v2 04/22] drm/tegra: Correct copying of waitchecks and disable them in the 'submit' IOCTL
The waitchecks along with multiple syncpoints per submit are not ready for
use yet, let's forbid them for now.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/drm.c | 60 ++---
drivers/gpu/host1x/job.h| 7 --
include/linux/host1x.h | 7 ++
3 files changed, 63 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index c9246405fc7b..b90ed2cd32ce 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -349,6 +349,36 @@ static int host1x_reloc_copy_from_user(struct host1x_reloc
*dest,
return 0;
}
+static int host1x_waitchk_copy_from_user(struct host1x_waitchk *dest,
+struct drm_tegra_waitchk __user *src,
+struct drm_file *file)
+{
+ u32 cmdbuf;
+ int err;
+
+ err = get_user(cmdbuf, &src->handle);
+ if (err < 0)
+ return err;
+
+ err = get_user(dest->offset, &src->offset);
+ if (err < 0)
+ return err;
+
+ err = get_user(dest->syncpt_id, &src->syncpt);
+ if (err < 0)
+ return err;
+
+ err = get_user(dest->thresh, &src->thresh);
+ if (err < 0)
+ return err;
+
+ dest->bo = host1x_bo_lookup(file, cmdbuf);
+ if (!dest->bo)
+ return -ENOENT;
+
+ return 0;
+}
+
int tegra_drm_submit(struct tegra_drm_context *context,
struct drm_tegra_submit *args, struct drm_device *drm,
struct drm_file *file)
@@ -370,6 +400,10 @@ int tegra_drm_submit(struct tegra_drm_context *context,
if (args->num_syncpts != 1)
return -EINVAL;
+ /* We don't yet support waitchks */
+ if (args->num_waitchks != 0)
+ return -EINVAL;
+
job = host1x_job_alloc(context->channel, args->num_cmdbufs,
args->num_relocs, args->num_waitchks);
if (!job)
@@ -458,10 +492,28 @@ int tegra_drm_submit(struct tegra_drm_context *context,
}
}
- if (copy_from_user(job->waitchk, waitchks,
- sizeof(*waitchks) * num_waitchks)) {
- err = -EFAULT;
- goto fail;
+ /* copy and resolve waitchks from submit */
+ while (num_waitchks--) {
+ struct host1x_waitchk *wait = &job->waitchk[num_waitchks];
+ struct tegra_bo *obj;
+
+ err = host1x_waitchk_copy_from_user(wait,
+ &waitchks[num_waitchks],
+ file);
+ if (err < 0)
+ goto fail;
+
+ obj = host1x_to_tegra_bo(wait->bo);
+
+ /*
+* The unaligned offset will cause an unaligned write during
+* of the waitchks patching, corrupting the commands stream.
+*/
+ if (wait->offset & 3 ||
+ wait->offset >= obj->gem.size) {
+ err = -EINVAL;
+ goto fail;
+ }
}
if (copy_from_user(&syncpt, (void __user *)(uintptr_t)args->syncpts,
diff --git a/drivers/gpu/host1x/job.h b/drivers/gpu/host1x/job.h
index 878239c476d2..0debd93a1849 100644
--- a/drivers/gpu/host1x/job.h
+++ b/drivers/gpu/host1x/job.h
@@ -34,13 +34,6 @@ struct host1x_cmdbuf {
u32 pad;
};
-struct host1x_waitchk {
- struct host1x_bo *bo;
- u32 offset;
- u32 syncpt_id;
- u32 thresh;
-};
-
struct host1x_job_unpin_data {
struct host1x_bo *bo;
struct sg_table *sgt;
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index 3d04aa1dc83e..aa323e43ae4e 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -177,6 +177,13 @@ struct host1x_reloc {
unsigned long shift;
};
+struct host1x_waitchk {
+ struct host1x_bo *bo;
+ u32 offset;
+ u32 syncpt_id;
+ u32 thresh;
+};
+
struct host1x_job {
/* When refcount goes to zero, job can be freed */
struct kref ref;
--
2.13.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 20/22] gpu: host1x: Remove unused host1x_cdma_stop() definition
There is no host1x_cdma_stop() in the code, let's remove its definition
from the header file.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Erik Faye-Lund
Reviewed-by: Mikko Perttunen
---
drivers/gpu/host1x/cdma.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/host1x/cdma.h b/drivers/gpu/host1x/cdma.h
index ec170a78f4e1..286d49386be9 100644
--- a/drivers/gpu/host1x/cdma.h
+++ b/drivers/gpu/host1x/cdma.h
@@ -88,7 +88,6 @@ struct host1x_cdma {
int host1x_cdma_init(struct host1x_cdma *cdma);
int host1x_cdma_deinit(struct host1x_cdma *cdma);
-void host1x_cdma_stop(struct host1x_cdma *cdma);
int host1x_cdma_begin(struct host1x_cdma *cdma, struct host1x_job *job);
void host1x_cdma_push(struct host1x_cdma *cdma, u32 op1, u32 op2);
void host1x_cdma_end(struct host1x_cdma *cdma, struct host1x_job *job);
--
2.13.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 18/22] gpu: host1x: Check waits in the firewall
Check waits in the firewall in a way it is done for relocations.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Mikko Perttunen
---
drivers/gpu/host1x/job.c | 36 ++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 32d3300bcf99..fc194c676d91 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -31,6 +31,8 @@
#include "job.h"
#include "syncpt.h"
+#define HOST1X_WAIT_SYNCPT_OFFSET 0x8
+
struct host1x_job *host1x_job_alloc(struct host1x_channel *ch,
u32 num_cmdbufs, u32 num_relocs,
u32 num_waitchks)
@@ -354,6 +356,17 @@ static bool check_reloc_shift(struct device *dev, struct
host1x_reloc *reloc)
return true;
}
+static bool check_wait(struct host1x_waitchk *wait, struct host1x_bo *cmdbuf,
+ unsigned int offset)
+{
+ offset *= sizeof(u32);
+
+ if (wait->bo != cmdbuf || wait->offset != offset)
+ return false;
+
+ return true;
+}
+
struct host1x_firewall {
struct host1x_job *job;
struct device *dev;
@@ -361,6 +374,9 @@ struct host1x_firewall {
unsigned int num_relocs;
struct host1x_reloc *reloc;
+ unsigned int num_waitchks;
+ struct host1x_waitchk *waitchk;
+
struct host1x_bo *cmdbuf;
unsigned int offset;
@@ -390,6 +406,20 @@ static int check_register(struct host1x_firewall *fw,
unsigned long offset)
fw->reloc++;
}
+ if (offset == HOST1X_WAIT_SYNCPT_OFFSET) {
+ if (fw->class != HOST1X_CLASS_HOST1X)
+ return -EINVAL;
+
+ if (!fw->num_waitchks)
+ return -EINVAL;
+
+ if (!check_wait(fw->waitchk, fw->cmdbuf, fw->offset))
+ return -EINVAL;
+
+ fw->num_waitchks--;
+ fw->waitchk++;
+ }
+
return 0;
}
@@ -554,6 +584,8 @@ static inline int copy_gathers(struct host1x_job *job,
struct device *dev)
fw.dev = dev;
fw.reloc = job->relocarray;
fw.num_relocs = job->num_relocs;
+ fw.waitchk = job->waitchk;
+ fw.num_waitchks = job->num_waitchk;
fw.class = job->class;
for (i = 0; i < job->num_gathers; i++) {
@@ -592,8 +624,8 @@ static inline int copy_gathers(struct host1x_job *job,
struct device *dev)
offset += g->words * sizeof(u32);
}
- /* No relocs should remain at this point */
- if (fw.num_relocs)
+ /* No relocs and waitchks should remain at this point */
+ if (fw.num_relocs || fw.num_waitchks)
return -EINVAL;
return 0;
--
2.13.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 21/22] gpu: host1x: Refactor channel allocation code
From: Mikko Perttunen
This is largely a rewrite of the Host1x channel allocation code, bringing
several changes:
- The previous code could deadlock due to an interaction
between the 'reflock' mutex and CDMA timeout handling.
This gets rid of the mutex.
- Support for more than 32 channels, required for Tegra186
- General refactoring, including better encapsulation
of channel ownership handling into channel.c
Signed-off-by: Mikko Perttunen
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/gr2d.c | 4 +-
drivers/gpu/drm/tegra/gr3d.c | 4 +-
drivers/gpu/drm/tegra/vic.c| 4 +-
drivers/gpu/host1x/channel.c | 147 +++--
drivers/gpu/host1x/channel.h | 21 --
drivers/gpu/host1x/debug.c | 47 +---
drivers/gpu/host1x/dev.c | 7 +-
drivers/gpu/host1x/dev.h | 6 +-
drivers/gpu/host1x/hw/channel_hw.c | 4 -
include/linux/host1x.h | 1 -
10 files changed, 135 insertions(+), 110 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index fbe0b8b25b42..6ea070da7718 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -38,7 +38,7 @@ static int gr2d_init(struct host1x_client *client)
client->syncpts[0] = host1x_syncpt_request(client->dev, flags);
if (!client->syncpts[0]) {
- host1x_channel_free(gr2d->channel);
+ host1x_channel_put(gr2d->channel);
return -ENOMEM;
}
@@ -57,7 +57,7 @@ static int gr2d_exit(struct host1x_client *client)
return err;
host1x_syncpt_free(client->syncpts[0]);
- host1x_channel_free(gr2d->channel);
+ host1x_channel_put(gr2d->channel);
return 0;
}
diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
index 13f0d1b7cd98..cee2ab645cde 100644
--- a/drivers/gpu/drm/tegra/gr3d.c
+++ b/drivers/gpu/drm/tegra/gr3d.c
@@ -48,7 +48,7 @@ static int gr3d_init(struct host1x_client *client)
client->syncpts[0] = host1x_syncpt_request(client->dev, flags);
if (!client->syncpts[0]) {
- host1x_channel_free(gr3d->channel);
+ host1x_channel_put(gr3d->channel);
return -ENOMEM;
}
@@ -67,7 +67,7 @@ static int gr3d_exit(struct host1x_client *client)
return err;
host1x_syncpt_free(client->syncpts[0]);
- host1x_channel_free(gr3d->channel);
+ host1x_channel_put(gr3d->channel);
return 0;
}
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index cd804e404a11..47cb1aaa58b1 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -182,7 +182,7 @@ static int vic_init(struct host1x_client *client)
free_syncpt:
host1x_syncpt_free(client->syncpts[0]);
free_channel:
- host1x_channel_free(vic->channel);
+ host1x_channel_put(vic->channel);
detach_device:
if (tegra->domain)
iommu_detach_device(tegra->domain, vic->dev);
@@ -203,7 +203,7 @@ static int vic_exit(struct host1x_client *client)
return err;
host1x_syncpt_free(client->syncpts[0]);
- host1x_channel_free(vic->channel);
+ host1x_channel_put(vic->channel);
if (vic->domain) {
iommu_detach_device(vic->domain, vic->dev);
diff --git a/drivers/gpu/host1x/channel.c b/drivers/gpu/host1x/channel.c
index 8f437d924c10..db9b91d1384c 100644
--- a/drivers/gpu/host1x/channel.c
+++ b/drivers/gpu/host1x/channel.c
@@ -24,19 +24,33 @@
#include "job.h"
/* Constructor for the host1x device list */
-int host1x_channel_list_init(struct host1x *host)
+int host1x_channel_list_init(struct host1x_channel_list *chlist,
+unsigned int num_channels)
{
- INIT_LIST_HEAD(&host->chlist.list);
- mutex_init(&host->chlist_mutex);
-
- if (host->info->nb_channels > BITS_PER_LONG) {
- WARN(1, "host1x hardware has more channels than supported by
the driver\n");
- return -ENOSYS;
+ chlist->channels = kcalloc(num_channels, sizeof(struct host1x_channel),
+ GFP_KERNEL);
+ if (!chlist->channels)
+ return -ENOMEM;
+
+ chlist->allocated_channels =
+ kcalloc(BITS_TO_LONGS(num_channels), sizeof(unsigned long),
+ GFP_KERNEL);
+ if (!chlist->allocated_channels) {
+ kfree(chlist->channels);
+ return -ENOMEM;
}
+ bitmap_zero(chlist->allocated_channels, num_channels);
+
return 0;
}
+void host1x_channel_list_free(struct host1x_channel_list *chlist)
+{
+ kfree(chlist->allocated_channels);
+ kfree(chlist->channels);
+}
+
int host1x_job_submit(struct host1x_job *job)
{
struct host1x *host = dev_get_drvdata(job->channel->dev->parent);
@@ -47,86 +61,10
[PATCH v2 10/22] Revert "iommu/tegra: gart: Do not register with bus"
The GART driver was disabled because it was picked by as an IOMMU provider for the DRM driver on Tegra20, which is not the purpose of the GART. Now DRM driver avoids to use IOMMU on Tegra20, so the GART driver can be re-enabled. Potentially there are interesting use cases of the GART for Tegra20, like mmap'ing of a fallback memory allocation and using its GART aperture for an accelerated graphics operation. This reverts commit c7e3ca515e784a82223f447b79eb2090bdb91378. Signed-off-by: Dmitry Osipenko Acked-by: Joerg Roedel --- drivers/iommu/tegra-gart.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/tegra-gart.c b/drivers/iommu/tegra-gart.c index 37e708fdbb5a..430d13bf4f95 100644 --- a/drivers/iommu/tegra-gart.c +++ b/drivers/iommu/tegra-gart.c @@ -422,7 +422,7 @@ static int tegra_gart_probe(struct platform_device *pdev) do_gart_setup(gart, NULL); gart_handle = gart; - + bus_set_iommu(&platform_bus_type, &gart_iommu_ops); return 0; } -- 2.13.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 22/22] gpu: host1x: At first try a non-blocking allocation for the gather copy
The blocking gather copy allocation is a major performance downside of the
Host1x firewall, it may take hundreds milliseconds which is unacceptable
for the real-time graphics operations. Let's try a non-blocking allocation
first as a least invasive solution, it makes opentegra (Xorg driver)
performance indistinguishable with/without the firewall.
Signed-off-by: Dmitry Osipenko
---
The other much more invasive solution could be: to have a memory pool
reserved for the gather copy and performing the firewall checks (and the
gather copying) on the actual job submission to the CDMA, not on the job
allocation like it is done now. This solution reduces the overhead of a
gather copy allocations.
drivers/gpu/host1x/job.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index fc194c676d91..ed0575f14093 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -594,12 +594,20 @@ static inline int copy_gathers(struct host1x_job *job,
struct device *dev)
size += g->words * sizeof(u32);
}
+ /*
+* Try a non-blocking allocation from a higher priority pools first,
+* as awaiting for the allocation here is a major performance hit.
+*/
job->gather_copy_mapped = dma_alloc_wc(dev, size, &job->gather_copy,
- GFP_KERNEL);
- if (!job->gather_copy_mapped) {
- job->gather_copy_mapped = NULL;
+ GFP_NOWAIT);
+
+ /* the higher priority allocation failed, try the generic-blocking */
+ if (!job->gather_copy_mapped)
+ job->gather_copy_mapped = dma_alloc_wc(dev, size,
+ &job->gather_copy,
+ GFP_KERNEL);
+ if (!job->gather_copy_mapped)
return -ENOMEM;
- }
job->gather_copy_size = size;
--
2.13.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 16/22] gpu: host1x: Forbid unrelated SETCLASS opcode in the firewall
Several channels could be made to write the same unit concurrently via the
SETCLASS opcode, trusting userspace is a bad idea. It should be possible to
drop the per-client channel reservation and add a per-unit locking by
inserting MLOCK's to the command stream to re-allow the SETCLASS opcode, but
it will be much more work. Let's forbid the unit-unrelated class changes for
now.
Signed-off-by: Dmitry Osipenko
Reviewed-by: Erik Faye-Lund
Reviewed-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/drm.c | 1 +
drivers/gpu/drm/tegra/drm.h | 1 +
drivers/gpu/drm/tegra/gr2d.c | 7 +++
drivers/gpu/host1x/job.c | 24
include/linux/host1x.h | 3 +++
5 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index aa7988dcc28f..971cdead6436 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -533,6 +533,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
}
job->is_addr_reg = context->client->ops->is_addr_reg;
+ job->is_valid_class = context->client->ops->is_valid_class;
job->syncpt_incrs = syncpt.incrs;
job->syncpt_id = syncpt.id;
job->timeout = 1;
diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
index 85aa2e3d9d4e..6d6da01282f3 100644
--- a/drivers/gpu/drm/tegra/drm.h
+++ b/drivers/gpu/drm/tegra/drm.h
@@ -83,6 +83,7 @@ struct tegra_drm_client_ops {
struct tegra_drm_context *context);
void (*close_channel)(struct tegra_drm_context *context);
int (*is_addr_reg)(struct device *dev, u32 class, u32 offset);
+ int (*is_valid_class)(u32 class);
int (*submit)(struct tegra_drm_context *context,
struct drm_tegra_submit *args, struct drm_device *drm,
struct drm_file *file);
diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index 02cd3e37a6ec..fbe0b8b25b42 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -109,10 +109,17 @@ static int gr2d_is_addr_reg(struct device *dev, u32
class, u32 offset)
return 0;
}
+static int gr2d_is_valid_class(u32 class)
+{
+ return (class == HOST1X_CLASS_GR2D ||
+ class == HOST1X_CLASS_GR2D_SB);
+}
+
static const struct tegra_drm_client_ops gr2d_ops = {
.open_channel = gr2d_open_channel,
.close_channel = gr2d_close_channel,
.is_addr_reg = gr2d_is_addr_reg,
+ .is_valid_class = gr2d_is_valid_class,
.submit = tegra_drm_submit,
};
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 3680b4b7dce9..32d3300bcf99 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -373,6 +373,9 @@ struct host1x_firewall {
static int check_register(struct host1x_firewall *fw, unsigned long offset)
{
+ if (!fw->job->is_addr_reg)
+ return 0;
+
if (fw->job->is_addr_reg(fw->dev, fw->class, offset)) {
if (!fw->num_relocs)
return -EINVAL;
@@ -390,6 +393,19 @@ static int check_register(struct host1x_firewall *fw,
unsigned long offset)
return 0;
}
+static int check_class(struct host1x_firewall *fw, u32 class)
+{
+ if (!fw->job->is_valid_class) {
+ if (fw->class != class)
+ return -EINVAL;
+ } else {
+ if (!fw->job->is_valid_class(fw->class))
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int check_mask(struct host1x_firewall *fw)
{
u32 mask = fw->mask;
@@ -463,11 +479,9 @@ static int validate(struct host1x_firewall *fw, struct
host1x_job_gather *g)
{
u32 *cmdbuf_base = (u32 *)fw->job->gather_copy_mapped +
(g->offset / sizeof(u32));
+ u32 job_class = fw->class;
int err = 0;
- if (!fw->job->is_addr_reg)
- return 0;
-
fw->words = g->words;
fw->cmdbuf = g->bo;
fw->offset = 0;
@@ -487,7 +501,9 @@ static int validate(struct host1x_firewall *fw, struct
host1x_job_gather *g)
fw->class = word >> 6 & 0x3ff;
fw->mask = word & 0x3f;
fw->reg = word >> 16 & 0xfff;
- err = check_mask(fw);
+ err = check_class(fw, job_class);
+ if (!err)
+ err = check_mask(fw);
if (err)
goto out;
break;
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index aa323e43ae4e..71a34774b56a 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -235,6 +235,9 @@ struct host1x_job {
/* Check if register is marked as an address reg */
int (*is_addr_reg)(struct device *dev, u32 reg, u32 class);
+ /* Check if class belongs to the unit */
+
[PATCH v2 09/22] drm/tegra: Don't use IOMMU on Tegra20
There is no IOMMU on Tegra20, instead a GART would be picked as an IOMMU
provider.
Signed-off-by: Dmitry Osipenko
Acked-by: Joerg Roedel
---
drivers/gpu/drm/tegra/drm.c | 3 ++-
drivers/gpu/host1x/dev.c| 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index e999391aedc9..aa7988dcc28f 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -131,7 +131,8 @@ static int tegra_drm_load(struct drm_device *drm, unsigned
long flags)
if (!tegra)
return -ENOMEM;
- if (iommu_present(&platform_bus_type)) {
+ if (iommu_present(&platform_bus_type) &&
+ !of_machine_is_compatible("nvidia,tegra20")) {
u64 carveout_start, carveout_end, gem_start, gem_end;
struct iommu_domain_geometry *geometry;
unsigned long order;
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index f05ebb14fa63..6a805ed908c3 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -177,7 +177,8 @@ static int host1x_probe(struct platform_device *pdev)
return err;
}
- if (iommu_present(&platform_bus_type)) {
+ if (iommu_present(&platform_bus_type) &&
+ !of_machine_is_compatible("nvidia,tegra20")) {
struct iommu_domain_geometry *geometry;
unsigned long order;
--
2.13.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Color lookup support for the atmel-hlcdc driver
Hi!
I need color lookup support for the atmel-hlcdc driver, and had a peek
at the code. I also looked at the drivers/gpu/drm/stm driver and came
up with the below diff. It compiles, but I have not booted it for the
simple reason that I can't imagine it will work.
Sure, the code fills the clut registers in the .load_lut helper function
and I think it might even do the right thing when setting up the mode.
I'm less sure DMA will work correctly? It might, but I haven't looked at
it for many seconds...
The big question is how the color info gets into the new clut array
I created in atmel_hlcdc_crtc? When I look at the stm driver, which does
it just like this AFAICT I just don't see it. So, what I'm I missing?
Also, when I'm looking at the docs for .load_lut I get the feeling
that I'm barking up some dead old tree.
help
Cheers,
peda
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 53489859997b..62ef30676cc3 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -61,6 +61,7 @@ struct atmel_hlcdc_crtc {
struct atmel_hlcdc_dc *dc;
struct drm_pending_vblank_event *event;
int id;
+ u32 clut[256];
};
static inline struct atmel_hlcdc_crtc *
@@ -140,6 +141,23 @@ static void atmel_hlcdc_crtc_mode_set_nofb(struct drm_crtc
*c)
cfg);
}
+static void
+atmel_hlcdc_crtc_load_lut(struct drm_crtc *c)
+{
+ struct atmel_hlcdc_crtc *crtc = drm_crtc_to_atmel_hlcdc_crtc(c);
+ struct atmel_hlcdc_dc *dc = crtc->dc;
+ unsigned int color;
+ int layer;
+
+ for (layer = 0; layer < ATMEL_HLCDC_MAX_LAYERS; layer++) {
+ if (!dc->layers[layer])
+ continue;
+ for (color = 0; color < 256; color++)
+ atmel_hlcdc_layer_write_clut(dc->layers[layer],
+color, crtc->clut[color]);
+ }
+}
+
static enum drm_mode_status
atmel_hlcdc_crtc_mode_valid(struct drm_crtc *c,
const struct drm_display_mode *mode)
@@ -319,6 +337,7 @@ static const struct drm_crtc_helper_funcs
lcdc_crtc_helper_funcs = {
.mode_set = drm_helper_crtc_mode_set,
.mode_set_nofb = atmel_hlcdc_crtc_mode_set_nofb,
.mode_set_base = drm_helper_crtc_mode_set_base,
+ .load_lut = atmel_hlcdc_crtc_load_lut,
.disable = atmel_hlcdc_crtc_disable,
.enable = atmel_hlcdc_crtc_enable,
.atomic_check = atmel_hlcdc_crtc_atomic_check,
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 30dbffdb45a3..4723cadb67c4 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -37,6 +37,7 @@ static const struct atmel_hlcdc_layer_desc
atmel_hlcdc_at91sam9n12_layers[] = {
.id = 0,
.type = ATMEL_HLCDC_BASE_LAYER,
.cfgs_offset = 0x2c,
+ .clut_offset = 0x400,
.layout = {
.xstride = { 2 },
.default_color = 3,
@@ -66,6 +67,7 @@ static const struct atmel_hlcdc_layer_desc
atmel_hlcdc_at91sam9x5_layers[] = {
.id = 0,
.type = ATMEL_HLCDC_BASE_LAYER,
.cfgs_offset = 0x2c,
+ .clut_offset = 0x400,
.layout = {
.xstride = { 2 },
.default_color = 3,
@@ -81,6 +83,7 @@ static const struct atmel_hlcdc_layer_desc
atmel_hlcdc_at91sam9x5_layers[] = {
.id = 1,
.type = ATMEL_HLCDC_OVERLAY_LAYER,
.cfgs_offset = 0x2c,
+ .clut_offset = 0x800,
.layout = {
.pos = 2,
.size = 3,
@@ -99,6 +102,7 @@ static const struct atmel_hlcdc_layer_desc
atmel_hlcdc_at91sam9x5_layers[] = {
.id = 2,
.type = ATMEL_HLCDC_OVERLAY_LAYER,
.cfgs_offset = 0x4c,
+ .clut_offset = 0x1000,
.layout = {
.pos = 2,
.size = 3,
@@ -122,6 +126,7 @@ static const struct atmel_hlcdc_layer_desc
atmel_hlcdc_at91sam9x5_layers[] = {
.max_width = 128,
.max_height = 128,
.cfgs_offset = 0x2c,
+ .clut_offset = 0x1400,
.layout = {
.pos = 2,
.size = 3,
@@ -155,6 +160,7 @@ static const struct atmel_hlcdc_layer_desc
atmel_hlcdc_sama5d3_layers[] = {
.id = 0,
.type = ATMEL_HLCDC_BASE_LAYER,
.cfgs_offset = 0x2c,
+ .clut_offset = 0x600,
.layout = {
.xstride = { 2 },
.default_color = 3,
@@ -170,6 +176,7 @@ s
