[Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit
Hi, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160420] [cannot apply to v4.6-rc4] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Robert-Bragg/Enable-Gen-7-Observation-Architecture/20160420-222746 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: i386-randconfig-s1-201616 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/built-in.o: In function `i915_perf_open_ioctl_locked': >> (.text+0x2cadf4): undefined reference to `__udivdi3' drivers/built-in.o: In function `i915_perf_open_ioctl_locked': (.text+0x2cae0d): undefined reference to `__udivdi3' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- next part -- A non-text attachment was scrubbed... Name: .config.gz Type: application/octet-stream Size: 25411 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/702901b3/attachment-0001.obj>
[PATCH 4/8] drm/fb-helper: Add fb_deferred_io support
found for
parameter 'engine'
drivers/gpu/drm/i915/i915_gem.c:3037: warning: No description found for
parameter 'obj'
drivers/gpu/drm/i915/i915_gem.c:3087: warning: No description found for
parameter 'dev'
drivers/gpu/drm/i915/i915_gem.c:3087: warning: No description found for
parameter 'data'
drivers/gpu/drm/i915/i915_gem.c:3087: warning: No description found for
parameter 'file'
drivers/gpu/drm/i915/i915_gem.c:3087: warning: Excess function parameter
'DRM_IOCTL_ARGS' description in 'i915_gem_wait_ioctl'
drivers/gpu/drm/i915/i915_gem.c:3459: warning: No description found for
parameter 'obj'
drivers/gpu/drm/i915/i915_gem.c:3459: warning: No description found for
parameter 'vm'
drivers/gpu/drm/i915/i915_gem.c:3459: warning: No description found for
parameter 'ggtt_view'
drivers/gpu/drm/i915/i915_gem.c:3459: warning: No description found for
parameter 'alignment'
drivers/gpu/drm/i915/i915_gem.c:3459: warning: No description found for
parameter 'flags'
drivers/gpu/drm/i915/i915_gem.c:3714: warning: No description found for
parameter 'obj'
drivers/gpu/drm/i915/i915_gem.c:3714: warning: No description found for
parameter 'write'
drivers/gpu/drm/i915/i915_gem.c:3789: warning: No description found for
parameter 'obj'
drivers/gpu/drm/i915/i915_gem.c:3789: warning: No description found for
parameter 'cache_level'
drivers/gpu/drm/i915/i915_gem.c:4063: warning: No description found for
parameter 'obj'
drivers/gpu/drm/i915/i915_gem.c:4063: warning: No description found for
parameter 'write'
drivers/gpu/drm/i915/i915_cmd_parser.c:748: warning: No description found
for parameter 'engine'
drivers/gpu/drm/i915/i915_cmd_parser.c:748: warning: Excess function
parameter 'ring' description in 'i915_cmd_parser_init_ring'
drivers/gpu/drm/i915/i915_cmd_parser.c:838: warning: No description found
for parameter 'engine'
drivers/gpu/drm/i915/i915_cmd_parser.c:838: warning: Excess function
parameter 'ring' description in 'i915_cmd_parser_fini_ring'
drivers/gpu/drm/i915/i915_cmd_parser.c:1034: warning: No description found
for parameter 'engine'
vim +/info +867 drivers/gpu/drm/drm_fb_helper.c
851 }
852 EXPORT_SYMBOL(drm_fb_helper_unlink_fbi);
853
854 #ifdef CONFIG_FB_DEFERRED_IO
855 /**
856 * drm_fb_helper_deferred_io() - (struct fb_deferred_io *)->deferred_io
callback
857 * function
858 *
859 * This function always runs in process context (struct delayed_work)
and calls
860 * the (struct drm_framebuffer_funcs)->dirty function with the collected
861 * damage. There's no need to worry about the possibility that the
fb_sys_*()
862 * functions could be running in atomic context. They only schedule the
863 * delayed worker which then calls this deferred_io callback.
864 */
865 void drm_fb_helper_deferred_io(struct fb_info *info,
866 struct list_head *pagelist)
> 867 {
868 struct drm_fb_helper *helper = info->par;
869 unsigned long start, end, min, max;
870 struct drm_clip_rect clip;
871 unsigned long flags;
872 struct page *page;
873
874 if (!helper->fb->funcs->dirty)
875 return;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 6302 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/dd11847d/attachment-0001.obj>
[Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit
Hi, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160420] [cannot apply to v4.6-rc4] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Robert-Bragg/Enable-Gen-7-Observation-Architecture/20160420-222746 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: i386-allmodconfig (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): >> ERROR: "__udivdi3" [drivers/gpu/drm/i915/i915.ko] undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- next part -- A non-text attachment was scrubbed... Name: .config.gz Type: application/octet-stream Size: 54467 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/88a99963/attachment-0001.obj>
[PATCH] drm: Remove warning from drm_connector_unregister_all()
Commit 6c87e5c3ec6d ("drm: Rename drm_connector_unplug_all() to
drm_connector_unregister_all()") replaced a manual connectors list walk
in drm_connector_unregister_all() with drm_for_each_connector(). The
list was walked without the mode config mutex locked as that ends up in
a clash with sysfs, but drm_connector_unregister_all() warns when the
mutex isn't locked.
The problem is known and doesn't require a large warning every time
drm_connector_unregister_all() is called. Fix it by reverting to manual
list walk.
Fixes: 6c87e5c3ec6d ("drm: Rename drm_connector_unplug_all() to
drm_connector_unregister_all()")
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 55ffde5a3a4a..1eab5ab472db 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1082,7 +1082,7 @@ void drm_connector_unregister_all(struct drm_device *dev)
struct drm_connector *connector;
/* FIXME: taking the mode config mutex ends up in a clash with sysfs */
- drm_for_each_connector(connector, dev)
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head)
drm_connector_unregister(connector);
}
EXPORT_SYMBOL(drm_connector_unregister_all);
--
Regards,
Laurent Pinchart
[RFC v2 1/8] drm/fb-helper: Add fb_deferred_io support
On 19 April 2016 at 01:15, Noralf Trønnes wrote: > > Den 13.04.2016 13:09, skrev Daniel Vetter: >> >> On Fri, Apr 08, 2016 at 07:05:03PM +0200, Noralf Trønnes wrote: >>> >>> This adds deferred io support if CONFIG_FB_DEFERRED_IO is enabled. >>> Accumulated fbdev framebuffer changes are signaled using the callback >>> (struct drm_framebuffer_funcs *)->dirty() >>> >>> The drm_fb_helper_sys_*() functions will accumulate changes and >>> schedule fb_info.deferred_work _if_ fb_info.fbdefio is set. >>> This worker is used by the deferred io mmap code to signal that it >>> has been collecting page faults. The page faults and/or other changes >>> are then merged into a drm_clip_rect and passed to the framebuffer >>> dirty() function. >>> >>> The driver is responsible for setting up the fb_info.fbdefio structure >>> and calling fb_deferred_io_init() using the provided callback: >>> (struct fb_info *)->fbdefio->deferred_io = drm_fb_helper_deferred_io; >>> >>> Signed-off-by: Noralf Trønnes >> >> For this one it'd be awesome to throw patches for qxl/udl on top to remove >> their own hand-rolled implementations. Just to maximize the testing >> coverage of this new code. Should be doable to set up a qxl virtual >> machine quickly, but even without that we should be able to pull it in >> (since it's mostly just about removing code from these two drivers). > > > There are three fb_deferred_io users in drivers/gpu/drm: qxl, udl and > vmwgfx. So I'm a bit confused. For me fb defio is a thing which userspace users, without an ioctl. So we keep track in the kernel of dirty pages in the fb and then flush those pages. Now the thing is that last time I tried this it interacted badly with gem/ttm as defio wanted to do something to the same pages etc. So I disabled it in udl for that reasons. if we are talking about just having some damage tracking and not doing the page level tracking then ignore me. Dave.
bug in autoloading of imx-ipuv3-crtc
Hello,
On Tue, Apr 19, 2016 at 03:16:01PM -0500, Dennis Gilmore wrote:
> On Tuesday, April 19, 2016 2:27:17 PM CDT Dennis Gilmore wrote:
> > On Tuesday, April 19, 2016 7:50:49 PM CDT Russell King - ARM Linux wrote:
> > > On Tue, Apr 19, 2016 at 01:34:23PM -0500, Dennis Gilmore wrote:
> > > > on all of my i.MX6 systems imx-ipuv3-crtc ius not getting automatically
> > > > loaded. Everything is built as a module
> > > >
> > > > CONFIG_DRM_IMX=m
> > > > CONFIG_DRM_IMX_FB_HELPER=m
> > > > CONFIG_DRM_IMX_HDMI=m
> > > > CONFIG_DRM_IMX_IPUV3=m
> > > > CONFIG_DRM_IMX_LDB=m
> > > > CONFIG_DRM_IMX_PARALLEL_DISPLAY=m
> > > > CONFIG_DRM_IMX_TVE=m
> > > > CONFIG_IMX_IPUV3_CORE=m
> > > >
> > > > The result is that until I log in via serial or ssh and modprobe the
> > > > module there is no display. I suspect that there is some devicetree
> > > > glue missing 4.4 and 4.5 seem to both be effected.
> > >
> > > DT doesn't come into it for imx-ipuv3-crtc - these platform devices are
> > > created by drivers/gpu/ipu-v3/ipu-common.c itself.
> > >
> > > drivers/gpu/drm/imx/ipuv3-crtc.c contains the proper module alias which
> > > should result in the module loaded at boot time when the imx-ipuv3-crtc
> > > devices are created.
> > >
> > > Could the problem be that imx-ipu-v3 isn't being loaded? However, again,
> > > it looks to me like everything is correct there.
> > >
> > > Are you saying that this used to work in older kernel versions like 4.3,
> > > but stopped in 4.4?
> >
> > yers it used to work and stopped working. I would need to go back and test
> > old kernels to figure out where it broke.
>
> after installing some old kernels it broke with 4.4-rc4 which included a
> patch
> with teh subject of "drm/imx: Remove of_node assignment from ipuv3-crtc
> driver
> probe"
Just to be sure: 4.4-rc4 with 407c9eba7897 ("drm/imx: Remove of_node
assignment from ipuv3-crtc driver probe") reverted works fine for you?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static void i915_oa_stream_enable(struct i915_perf_stream *stream)
> +{
> + struct drm_i915_private *dev_priv = stream->dev_priv;
> +
> + dev_priv->perf.oa.ops.oa_enable(dev_priv);
> +
> + if (dev_priv->perf.oa.periodic)
> + hrtimer_start(&dev_priv->perf.oa.poll_check_timer,
> + ns_to_ktime(POLL_PERIOD),
> + HRTIMER_MODE_REL_PINNED);
> +}
> +static void i915_oa_stream_disable(struct i915_perf_stream *stream)
> +{
> + struct drm_i915_private *dev_priv = stream->dev_priv;
> +
> + dev_priv->perf.oa.ops.oa_disable(dev_priv);
> +
> + if (dev_priv->perf.oa.periodic)
> + hrtimer_cancel(&dev_priv->perf.oa.poll_check_timer);
> +}
> +static enum hrtimer_restart oa_poll_check_timer_cb(struct hrtimer *hrtimer)
> +{
> + struct drm_i915_private *dev_priv =
> + container_of(hrtimer, typeof(*dev_priv),
> + perf.oa.poll_check_timer);
> +
> + if (!dev_priv->perf.oa.ops.oa_buffer_is_empty(dev_priv))
> + wake_up(&dev_priv->perf.oa.poll_wq);
> +
> + hrtimer_forward_now(hrtimer, ns_to_ktime(POLL_PERIOD));
> +
> + return HRTIMER_RESTART;
> +}
> @@ -424,8 +1313,37 @@ void i915_perf_init(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
>
> + if (!IS_HASWELL(dev))
> + return;
> +
> + hrtimer_init(&dev_priv->perf.oa.poll_check_timer,
> + CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> + dev_priv->perf.oa.poll_check_timer.function = oa_poll_check_timer_cb;
> + init_waitqueue_head(&dev_priv->perf.oa.poll_wq);
This timer only serves to wake up pollers / wait_unlocked, right? So why
is it always running (when the stream is enabled)?
What happens to poll / wait_unlocked if oa.periodic is not set? It seems
like those functions would block indefinitely.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit
On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> +static int hsw_enable_metric_set(struct drm_i915_private *dev_priv)
> +{
> + int ret = i915_oa_select_metric_set_hsw(dev_priv);
> +
> + if (ret)
> + return ret;
> +
> + I915_WRITE(GDT_CHICKEN_BITS, GT_NOA_ENABLE);
> +
> + /* PRM:
> + *
> + * OA unit is using âcrclkâ for its functionality. When trunk
> + * level clock gating takes place, OA clock would be gated,
> + * unable to count the events from non-render clock domain.
> + * Render clock gating must be disabled when OA is enabled to
> + * count the events from non-render domain. Unit level clock
> + * gating for RCS should also be disabled.
> + */
> + I915_WRITE(GEN7_MISCCPCTL, (I915_READ(GEN7_MISCCPCTL) &
> + ~GEN7_DOP_CLOCK_GATE_ENABLE));
> + I915_WRITE(GEN6_UCGCTL1, (I915_READ(GEN6_UCGCTL1) |
> + GEN6_CSUNIT_CLOCK_GATE_DISABLE));
> +
> + config_oa_regs(dev_priv, dev_priv->perf.oa.mux_regs,
> +dev_priv->perf.oa.mux_regs_len);
> +
> + /* It takes a fairly long time for a new MUX configuration to
> + * be be applied after these register writes. This delay
> + * duration was derived empirically based on the render_basic
> + * config but hopefully it covers the maximum configuration
> + * latency...
> + */
> + mdelay(100);
You really want to busy spin for 100ms? msleep() perhaps!
Did you look for some register you can observe the change in when the
mux is reconfigured? Is even reading one of the OA registers enough?
> + config_oa_regs(dev_priv, dev_priv->perf.oa.b_counter_regs,
> +dev_priv->perf.oa.b_counter_regs_len);
> +
> + return 0;
> +}
> +
> +static void hsw_disable_metric_set(struct drm_i915_private *dev_priv)
> +{
> + I915_WRITE(GEN6_UCGCTL1, (I915_READ(GEN6_UCGCTL1) &
> + ~GEN6_CSUNIT_CLOCK_GATE_DISABLE));
> + I915_WRITE(GEN7_MISCCPCTL, (I915_READ(GEN7_MISCCPCTL) |
> + GEN7_DOP_CLOCK_GATE_ENABLE));
> +
> + I915_WRITE(GDT_CHICKEN_BITS, (I915_READ(GDT_CHICKEN_BITS) &
> + ~GT_NOA_ENABLE));
You didn't preserve any other chicken bits during enable_metric_set.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH 0/2] Renesas R-Car Gen3 DU alpha and z-order support
Hello, This patch series implement support for alpha and z-order configuration in the R-Car DU driver for the Gen3 SoCs family. The Gen3 SoCs delegate composition to an external IP core called VSP, supported by a V4L2 driver. The DU driver interfaces with the VSP driver using direct function calls. Alpha and z-order configuration is implemented in the VSP driver, the DU driver thus just needs to pass the values using the VSP API. This series depends on a large VSP series that has been merged in the Linux media git tree for v4.7. Dave, instead of merging the media tree in your tree to pull the dependency in, it would be easier to get those two patches upstream through the media tree. I don't expect any conflict related to the DU driver for v4.7. If you're fine with that, could you ack the patches ? Laurent Pinchart (2): drm: rcar-du: Add Z-order support for VSP planes drm: rcar-du: Add alpha support for VSP planes drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 16 drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 ++ 2 files changed, 14 insertions(+), 4 deletions(-) -- Regards, Laurent Pinchart
[PATCH 2/2] drm: rcar-du: Add alpha support for VSP planes
Make the global alpha multiplier of VSP planes configurable through the
alpha property, exactly as for the native DU planes.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 62e9619eaea4..7a588f1f6d69 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -180,9 +180,9 @@ static void rcar_du_vsp_plane_setup(struct
rcar_du_vsp_plane *plane)
WARN_ON(!pixelformat);
- vsp1_du_atomic_update_zpos(plane->vsp->vsp, plane->index, pixelformat,
- fb->pitches[0], paddr, &src, &dst,
- state->zpos);
+ vsp1_du_atomic_update_ext(plane->vsp->vsp, plane->index, pixelformat,
+ fb->pitches[0], paddr, &src, &dst,
+ state->alpha, state->zpos);
}
static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
@@ -221,8 +221,8 @@ static void rcar_du_vsp_plane_atomic_update(struct
drm_plane *plane,
if (plane->state->crtc)
rcar_du_vsp_plane_setup(rplane);
else
- vsp1_du_atomic_update_zpos(rplane->vsp->vsp, rplane->index,
- 0, 0, 0, NULL, NULL, 0);
+ vsp1_du_atomic_update_ext(rplane->vsp->vsp, rplane->index,
+ 0, 0, 0, NULL, NULL, 0, 0);
}
static const struct drm_plane_helper_funcs rcar_du_vsp_plane_helper_funcs = {
--
2.7.3
[PATCH 1/2] drm: rcar-du: Add Z-order support for VSP planes
Make the Z-order of VSP planes configurable through the zpos property,
exactly as for the native DU planes.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 16
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 ++
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index de7ef041182b..62e9619eaea4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -180,8 +180,9 @@ static void rcar_du_vsp_plane_setup(struct
rcar_du_vsp_plane *plane)
WARN_ON(!pixelformat);
- vsp1_du_atomic_update(plane->vsp->vsp, plane->index, pixelformat,
- fb->pitches[0], paddr, &src, &dst);
+ vsp1_du_atomic_update_zpos(plane->vsp->vsp, plane->index, pixelformat,
+ fb->pitches[0], paddr, &src, &dst,
+ state->zpos);
}
static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
@@ -220,8 +221,8 @@ static void rcar_du_vsp_plane_atomic_update(struct
drm_plane *plane,
if (plane->state->crtc)
rcar_du_vsp_plane_setup(rplane);
else
- vsp1_du_atomic_update(rplane->vsp->vsp, rplane->index, 0, 0, 0,
- NULL, NULL);
+ vsp1_du_atomic_update_zpos(rplane->vsp->vsp, rplane->index,
+ 0, 0, 0, NULL, NULL, 0);
}
static const struct drm_plane_helper_funcs rcar_du_vsp_plane_helper_funcs = {
@@ -269,6 +270,7 @@ static void rcar_du_vsp_plane_reset(struct drm_plane *plane)
return;
state->alpha = 255;
+ state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
plane->state = &state->state;
plane->state->plane = plane;
@@ -283,6 +285,8 @@ static int rcar_du_vsp_plane_atomic_set_property(struct
drm_plane *plane,
if (property == rcdu->props.alpha)
rstate->alpha = val;
+ else if (property == rcdu->props.zpos)
+ rstate->zpos = val;
else
return -EINVAL;
@@ -299,6 +303,8 @@ static int rcar_du_vsp_plane_atomic_get_property(struct
drm_plane *plane,
if (property == rcdu->props.alpha)
*val = rstate->alpha;
+ else if (property == rcdu->props.zpos)
+ *val = rstate->zpos;
else
return -EINVAL;
@@ -378,6 +384,8 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp)
drm_object_attach_property(&plane->plane.base,
rcdu->props.alpha, 255);
+ drm_object_attach_property(&plane->plane.base,
+ rcdu->props.zpos, 1);
}
return 0;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index df3bf3805c69..510dcc9c6816 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -44,6 +44,7 @@ static inline struct rcar_du_vsp_plane
*to_rcar_vsp_plane(struct drm_plane *p)
* @state: base DRM plane state
* @format: information about the pixel format used by the plane
* @alpha: value of the plane alpha property
+ * @zpos: value of the plane zpos property
*/
struct rcar_du_vsp_plane_state {
struct drm_plane_state state;
@@ -51,6 +52,7 @@ struct rcar_du_vsp_plane_state {
const struct rcar_du_format_info *format;
unsigned int alpha;
+ unsigned int zpos;
};
static inline struct rcar_du_vsp_plane_state *
--
2.7.3
[PATCH] drm/vc4: Add support for gamma ramps.
On 21.04.2016 05:43, Eric Anholt wrote: > > This should fix brightness sliders in a lot of fullscreen games. FYI, it won't fix at least games using SDL until https://bugs.freedesktop.org/show_bug.cgi?id=27222 is fixed as well. It will sort of fix changing gamma via xgamma or RandR though. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[Bug 115251] amdgpu: Black screen + hang with Kaveri
https://bugzilla.kernel.org/show_bug.cgi?id=115251 --- Comment #3 from Bernd Steinhauser --- Ping. Was this forgotten? Afaics, it's still not applied to 4.5 stable (in 4.5.2). -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 94231] Problems compiling libdrm since glibc 2.23
https://bugs.freedesktop.org/show_bug.cgi?id=94231 --- Comment #18 from Matt Turner --- I guess you can think of this as the deprecation period. Documentation has been updated: https://github.com/mkerrisk/man-pages/commit/3350a86413d770198e11fe8df9a3cd5710240dc3 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/0b5c36da/attachment.html>
[RFC v2 1/8] drm/fb-helper: Add fb_deferred_io support
On Thu, Apr 21, 2016 at 12:29 AM, Dave Airlie wrote: > On 19 April 2016 at 01:15, Noralf Trønnes wrote: >> >> Den 13.04.2016 13:09, skrev Daniel Vetter: >>> >>> On Fri, Apr 08, 2016 at 07:05:03PM +0200, Noralf Trønnes wrote: This adds deferred io support if CONFIG_FB_DEFERRED_IO is enabled. Accumulated fbdev framebuffer changes are signaled using the callback (struct drm_framebuffer_funcs *)->dirty() The drm_fb_helper_sys_*() functions will accumulate changes and schedule fb_info.deferred_work _if_ fb_info.fbdefio is set. This worker is used by the deferred io mmap code to signal that it has been collecting page faults. The page faults and/or other changes are then merged into a drm_clip_rect and passed to the framebuffer dirty() function. The driver is responsible for setting up the fb_info.fbdefio structure and calling fb_deferred_io_init() using the provided callback: (struct fb_info *)->fbdefio->deferred_io = drm_fb_helper_deferred_io; Signed-off-by: Noralf Trønnes >>> >>> For this one it'd be awesome to throw patches for qxl/udl on top to remove >>> their own hand-rolled implementations. Just to maximize the testing >>> coverage of this new code. Should be doable to set up a qxl virtual >>> machine quickly, but even without that we should be able to pull it in >>> (since it's mostly just about removing code from these two drivers). >> >> >> There are three fb_deferred_io users in drivers/gpu/drm: qxl, udl and >> vmwgfx. > > So I'm a bit confused. For me fb defio is a thing which userspace users, > without an ioctl. > > So we keep track in the kernel of dirty pages in the fb and then flush those > pages. Now the thing is that last time I tried this it interacted badly with > gem/ttm as defio wanted to do something to the same pages etc. > > So I disabled it in udl for that reasons. > > if we are talking about just having some damage tracking and not doing > the page level tracking then ignore me. Yeah I read through the code, and with shmem it'll die because shmem and fb defio will fight over the page lru. But if you have your pages backed by cma, or the fbdev mmap pointing at an mmio range I think it should all work (and seems to at least for Noralf). Either way it's all optional opt-in code (just shared) and drivers can still opt to only do defio for in-kernel rendering and either have broken fbdev mmap support (like udl today), or implement their own defio mmap support compatible with shmem (not that hard either, but meh). And Noralf's conversion patches should result in bug-for-bug compatibility. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm: Remove warning from drm_connector_unregister_all()
On Thu, Apr 21, 2016 at 01:21:14AM +0300, Laurent Pinchart wrote:
> Commit 6c87e5c3ec6d ("drm: Rename drm_connector_unplug_all() to
> drm_connector_unregister_all()") replaced a manual connectors list walk
> in drm_connector_unregister_all() with drm_for_each_connector(). The
> list was walked without the mode config mutex locked as that ends up in
> a clash with sysfs, but drm_connector_unregister_all() warns when the
> mutex isn't locked.
>
> The problem is known and doesn't require a large warning every time
> drm_connector_unregister_all() is called. Fix it by reverting to manual
> list walk.
>
> Fixes: 6c87e5c3ec6d ("drm: Rename drm_connector_unplug_all() to
> drm_connector_unregister_all()")
> Signed-off-by: Laurent Pinchart
My apologies for missing this when reviewing the patch. Applied to
drm-misc, thanks.
-Daniel
> ---
> drivers/gpu/drm/drm_crtc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 55ffde5a3a4a..1eab5ab472db 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1082,7 +1082,7 @@ void drm_connector_unregister_all(struct drm_device
> *dev)
> struct drm_connector *connector;
>
> /* FIXME: taking the mode config mutex ends up in a clash with sysfs */
> - drm_for_each_connector(connector, dev)
> + list_for_each_entry(connector, &dev->mode_config.connector_list, head)
> drm_connector_unregister(connector);
> }
> EXPORT_SYMBOL(drm_connector_unregister_all);
> --
> Regards,
>
> Laurent Pinchart
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm/vc4: Add missing render node support
On Wed, Apr 20, 2016 at 03:20:49PM -0700, Eric Anholt wrote:
> There shouldn't be any other driver support necessary, since none of
> the driver-specific ioctls ever required auth, and none of them deal
> with modesetting.
Indeed, somehow I thought you need to mark them all up explicitly. But
that's only the case for DRM_AUTH ioctls.
Reviewed-by: Daniel Vetter
Aside: I wonder whether we should go through all the drivers and replace
DRM_AUTH | DRM_RENDER_ALLOW with 0? It looks a bit like drm ioctl flags
are cargo culted ...
-Daniel
>
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/vc4/vc4_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 54f9f52fa004..143dd98aa079 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -81,6 +81,7 @@ static struct drm_driver vc4_drm_driver = {
> DRIVER_ATOMIC |
> DRIVER_GEM |
> DRIVER_HAVE_IRQ |
> + DRIVER_RENDER |
> DRIVER_PRIME),
> .lastclose = vc4_lastclose,
> .irq_handler = vc4_irq,
> --
> 2.8.0.rc3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Intel-gfx] [PATCH 4/4] drm/i915: Move ioremap_wc tracking onto VMA
On Wed, Apr 20, 2016 at 11:27:27PM +0200, Luis R. Rodriguez wrote: > On Wed, Apr 20, 2016 at 01:17:30PM +0200, Daniel Vetter wrote: > > On Wed, Apr 20, 2016 at 11:10:54AM +0200, Luis R. Rodriguez wrote: > > > Reason I ask is since I noticed a while ago a lot of drivers > > > were using info->fix.smem_start and info->fix.smem_len consistently > > > for their ioremap'd areas it might make sense instead to let the > > > internal framebuffer (register_framebuffer()) optionally manage the > > > ioremap_wc() for drivers, given that this is pretty generic stuff. > > > > All that legacy fbdev stuff is just for legacy support, and I prefer to > > have that as dumb as possible. There's been some discussion even around > > lifting the "kick out firmware fb driver" out of fbdev, since we'd need it > > to have a simple drm driver for e.g. uefi. > > > > But I definitely don't want a legacy horror show like fbdev to > > automagically take care of device mappings for drivers. > > Makes sense, it also still begs the question if more modern APIs > could manage the ioremap for you. Evidence shows people get > sloppy and if things were done internally with helpers it may > be easier to later make adjustments. Real gpus generally have so much mmio space that you want to ioremap them on demand. At least if you still care about 32bit support. And on-die gpus on socs or similar tend to not have an mmio range to access the gfx remapping range at all, but instead expect that to be done with gpu pagetables. So at least with gpus I don't see a real demand for this, and the existing users are mostly old fbdev drivers that really no one should be touching ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 2/8] drm/udl: Change drm_fb_helper_sys_*() calls to sys_*()
On Wed, Apr 20, 2016 at 08:15:30PM +0200, Noralf Trønnes wrote:
>
> Den 20.04.2016 19:42, skrev Daniel Vetter:
> >On Wed, Apr 20, 2016 at 05:25:23PM +0200, Noralf Trønnes wrote:
> >>Now that drm_fb_helper gets deferred io support, the
> >>drm_fb_helper_sys_{fillrect,copyarea,imageblit} functions will schedule
> >>the worker that calls the deferred_io callback. This will break this
> >>driver so use the sys_{fillrect,copyarea,imageblit} functions directly.
> >>
> >>Signed-off-by: Noralf Trønnes
> >I think this intermediately breaks the build, if you disable fbdev
> >support. That's now supported in the fbdev helpers core generically across
> >all drivers.
> >
> >Not sure how to best fix this up, since the only way would be to squash
> >these patches, plus generic deferred io plus the conversion patches for
> >udl/qxl all into one. Tricky.
>
> Yes you're right, I missed that.
> How about this:
> #ifdef CONFIG_FB
> sys_fillrect(info, rect);
> #endif
>
> The later patch will then remove this ugliness...
Yeah I think we have to bite the bullet and take this temporary ugliness
:(
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 5/8] fbdev: fb_defio: Export fb_deferred_io_mmap
On Wed, Apr 20, 2016 at 08:33:17PM +0200, Noralf Trønnes wrote:
>
> Den 20.04.2016 19:44, skrev Daniel Vetter:
> >On Wed, Apr 20, 2016 at 05:25:26PM +0200, Noralf Trønnes wrote:
> >>Export fb_deferred_io_mmap so drivers can change vma->vm_page_prot.
> >>When the framebuffer memory is allocated using dma_alloc_writecombine()
> >>instead of vmalloc(), I get cache syncing problems.
> >>This solves it:
> >>
> >>static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
> >> struct vm_area_struct *vma)
> >>{
> >>fb_deferred_io_mmap(info, vma);
> >>vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> >Hm, do we need pgpropt_writecombine? There recently was some discussion
> >(on the arc platform) that fbdev pgprots need to be fixed up in fbdev
> >code. I have no idea, just repeating from memory ...
>
> I need it or else I get partial lines that doesn't get updated on the
> display.
> fbdev code that doesn't set (struct fb_ops *)->fb_mmap, gets this for free
> in the default fb_mmap implementation (drivers/video/fbdev/core/fbmem.c).
> It calls fb_pgprotect() at the end which is an architecture specific
> function that on many platforms uses pgprot_writecombine(), but not on all.
> And looking at some of the fb_mmap implementations, some of them sets
> vm_page_prot to nocache for instance, so I think the safest bet is to do
> this here and not in the fbdev core. And we can't call fb_pgprotect() from
> fb_deferred_io_mmap() either because we don't have access to the file
> pointer that powerpc needs.
> I think the case you refer to was solved with using fb_pgprotect() for
> the platform in question and it didn't involve deferred io.
Argh, oh well. I guess another case (besides the mmap thing in udl where
the default defio support from fbdev goes boom) where this isn't the most
awesome thing ever.
Please add your explanation to the commit message for posterity.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2] drm: Make drm.debug parameter description more helpful
On Wed, 20 Apr 2016, Ezequiel Garcia wrote:
> Let's be user-friendly and print an actually helpful parameter
> description.
>
> This makes modinfo output the debug parameter like this:
>
> parm: debug:Enable debug output, where each bit enables a debug
> category.
> Bit 0 (0x01) will enable CORE messages (drm core code)
> Bit 1 (0x02) will enable DRIVER messages (drm controller code)
> Bit 2 (0x04) will enable KMS messages (modesetting code)
> Bit 3 (0x08) will enable PRIME messages (prime code)
> Bit 4 (0x10) will enable ATOMIC messages (atomic code)
> Bit 5 (0x20) will enable VBL messages (vblank code) (int)
>
> Signed-off-by: Ezequiel Garcia
Reviewed-by: Jani Nikula
> --
> Changes from v1:
>
> * Fixed s/PRMIE/PRIME typo.
> * Add ATOMIC and VBL debug parameter documentation.
> * Prefix the continuation lines with two tabs and
> removed the last new line.
> * Remove spurious whitespace.
>
> drivers/gpu/drm/drm_drv.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 167c8d3d4a31..c4f45ac04ea4 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -37,13 +37,23 @@
> #include "drm_legacy.h"
> #include "drm_internal.h"
>
> -unsigned int drm_debug = 0; /* bitmask of DRM_UT_x */
> +/*
> + * drm_debug: Enable debug output.
> + * Bitmask of DRM_UT_x. See include/drm/drmP.h for details.
> + */
> +unsigned int drm_debug = 0;
> EXPORT_SYMBOL(drm_debug);
>
> MODULE_AUTHOR(CORE_AUTHOR);
> MODULE_DESCRIPTION(CORE_DESC);
> MODULE_LICENSE("GPL and additional rights");
> -MODULE_PARM_DESC(debug, "Enable debug output");
> +MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a debug
> category.\n"
> +"\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n"
> +"\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n"
> +"\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n"
> +"\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n"
> +"\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n"
> +"\t\tBit 5 (0x20) will enable VBL messages (vblank code)");
> module_param_named(debug, drm_debug, int, 0600);
>
> static DEFINE_SPINLOCK(drm_minor_lock);
--
Jani Nikula, Intel Open Source Technology Center
[PULL] drm-intel-fixes
Hi Dave, fixes all around, all but one are cc: stable material, the most important ones are likely the Skylake hang fixes from Mika. BR, Jani. The following changes since commit c3b46c73264b03000d1e18b22f5caf63332547c9: Linux 4.6-rc4 (2016-04-17 19:13:32 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-04-21 for you to fetch changes up to 31318a922395ec9e78d6e2ddf70779355afc7594: drm/i915: Use fw_domains_put_with_fifo() on HSW (2016-04-18 12:35:51 +0300) Akash Goel (1): drm/i915: Fixup the free space logic in ring_prepare Chris Wilson (2): drm/i915/userptr: Hold mmref whilst calling get-user-pages drm/i915: Force ringbuffers to not be at offset 0 Kumar, Mahesh (1): drm/i915/skl+: Use plane size for relative data rate calculation MichaŠWiniarski (1): drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno write Mika Kuoppala (2): drm/i915/skl: Fix rc6 based gpu/system hang drm/i915/skl: Fix spurious gpu hang with gt3/gt4 revs Ville Syrjälä (1): drm/i915: Use fw_domains_put_with_fifo() on HSW drivers/gpu/drm/i915/i915_drv.h | 5 ++-- drivers/gpu/drm/i915/i915_gem_userptr.c | 29 +-- drivers/gpu/drm/i915/intel_lrc.c| 16 + drivers/gpu/drm/i915/intel_pm.c | 42 ++--- drivers/gpu/drm/i915/intel_ringbuffer.c | 18 -- drivers/gpu/drm/i915/intel_uncore.c | 6 - 6 files changed, 75 insertions(+), 41 deletions(-) -- Jani Nikula, Intel Open Source Technology Center
[PATCH 7/8] drm/qxl: Use drm_fb_helper deferred_io support
On Wed, Apr 20, 2016 at 09:04:38PM +0200, Noralf Trønnes wrote:
>
> Den 20.04.2016 19:47, skrev Daniel Vetter:
> >On Wed, Apr 20, 2016 at 05:25:28PM +0200, Noralf Trønnes wrote:
> >>Use the fbdev deferred io support in drm_fb_helper.
> >>The (struct fb_ops *)->fb_{fillrect,copyarea,imageblit} functions will
> >>now be deferred in the same way that mmap damage is, instead of being
> >>flushed directly.
> >>This patch has only been compile tested.
> >>
> >>Signed-off-by: Noralf Trønnes
> >>---
> >> drivers/gpu/drm/qxl/qxl_display.c | 9 +-
> >> drivers/gpu/drm/qxl/qxl_drv.h | 7 +-
> >> drivers/gpu/drm/qxl/qxl_fb.c | 220
> >> ++
> >> drivers/gpu/drm/qxl/qxl_kms.c | 4 -
> >> 4 files changed, 62 insertions(+), 178 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> >>b/drivers/gpu/drm/qxl/qxl_display.c
> >>index 030409a..9a03524 100644
> >>--- a/drivers/gpu/drm/qxl/qxl_display.c
> >>+++ b/drivers/gpu/drm/qxl/qxl_display.c
> >>@@ -465,7 +465,7 @@ static const struct drm_crtc_funcs qxl_crtc_funcs = {
> >>.page_flip = qxl_crtc_page_flip,
> >> };
> >>-static void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
> >>+void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
> >> {
> >>struct qxl_framebuffer *qxl_fb = to_qxl_framebuffer(fb);
> >>@@ -527,12 +527,13 @@ int
> >> qxl_framebuffer_init(struct drm_device *dev,
> >> struct qxl_framebuffer *qfb,
> >> const struct drm_mode_fb_cmd2 *mode_cmd,
> >>-struct drm_gem_object *obj)
> >>+struct drm_gem_object *obj,
> >>+const struct drm_framebuffer_funcs *funcs)
> >There should be no need at all to have a separate fb funcs table for the
> >fbdev fb. Both /should/ be able to use the exact same (already existing)
> >->dirty() callback. We need this only in CMA because CMA is a midlayer
> >used by multiple drivers.
>
> I don't see how I can avoid it.
>
> fbdev framebuffer flushing:
>
> static void qxl_fb_dirty_flush(struct fb_info *info)
> {
> qxl_fb_image_init(&qxl_fb_image, qdev, info, NULL);
> qxl_draw_opaque_fb(&qxl_fb_image, stride);
> }
>
> drm framebuffer flushing:
>
> static int qxl_framebuffer_surface_dirty(...)
> {
> qxl_draw_dirty_fb(...);
> }
>
> qxl_draw_opaque_fb() and qxl_draw_dirty_fb() differ so much that it's way
> over my head to see if they can be combined.
> Here's an online diff of the two functions:
> https://www.diffchecker.com/jqbbalux
Imo nuke the fbdev one entirely. If it breaks then it's either a bug in
your generic fbdefio code, or the qxl ->dirty implementation has a bug. It
should work ;-)
Ok, slightly more seriously the difference seems to be that the fbdev one
support paletted mode too. But since qxl has 0 pixel format checking
anywhere I have no idea whether that's dead code (i.e. broken) or actually
working. I guess keeping the split is ok, if we add a big FIXME comment to
it that this is very fishy.
-Daniel
>
>
> >
> >With that change you should be able to condense this patch down to pretty
> >much just removing lines. Which is Good (tm).
> >
> >Cheers, Daniel
> >
> >> {
> >>int ret;
> >>qfb->obj = obj;
> >>- ret = drm_framebuffer_init(dev, &qfb->base, &qxl_fb_funcs);
> >>+ ret = drm_framebuffer_init(dev, &qfb->base, funcs);
> >>if (ret) {
> >>qfb->obj = NULL;
> >>return ret;
> >>@@ -999,7 +1000,7 @@ qxl_user_framebuffer_create(struct drm_device *dev,
> >>if (qxl_fb == NULL)
> >>return NULL;
> >>- ret = qxl_framebuffer_init(dev, qxl_fb, mode_cmd, obj);
> >>+ ret = qxl_framebuffer_init(dev, qxl_fb, mode_cmd, obj, &qxl_fb_funcs);
> >>if (ret) {
> >>kfree(qxl_fb);
> >>drm_gem_object_unreference_unlocked(obj);
> >>diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
> >>index 3f3897e..3ad6604 100644
> >>--- a/drivers/gpu/drm/qxl/qxl_drv.h
> >>+++ b/drivers/gpu/drm/qxl/qxl_drv.h
> >>@@ -324,8 +324,6 @@ struct qxl_device {
> >>struct workqueue_struct *gc_queue;
> >>struct work_struct gc_work;
> >>- struct work_struct fb_work;
> >>-
> >>struct drm_property *hotplug_mode_update_property;
> >>int monitors_config_width;
> >>int monitors_config_height;
> >>@@ -389,11 +387,13 @@ int qxl_get_handle_for_primary_fb(struct qxl_device
> >>*qdev,
> >> void qxl_fbdev_set_suspend(struct qxl_device *qdev, int state);
> >> /* qxl_display.c */
> >>+void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb);
> >> int
> >> qxl_framebuffer_init(struct drm_device *dev,
> >> struct qxl_framebuffer *rfb,
> >> const struct drm_mode_fb_cmd2 *mode_cmd,
> >>-struct drm_gem_object *obj);
> >>+struct drm_gem_object *obj,
> >>+const struct drm_framebuffer_funcs *funcs);
> >> void qxl_display_read_client_monitors_config(struct qxl_devi
[PATCH v2] drm/dsi: Implement set tear scanline compile fix
Provide a small convenience wrapper that transmits
a set_tear_scanline command.
Cc: Archit Taneja
Cc: Sumit Semwal
Cc: John Stultz
Cc: Thierry Reding
Signed-off-by: Vinay Simha BN
---
drivers/gpu/drm/drm_mipi_dsi.c | 23 +++
include/drm/drm_mipi_dsi.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index f5d8083..2f0b85c 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -983,6 +983,29 @@ int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
EXPORT_SYMBOL(mipi_dsi_dcs_set_tear_on);
/**
+ * mipi_dsi_set_tear_scanline() - turn on the display module's Tearing Effect
+ * output signal on the TE signal line when display module reaches line N
+ * defined by STS[n:0].
+ * @dsi: DSI peripheral device
+ * @param1: STS[10:8]
+ * @param2: STS[7:0]
+ * Return: 0 on success or a negative error code on failure
+ */
+int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi,
+ u8 param1, u8 param2)
+{
+ u8 payload[3] = { MIPI_DCS_SET_TEAR_SCANLINE, param1, param2};
+ ssize_t err;
+
+ err = mipi_dsi_generic_write(dsi, &payload, sizeof(payload));
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_set_tear_scanline);
+
+/**
* mipi_dsi_dcs_set_pixel_format() - sets the pixel format for the RGB image
*data used by the interface
* @dsi: DSI peripheral device
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 7a9840f..2788dbe 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -263,6 +263,8 @@ int mipi_dsi_dcs_set_column_address(struct mipi_dsi_device
*dsi, u16 start,
u16 end);
int mipi_dsi_dcs_set_page_address(struct mipi_dsi_device *dsi, u16 start,
u16 end);
+int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi, u8 param1,
+ u8 param2);
int mipi_dsi_dcs_set_tear_off(struct mipi_dsi_device *dsi);
int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
enum mipi_dsi_dcs_tear_mode mode);
--
2.1.2
libdrm: Patch to compile on hurd.
Hallo, attached is a patch that makes libdrm compile on hurd. (Note: I intentionally said compile, as I have no way to see if it actually works there.) The patch is created in a way to be neutral on all other archs; it is mostly about PATH_MAX, which does not exist on that arch. Maybe you find the patch useful. Thanks! -- -- next part -- A non-text attachment was scrubbed... Name: 02_hurd.patch Type: text/x-patch Size: 3828 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/d31f65e6/attachment-0001.bin>
[PATCH v3] drm/dsi: Implement set tear scanline
Provide a small convenience wrapper that transmits
a set_tear_scanline command.
Cc: Archit Taneja
Cc: John Stultz
[thierry.reding: suggested to create helper function (v1)]
Cc: Thierry Reding
[sumit.semwal: create a single patch for compilation fix (v2)]
Cc: Sumit Semwal
[vinay simha bn: subject line changed (v3)]
Signed-off-by: Vinay Simha BN
---
drivers/gpu/drm/drm_mipi_dsi.c | 23 +++
include/drm/drm_mipi_dsi.h | 2 ++
2 files changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index f5d8083..2f0b85c 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -983,6 +983,29 @@ int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
EXPORT_SYMBOL(mipi_dsi_dcs_set_tear_on);
/**
+ * mipi_dsi_set_tear_scanline() - turn on the display module's Tearing Effect
+ * output signal on the TE signal line when display module reaches line N
+ * defined by STS[n:0].
+ * @dsi: DSI peripheral device
+ * @param1: STS[10:8]
+ * @param2: STS[7:0]
+ * Return: 0 on success or a negative error code on failure
+ */
+int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi,
+ u8 param1, u8 param2)
+{
+ u8 payload[3] = { MIPI_DCS_SET_TEAR_SCANLINE, param1, param2};
+ ssize_t err;
+
+ err = mipi_dsi_generic_write(dsi, &payload, sizeof(payload));
+ if (err < 0)
+ return err;
+
+ return 0;
+}
+EXPORT_SYMBOL(mipi_dsi_set_tear_scanline);
+
+/**
* mipi_dsi_dcs_set_pixel_format() - sets the pixel format for the RGB image
*data used by the interface
* @dsi: DSI peripheral device
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 7a9840f..2788dbe 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -263,6 +263,8 @@ int mipi_dsi_dcs_set_column_address(struct mipi_dsi_device
*dsi, u16 start,
u16 end);
int mipi_dsi_dcs_set_page_address(struct mipi_dsi_device *dsi, u16 start,
u16 end);
+int mipi_dsi_set_tear_scanline(struct mipi_dsi_device *dsi, u8 param1,
+ u8 param2);
int mipi_dsi_dcs_set_tear_off(struct mipi_dsi_device *dsi);
int mipi_dsi_dcs_set_tear_on(struct mipi_dsi_device *dsi,
enum mipi_dsi_dcs_tear_mode mode);
--
2.1.2
[PATCH 7/8] drm/qxl: Use drm_fb_helper deferred_io support
On Thu, Apr 21, 2016 at 09:41:34AM +0200, Daniel Vetter wrote:
> On Wed, Apr 20, 2016 at 09:04:38PM +0200, Noralf Trønnes wrote:
> >
> > Den 20.04.2016 19:47, skrev Daniel Vetter:
> > >On Wed, Apr 20, 2016 at 05:25:28PM +0200, Noralf Trønnes wrote:
> > >>Use the fbdev deferred io support in drm_fb_helper.
> > >>The (struct fb_ops *)->fb_{fillrect,copyarea,imageblit} functions will
> > >>now be deferred in the same way that mmap damage is, instead of being
> > >>flushed directly.
> > >>This patch has only been compile tested.
> > >>
> > >>Signed-off-by: Noralf Trønnes
> > >>---
> > >> drivers/gpu/drm/qxl/qxl_display.c | 9 +-
> > >> drivers/gpu/drm/qxl/qxl_drv.h | 7 +-
> > >> drivers/gpu/drm/qxl/qxl_fb.c | 220
> > >> ++
> > >> drivers/gpu/drm/qxl/qxl_kms.c | 4 -
> > >> 4 files changed, 62 insertions(+), 178 deletions(-)
> > >>
> > >>diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> > >>b/drivers/gpu/drm/qxl/qxl_display.c
> > >>index 030409a..9a03524 100644
> > >>--- a/drivers/gpu/drm/qxl/qxl_display.c
> > >>+++ b/drivers/gpu/drm/qxl/qxl_display.c
> > >>@@ -465,7 +465,7 @@ static const struct drm_crtc_funcs qxl_crtc_funcs = {
> > >> .page_flip = qxl_crtc_page_flip,
> > >> };
> > >>-static void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
> > >>+void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
> > >> {
> > >> struct qxl_framebuffer *qxl_fb = to_qxl_framebuffer(fb);
> > >>@@ -527,12 +527,13 @@ int
> > >> qxl_framebuffer_init(struct drm_device *dev,
> > >> struct qxl_framebuffer *qfb,
> > >> const struct drm_mode_fb_cmd2 *mode_cmd,
> > >>- struct drm_gem_object *obj)
> > >>+ struct drm_gem_object *obj,
> > >>+ const struct drm_framebuffer_funcs *funcs)
> > >There should be no need at all to have a separate fb funcs table for the
> > >fbdev fb. Both /should/ be able to use the exact same (already existing)
> > >->dirty() callback. We need this only in CMA because CMA is a midlayer
> > >used by multiple drivers.
> >
> > I don't see how I can avoid it.
> >
> > fbdev framebuffer flushing:
> >
> > static void qxl_fb_dirty_flush(struct fb_info *info)
> > {
> > qxl_fb_image_init(&qxl_fb_image, qdev, info, NULL);
> > qxl_draw_opaque_fb(&qxl_fb_image, stride);
> > }
> >
> > drm framebuffer flushing:
> >
> > static int qxl_framebuffer_surface_dirty(...)
> > {
> > qxl_draw_dirty_fb(...);
> > }
> >
> > qxl_draw_opaque_fb() and qxl_draw_dirty_fb() differ so much that it's way
> > over my head to see if they can be combined.
> > Here's an online diff of the two functions:
> > https://www.diffchecker.com/jqbbalux
>
> Imo nuke the fbdev one entirely. If it breaks then it's either a bug in
> your generic fbdefio code, or the qxl ->dirty implementation has a bug. It
> should work ;-)
>
> Ok, slightly more seriously the difference seems to be that the fbdev one
> support paletted mode too. But since qxl has 0 pixel format checking
> anywhere I have no idea whether that's dead code (i.e. broken) or actually
> working. I guess keeping the split is ok, if we add a big FIXME comment to
> it that this is very fishy.
Ok, I read around a bit more. The only things qxl seems to support are
bits_per_pixel of 1, 24 and 32 (see qxl_image_init_helper). And drm has no
way to pass in 1 bpp images. And it doesn't support 8 bit paletted, which
is the only paletted thing drm supports.
So if you totally feel like I think we could add format checking for
DRM_FORMAT_XRGB and DRM_FORMAT_RGB888 in qxl_framebuffer_init and then
rip out all that code. But that's a few more patches and probably should
be tested actually ;-)
FIXME plus explaing it all in the commit message is fine with me too.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2] drm: Make drm.debug parameter description more helpful
On Thu, Apr 21, 2016 at 10:32:11AM +0300, Jani Nikula wrote:
> On Wed, 20 Apr 2016, Ezequiel Garcia wrote:
> > Let's be user-friendly and print an actually helpful parameter
> > description.
> >
> > This makes modinfo output the debug parameter like this:
> >
> > parm: debug:Enable debug output, where each bit enables a debug
> > category.
> > Bit 0 (0x01) will enable CORE messages (drm core code)
> > Bit 1 (0x02) will enable DRIVER messages (drm controller code)
> > Bit 2 (0x04) will enable KMS messages (modesetting code)
> > Bit 3 (0x08) will enable PRIME messages (prime code)
> > Bit 4 (0x10) will enable ATOMIC messages (atomic code)
> > Bit 5 (0x20) will enable VBL messages (vblank code) (int)
> >
> > Signed-off-by: Ezequiel Garcia
>
> Reviewed-by: Jani Nikula
Applied to drm-misc, thanks.
-Daniel
>
>
>
> > --
> > Changes from v1:
> >
> > * Fixed s/PRMIE/PRIME typo.
> > * Add ATOMIC and VBL debug parameter documentation.
> > * Prefix the continuation lines with two tabs and
> > removed the last new line.
> > * Remove spurious whitespace.
> >
> > drivers/gpu/drm/drm_drv.c | 14 --
> > 1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 167c8d3d4a31..c4f45ac04ea4 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -37,13 +37,23 @@
> > #include "drm_legacy.h"
> > #include "drm_internal.h"
> >
> > -unsigned int drm_debug = 0;/* bitmask of DRM_UT_x */
> > +/*
> > + * drm_debug: Enable debug output.
> > + * Bitmask of DRM_UT_x. See include/drm/drmP.h for details.
> > + */
> > +unsigned int drm_debug = 0;
> > EXPORT_SYMBOL(drm_debug);
> >
> > MODULE_AUTHOR(CORE_AUTHOR);
> > MODULE_DESCRIPTION(CORE_DESC);
> > MODULE_LICENSE("GPL and additional rights");
> > -MODULE_PARM_DESC(debug, "Enable debug output");
> > +MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a
> > debug category.\n"
> > +"\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n"
> > +"\t\tBit 1 (0x02) will enable DRIVER messages (drm controller code)\n"
> > +"\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n"
> > +"\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n"
> > +"\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n"
> > +"\t\tBit 5 (0x20) will enable VBL messages (vblank code)");
> > module_param_named(debug, drm_debug, int, 0600);
> >
> > static DEFINE_SPINLOCK(drm_minor_lock);
>
> --
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 7/8] drm/qxl: Use drm_fb_helper deferred_io support
On Thu, Apr 21, 2016 at 09:49:39AM +0200, Daniel Vetter wrote:
> On Thu, Apr 21, 2016 at 09:41:34AM +0200, Daniel Vetter wrote:
> > On Wed, Apr 20, 2016 at 09:04:38PM +0200, Noralf Trønnes wrote:
> > >
> > > Den 20.04.2016 19:47, skrev Daniel Vetter:
> > > >On Wed, Apr 20, 2016 at 05:25:28PM +0200, Noralf Trønnes wrote:
> > > >>Use the fbdev deferred io support in drm_fb_helper.
> > > >>The (struct fb_ops *)->fb_{fillrect,copyarea,imageblit} functions will
> > > >>now be deferred in the same way that mmap damage is, instead of being
> > > >>flushed directly.
> > > >>This patch has only been compile tested.
> > > >>
> > > >>Signed-off-by: Noralf Trønnes
> > > >>---
> > > >> drivers/gpu/drm/qxl/qxl_display.c | 9 +-
> > > >> drivers/gpu/drm/qxl/qxl_drv.h | 7 +-
> > > >> drivers/gpu/drm/qxl/qxl_fb.c | 220
> > > >> ++
> > > >> drivers/gpu/drm/qxl/qxl_kms.c | 4 -
> > > >> 4 files changed, 62 insertions(+), 178 deletions(-)
> > > >>
> > > >>diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> > > >>b/drivers/gpu/drm/qxl/qxl_display.c
> > > >>index 030409a..9a03524 100644
> > > >>--- a/drivers/gpu/drm/qxl/qxl_display.c
> > > >>+++ b/drivers/gpu/drm/qxl/qxl_display.c
> > > >>@@ -465,7 +465,7 @@ static const struct drm_crtc_funcs qxl_crtc_funcs =
> > > >>{
> > > >>.page_flip = qxl_crtc_page_flip,
> > > >> };
> > > >>-static void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
> > > >>+void qxl_user_framebuffer_destroy(struct drm_framebuffer *fb)
> > > >> {
> > > >>struct qxl_framebuffer *qxl_fb = to_qxl_framebuffer(fb);
> > > >>@@ -527,12 +527,13 @@ int
> > > >> qxl_framebuffer_init(struct drm_device *dev,
> > > >> struct qxl_framebuffer *qfb,
> > > >> const struct drm_mode_fb_cmd2 *mode_cmd,
> > > >>-struct drm_gem_object *obj)
> > > >>+struct drm_gem_object *obj,
> > > >>+const struct drm_framebuffer_funcs *funcs)
> > > >There should be no need at all to have a separate fb funcs table for the
> > > >fbdev fb. Both /should/ be able to use the exact same (already existing)
> > > >->dirty() callback. We need this only in CMA because CMA is a midlayer
> > > >used by multiple drivers.
> > >
> > > I don't see how I can avoid it.
> > >
> > > fbdev framebuffer flushing:
> > >
> > > static void qxl_fb_dirty_flush(struct fb_info *info)
> > > {
> > > qxl_fb_image_init(&qxl_fb_image, qdev, info, NULL);
> > > qxl_draw_opaque_fb(&qxl_fb_image, stride);
> > > }
> > >
> > > drm framebuffer flushing:
> > >
> > > static int qxl_framebuffer_surface_dirty(...)
> > > {
> > > qxl_draw_dirty_fb(...);
> > > }
> > >
> > > qxl_draw_opaque_fb() and qxl_draw_dirty_fb() differ so much that it's way
> > > over my head to see if they can be combined.
> > > Here's an online diff of the two functions:
> > > https://www.diffchecker.com/jqbbalux
> >
> > Imo nuke the fbdev one entirely. If it breaks then it's either a bug in
> > your generic fbdefio code, or the qxl ->dirty implementation has a bug. It
> > should work ;-)
> >
> > Ok, slightly more seriously the difference seems to be that the fbdev one
> > support paletted mode too. But since qxl has 0 pixel format checking
> > anywhere I have no idea whether that's dead code (i.e. broken) or actually
> > working. I guess keeping the split is ok, if we add a big FIXME comment to
> > it that this is very fishy.
>
> Ok, I read around a bit more. The only things qxl seems to support are
> bits_per_pixel of 1, 24 and 32 (see qxl_image_init_helper). And drm has no
> way to pass in 1 bpp images. And it doesn't support 8 bit paletted, which
> is the only paletted thing drm supports.
>
> So if you totally feel like I think we could add format checking for
> DRM_FORMAT_XRGB and DRM_FORMAT_RGB888 in qxl_framebuffer_init and then
> rip out all that code. But that's a few more patches and probably should
> be tested actually ;-)
Even simpler: Check for bits_per_pixel == 24 || 32, since that matches the
only other check in qxl. Extremely unlikely qxl supports all these
formats, but meh ...
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 01/15] drm/mode: rework drm_mode_object_put to drm_mode_object_unregister.
On Fri, Apr 15, 2016 at 03:10:32PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This changes the code to handle being called multiple times without
> side effects. The new names seems more suitable for what it does.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 37
> +
> drivers/gpu/drm/drm_crtc_internal.h | 4 ++--
> drivers/gpu/drm/drm_modes.c | 2 +-
> 3 files changed, 24 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index e08f962..21cb8dc 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -323,19 +323,24 @@ static void drm_mode_object_register(struct drm_device
> *dev,
> }
>
> /**
> - * drm_mode_object_put - free a modeset identifer
> + * drm_mode_object_unregister - free a modeset identifer
> * @dev: DRM device
> * @object: object to free
> *
> - * Free @id from @dev's unique identifier pool. Note that despite the _get
> - * postfix modeset identifiers are _not_ reference counted. Hence don't use
> this
> + * Free @id from @dev's unique identifier pool.
> + * This function can be called multiple times, and guards against
> + * multiple removals.
> + * These modeset identifiers are _not_ reference counted. Hence don't use
> this
> * for reference counted modeset objects like framebuffers.
> */
> -void drm_mode_object_put(struct drm_device *dev,
> +void drm_mode_object_unregister(struct drm_device *dev,
>struct drm_mode_object *object)
> {
> mutex_lock(&dev->mode_config.idr_mutex);
> - idr_remove(&dev->mode_config.crtc_idr, object->id);
> + if (object->id) {
> + idr_remove(&dev->mode_config.crtc_idr, object->id);
> + object->id = 0;
> + }
> mutex_unlock(&dev->mode_config.idr_mutex);
> }
>
> @@ -705,7 +710,7 @@ int drm_crtc_init_with_planes(struct drm_device *dev,
> struct drm_crtc *crtc,
> drm_num_crtcs(dev));
> }
> if (!crtc->name) {
> - drm_mode_object_put(dev, &crtc->base);
> + drm_mode_object_unregister(dev, &crtc->base);
> return -ENOMEM;
> }
>
> @@ -747,7 +752,7 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
>
> drm_modeset_lock_fini(&crtc->mutex);
>
> - drm_mode_object_put(dev, &crtc->base);
> + drm_mode_object_unregister(dev, &crtc->base);
> list_del(&crtc->head);
> dev->mode_config.num_crtc--;
>
> @@ -972,7 +977,7 @@ out_put_id:
> ida_remove(&config->connector_ida, connector->connector_id);
> out_put:
> if (ret)
> - drm_mode_object_put(dev, &connector->base);
> + drm_mode_object_unregister(dev, &connector->base);
>
> out_unlock:
> drm_modeset_unlock_all(dev);
> @@ -1010,7 +1015,7 @@ void drm_connector_cleanup(struct drm_connector
> *connector)
> connector->connector_id);
>
> kfree(connector->display_info.bus_formats);
> - drm_mode_object_put(dev, &connector->base);
> + drm_mode_object_unregister(dev, &connector->base);
> kfree(connector->name);
> connector->name = NULL;
> list_del(&connector->head);
> @@ -1138,7 +1143,7 @@ int drm_encoder_init(struct drm_device *dev,
>
> out_put:
> if (ret)
> - drm_mode_object_put(dev, &encoder->base);
> + drm_mode_object_unregister(dev, &encoder->base);
>
> out_unlock:
> drm_modeset_unlock_all(dev);
> @@ -1181,7 +1186,7 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
> struct drm_device *dev = encoder->dev;
>
> drm_modeset_lock_all(dev);
> - drm_mode_object_put(dev, &encoder->base);
> + drm_mode_object_unregister(dev, &encoder->base);
> kfree(encoder->name);
> list_del(&encoder->head);
> dev->mode_config.num_encoder--;
> @@ -1242,7 +1247,7 @@ int drm_universal_plane_init(struct drm_device *dev,
> struct drm_plane *plane,
> GFP_KERNEL);
> if (!plane->format_types) {
> DRM_DEBUG_KMS("out of memory when allocating plane\n");
> - drm_mode_object_put(dev, &plane->base);
> + drm_mode_object_unregister(dev, &plane->base);
> return -ENOMEM;
> }
>
> @@ -1258,7 +1263,7 @@ int drm_universal_plane_init(struct drm_device *dev,
> struct drm_plane *plane,
> }
> if (!plane->name) {
> kfree(plane->format_types);
> - drm_mode_object_put(dev, &plane->base);
> + drm_mode_object_unregister(dev, &plane->base);
> return -ENOMEM;
> }
>
> @@ -1338,7 +1343,7 @@ void drm_plane_cleanup(struct drm_plane *plane)
>
> drm_modeset_lock_all(dev);
> kfree(plane->format_types);
> - drm_mode_object_put(dev, &plane->base);
> + drm_mode_object_unregister(dev, &plane->base);
>
>
[PATCH 02/15] drm/mode: move framebuffer_free up above framebuffer_init
On Fri, Apr 15, 2016 at 03:10:33PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> A later patch will use it in framebuffer_init, and I want
> to keep the diff cleaner.
>
> Signed-off-by: Dave Airlie
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 58
> +++---
> 1 file changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 21cb8dc..e69aac4 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -389,6 +389,35 @@ struct drm_mode_object *drm_mode_object_find(struct
> drm_device *dev,
> }
> EXPORT_SYMBOL(drm_mode_object_find);
>
> +/* dev->mode_config.fb_lock must be held! */
> +static void __drm_framebuffer_unregister(struct drm_device *dev,
> + struct drm_framebuffer *fb)
> +{
> + drm_mode_object_put(dev, &fb->base);
> +
> + fb->base.id = 0;
> +}
> +
> +static void drm_framebuffer_free(struct kref *kref)
> +{
> + struct drm_framebuffer *fb =
> + container_of(kref, struct drm_framebuffer, refcount);
> + struct drm_device *dev = fb->dev;
> +
> + /*
> + * The lookup idr holds a weak reference, which has not necessarily been
> + * removed at this point. Check for that.
> + */
> + mutex_lock(&dev->mode_config.fb_lock);
> + if (fb->base.id) {
> + /* Mark fb as reaped and drop idr ref. */
> + __drm_framebuffer_unregister(dev, fb);
> + }
> + mutex_unlock(&dev->mode_config.fb_lock);
> +
> + fb->funcs->destroy(fb);
> +}
> +
> /**
> * drm_framebuffer_init - initialize a framebuffer
> * @dev: DRM device
> @@ -431,35 +460,6 @@ out:
> }
> EXPORT_SYMBOL(drm_framebuffer_init);
>
> -/* dev->mode_config.fb_lock must be held! */
> -static void __drm_framebuffer_unregister(struct drm_device *dev,
> - struct drm_framebuffer *fb)
> -{
> - drm_mode_object_put(dev, &fb->base);
> -
> - fb->base.id = 0;
> -}
> -
> -static void drm_framebuffer_free(struct kref *kref)
> -{
> - struct drm_framebuffer *fb =
> - container_of(kref, struct drm_framebuffer, refcount);
> - struct drm_device *dev = fb->dev;
> -
> - /*
> - * The lookup idr holds a weak reference, which has not necessarily been
> - * removed at this point. Check for that.
> - */
> - mutex_lock(&dev->mode_config.fb_lock);
> - if (fb->base.id) {
> - /* Mark fb as reaped and drop idr ref. */
> - __drm_framebuffer_unregister(dev, fb);
> - }
> - mutex_unlock(&dev->mode_config.fb_lock);
> -
> - fb->funcs->destroy(fb);
> -}
> -
> static struct drm_framebuffer *__drm_framebuffer_lookup(struct drm_device
> *dev,
> uint32_t id)
> {
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 03/15] drm/modes: drop __drm_framebuffer_unregister.
On Fri, Apr 15, 2016 at 03:10:34PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Just use the generic function.
>
> Signed-off-by: Dave Airlie
Maybe mention in the commit message that a side effect of this is that we
now also protect fb->base.id (at least when we clear it) with the idr
mutex.
Either way: Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 16 ++--
> 1 file changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index e69aac4..0ad1a92 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -389,15 +389,6 @@ struct drm_mode_object *drm_mode_object_find(struct
> drm_device *dev,
> }
> EXPORT_SYMBOL(drm_mode_object_find);
>
> -/* dev->mode_config.fb_lock must be held! */
> -static void __drm_framebuffer_unregister(struct drm_device *dev,
> - struct drm_framebuffer *fb)
> -{
> - drm_mode_object_put(dev, &fb->base);
> -
> - fb->base.id = 0;
> -}
> -
> static void drm_framebuffer_free(struct kref *kref)
> {
> struct drm_framebuffer *fb =
> @@ -409,10 +400,7 @@ static void drm_framebuffer_free(struct kref *kref)
>* removed at this point. Check for that.
>*/
> mutex_lock(&dev->mode_config.fb_lock);
> - if (fb->base.id) {
> - /* Mark fb as reaped and drop idr ref. */
> - __drm_framebuffer_unregister(dev, fb);
> - }
> + drm_mode_object_unregister(dev, &fb->base);
> mutex_unlock(&dev->mode_config.fb_lock);
>
> fb->funcs->destroy(fb);
> @@ -549,7 +537,7 @@ void drm_framebuffer_unregister_private(struct
> drm_framebuffer *fb)
>
> mutex_lock(&dev->mode_config.fb_lock);
> /* Mark fb as reaped and drop idr ref. */
> - __drm_framebuffer_unregister(dev, fb);
> + drm_mode_object_unregister(dev, &fb->base);
> mutex_unlock(&dev->mode_config.fb_lock);
> }
> EXPORT_SYMBOL(drm_framebuffer_unregister_private);
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 04/15] drm/mode: introduce wrapper to read framebuffer refcount.
On Fri, Apr 15, 2016 at 03:10:35PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Avoids drivers knowing where the kref is stored.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 2 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
> drivers/gpu/drm/msm/msm_fb.c| 2 +-
> drivers/gpu/drm/tegra/drm.c | 2 +-
> include/drm/drm_crtc.h | 5 +
> 5 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 0ad1a92..8616737 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -612,7 +612,7 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
>* in-use fb with fb-id == 0. Userspace is allowed to shoot its own foot
>* in this manner.
>*/
> - if (atomic_read(&fb->refcount.refcount) > 1) {
> + if (drm_framebuffer_read_refcount(fb) > 1) {
> drm_modeset_lock_all(dev);
> /* remove from any CRTC */
> drm_for_each_crtc(crtc, dev) {
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index a0f1bd7..20d9300 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1908,7 +1908,7 @@ static int i915_gem_framebuffer_info(struct seq_file
> *m, void *data)
> fbdev_fb->base.depth,
> fbdev_fb->base.bits_per_pixel,
> fbdev_fb->base.modifier[0],
> - atomic_read(&fbdev_fb->base.refcount.refcount));
> + drm_framebuffer_read_refcount(&fbdev_fb->base));
> describe_obj(m, fbdev_fb->obj);
> seq_putc(m, '\n');
> }
> @@ -1926,7 +1926,7 @@ static int i915_gem_framebuffer_info(struct seq_file
> *m, void *data)
> fb->base.depth,
> fb->base.bits_per_pixel,
> fb->base.modifier[0],
> -atomic_read(&fb->base.refcount.refcount));
> +drm_framebuffer_read_refcount(&fb->base));
> describe_obj(m, fb->obj);
> seq_putc(m, '\n');
> }
> diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c
> index a474d6c..17e0c9e 100644
> --- a/drivers/gpu/drm/msm/msm_fb.c
> +++ b/drivers/gpu/drm/msm/msm_fb.c
> @@ -77,7 +77,7 @@ void msm_framebuffer_describe(struct drm_framebuffer *fb,
> struct seq_file *m)
>
> seq_printf(m, "fb: %dx%d@%4.4s (%2d, ID:%d)\n",
> fb->width, fb->height, (char *)&fb->pixel_format,
> - fb->refcount.refcount.counter, fb->base.id);
> + drm_framebuffer_read_refcount(fb), fb->base.id);
>
> for (i = 0; i < n; i++) {
> seq_printf(m, " %d: offset=%d pitch=%d, obj: ",
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index 8e6b18c..2be88eb 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -878,7 +878,7 @@ static int tegra_debugfs_framebuffers(struct seq_file *s,
> void *data)
> seq_printf(s, "%3d: user size: %d x %d, depth %d, %d bpp,
> refcount %d\n",
> fb->base.id, fb->width, fb->height, fb->depth,
> fb->bits_per_pixel,
> -atomic_read(&fb->refcount.refcount));
> +drm_framebuffer_read_refcount(fb));
> }
>
> mutex_unlock(&drm->mode_config.fb_lock);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index e0170bf..99a12f0 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2608,6 +2608,11 @@ static inline uint32_t drm_color_lut_extract(uint32_t
> user_input,
> return clamp_val(val, 0, max);
> }
>
> +static inline uint32_t drm_framebuffer_read_refcount(struct drm_framebuffer
> *fb)
> +{
> + return atomic_read(&fb->refcount.refcount);
> +}
> +
> /* Plane list iterator for legacy (overlay only) planes. */
> #define drm_for_each_legacy_plane(plane, dev) \
> list_for_each_entry(plane, &(dev)->mode_config.plane_list, head) \
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 05/15] drm/mode: move framebuffer reference into object.
On Fri, Apr 15, 2016 at 03:10:36PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This is the initial code to add references to some mode objects.
> In the future we need to start reference counting connectors so
> firstly I want to reorganise the code so the framebuffer ref counting
> uses the same paths.
>
> This patch shouldn't change any functionality, just moves the kref.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/drm_crtc.c | 72
> --
> include/drm/drm_crtc.h | 20 ++---
> 2 files changed, 54 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 8616737..75a45e9 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -275,7 +275,8 @@ EXPORT_SYMBOL(drm_get_format_name);
> static int drm_mode_object_get_reg(struct drm_device *dev,
> struct drm_mode_object *obj,
> uint32_t obj_type,
> -bool register_obj)
> +bool register_obj,
> +void (*obj_free_cb)(struct kref *kref))
> {
> int ret;
>
> @@ -288,6 +289,10 @@ static int drm_mode_object_get_reg(struct drm_device
> *dev,
>*/
> obj->id = ret;
> obj->type = obj_type;
> + if (obj_free_cb) {
> + obj->free_cb = obj_free_cb;
> + kref_init(&obj->refcount);
> + }
> }
> mutex_unlock(&dev->mode_config.idr_mutex);
>
> @@ -311,7 +316,7 @@ static int drm_mode_object_get_reg(struct drm_device *dev,
> int drm_mode_object_get(struct drm_device *dev,
> struct drm_mode_object *obj, uint32_t obj_type)
> {
> - return drm_mode_object_get_reg(dev, obj, obj_type, true);
> + return drm_mode_object_get_reg(dev, obj, obj_type, true, NULL);
> }
>
> static void drm_mode_object_register(struct drm_device *dev,
> @@ -389,10 +394,35 @@ struct drm_mode_object *drm_mode_object_find(struct
> drm_device *dev,
> }
> EXPORT_SYMBOL(drm_mode_object_find);
>
Kerneldoc for this one would be nice.
> +void drm_mode_object_unreference(struct drm_mode_object *obj)
> +{
> + if (obj->free_cb) {
> + DRM_DEBUG("OBJ ID: %d (%d)\n", obj->id,
> atomic_read(&obj->refcount.refcount));
> + kref_put(&obj->refcount, obj->free_cb);
> + }
> +}
> +EXPORT_SYMBOL(drm_mode_object_unreference);
> +
> +/**
> + * drm_mode_object_reference - incr the fb refcnt
> + * @obj: mode_object
> + *
> + * This function operates only on refcounted objects.
> + * This functions increments the object's refcount.
> + */
> +void drm_mode_object_reference(struct drm_mode_object *obj)
> +{
> + if (obj->free_cb) {
> + DRM_DEBUG("OBJ ID: %d (%d)\n", obj->id,
> atomic_read(&obj->refcount.refcount));
> + kref_get(&obj->refcount);
> + }
> +}
> +EXPORT_SYMBOL(drm_mode_object_reference);
> +
> static void drm_framebuffer_free(struct kref *kref)
> {
> struct drm_framebuffer *fb =
> - container_of(kref, struct drm_framebuffer, refcount);
> + container_of(kref, struct drm_framebuffer,
> base.refcount);
> struct drm_device *dev = fb->dev;
>
> /*
> @@ -430,12 +460,12 @@ int drm_framebuffer_init(struct drm_device *dev, struct
> drm_framebuffer *fb,
> int ret;
>
> mutex_lock(&dev->mode_config.fb_lock);
> - kref_init(&fb->refcount);
> INIT_LIST_HEAD(&fb->filp_head);
> fb->dev = dev;
> fb->funcs = funcs;
>
> - ret = drm_mode_object_get(dev, &fb->base, DRM_MODE_OBJECT_FB);
> + ret = drm_mode_object_get_reg(dev, &fb->base, DRM_MODE_OBJECT_FB,
> + true, drm_framebuffer_free);
> if (ret)
> goto out;
>
> @@ -482,7 +512,7 @@ struct drm_framebuffer *drm_framebuffer_lookup(struct
> drm_device *dev,
> mutex_lock(&dev->mode_config.fb_lock);
> fb = __drm_framebuffer_lookup(dev, id);
> if (fb) {
> - if (!kref_get_unless_zero(&fb->refcount))
> + if (!kref_get_unless_zero(&fb->base.refcount))
> fb = NULL;
> }
> mutex_unlock(&dev->mode_config.fb_lock);
> @@ -492,32 +522,6 @@ struct drm_framebuffer *drm_framebuffer_lookup(struct
> drm_device *dev,
> EXPORT_SYMBOL(drm_framebuffer_lookup);
>
> /**
> - * drm_framebuffer_unreference - unref a framebuffer
> - * @fb: framebuffer to unref
> - *
> - * This functions decrements the fb's refcount and frees it if it drops to
> zero.
> - */
> -void drm_framebuffer_unreference(struct drm_framebuffer *fb)
> -{
> - DRM_DEBUG("%p: FB ID: %d (%d)\n", fb, fb->base.id,
> atomic_read(&fb->refcount.refcount));
> - kref_put(&fb->refcount, drm_framebuffer_free);
> -}
> -EXPORT_SYMBOL(drm_framebuffer_unreference);
> -
> -/**
> - * drm_
[PATCH 06/15] drm/mode: use _object_find to find framebuffers.
On Fri, Apr 15, 2016 at 03:10:37PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> No point have this code dupliated at this point, use the
> _object_find code instead now.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 35 ++-
> 1 file changed, 10 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 75a45e9..0d75517 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -362,8 +362,7 @@ static struct drm_mode_object *_object_find(struct
> drm_device *dev,
> obj = NULL;
> /* don't leak out unref'd fb's */
> if (obj &&
> - (obj->type == DRM_MODE_OBJECT_FB ||
> - obj->type == DRM_MODE_OBJECT_BLOB))
> + obj->type == DRM_MODE_OBJECT_BLOB)
> obj = NULL;
> mutex_unlock(&dev->mode_config.idr_mutex);
>
> @@ -478,23 +477,6 @@ out:
> }
> EXPORT_SYMBOL(drm_framebuffer_init);
>
> -static struct drm_framebuffer *__drm_framebuffer_lookup(struct drm_device
> *dev,
> - uint32_t id)
> -{
> - struct drm_mode_object *obj = NULL;
> - struct drm_framebuffer *fb;
> -
> - mutex_lock(&dev->mode_config.idr_mutex);
> - obj = idr_find(&dev->mode_config.crtc_idr, id);
> - if (!obj || (obj->type != DRM_MODE_OBJECT_FB) || (obj->id != id))
> - fb = NULL;
> - else
> - fb = obj_to_fb(obj);
> - mutex_unlock(&dev->mode_config.idr_mutex);
> -
> - return fb;
> -}
> -
> /**
> * drm_framebuffer_lookup - look up a drm framebuffer and grab a reference
> * @dev: drm device
> @@ -507,11 +489,13 @@ static struct drm_framebuffer
> *__drm_framebuffer_lookup(struct drm_device *dev,
> struct drm_framebuffer *drm_framebuffer_lookup(struct drm_device *dev,
> uint32_t id)
> {
> - struct drm_framebuffer *fb;
> + struct drm_mode_object *obj;
> + struct drm_framebuffer *fb = NULL;
>
> mutex_lock(&dev->mode_config.fb_lock);
> - fb = __drm_framebuffer_lookup(dev, id);
> - if (fb) {
> + obj = _object_find(dev, id, DRM_MODE_OBJECT_FB);
> + if (obj) {
> + fb = obj_to_fb(obj);
> if (!kref_get_unless_zero(&fb->base.refcount))
> fb = NULL;
> }
> @@ -3449,6 +3433,7 @@ int drm_mode_rmfb(struct drm_device *dev,
> {
> struct drm_framebuffer *fb = NULL;
> struct drm_framebuffer *fbl = NULL;
> + struct drm_mode_object *obj;
> uint32_t *id = data;
> int found = 0;
>
> @@ -3457,10 +3442,10 @@ int drm_mode_rmfb(struct drm_device *dev,
>
> mutex_lock(&file_priv->fbs_lock);
> mutex_lock(&dev->mode_config.fb_lock);
> - fb = __drm_framebuffer_lookup(dev, *id);
> - if (!fb)
> + obj = _object_find(dev, *id, DRM_MODE_OBJECT_FB);
> + if (!obj)
> goto fail_lookup;
> -
> + fb = obj_to_fb(obj);
> list_for_each_entry(fbl, &file_priv->fbs, filp_head)
> if (fb == fbl)
> found = 1;
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 07/15] drm/mode: reduce scope of fb_lock in framebuffer init
On Fri, Apr 15, 2016 at 03:10:38PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> We don't need to hold the fb lock around the initialisation,
> only around the list manipulaton.
>
> So do the lock hold only around the register for now.
> Signed-off-by: Dave Airlie
This needs a bit more explanation added:
"Previously fb refcounting, and especially the weak reference
(kref_get_unless_zero) used in fb lookups have been protected by fb_lock.
But with the refactoring to share refcounting in the drm_mode_object base
class that switched to being protected by idr_mutex, which means fb_lock
critical sections can be reduced."
I also double-checked that we don't have any outdated comments that point
at the wrong lock, and didn't find any.
With the commit message augmented:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 0d75517..1863879 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -458,21 +458,22 @@ int drm_framebuffer_init(struct drm_device *dev, struct
> drm_framebuffer *fb,
> {
> int ret;
>
> - mutex_lock(&dev->mode_config.fb_lock);
> INIT_LIST_HEAD(&fb->filp_head);
> fb->dev = dev;
> fb->funcs = funcs;
>
> ret = drm_mode_object_get_reg(dev, &fb->base, DRM_MODE_OBJECT_FB,
> - true, drm_framebuffer_free);
> + false, drm_framebuffer_free);
> if (ret)
> goto out;
>
> + mutex_lock(&dev->mode_config.fb_lock);
> dev->mode_config.num_fb++;
> list_add(&fb->head, &dev->mode_config.fb_list);
> -out:
> - mutex_unlock(&dev->mode_config.fb_lock);
>
> + drm_mode_object_register(dev, &fb->base);
> + mutex_unlock(&dev->mode_config.fb_lock);
> +out:
> return ret;
> }
> EXPORT_SYMBOL(drm_framebuffer_init);
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 08/15] drm/mode: reduce lock hold in addfb2
On Fri, Apr 15, 2016 at 03:10:39PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> No need to hold the lock while assigning the variable.
>
> Signed-off-by: Dave Airlie
Not sure why exactly I put that under the lock, but the only thing that
can race here is rmfb while addfb2 is still doing it's thing, with a
correctly guess (easy to do since they're fully deterministic) fb_id.
But that race can't happen because rmfb checks whether the fb is
associated with the drm_file, and if not bails out. And since
mutex_lock/unlock together are a full barrier gcc can't even reorder
things so that it would be possible to return a 0 fb_id.
I think I convinced myself that this is totally safe ;-)
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 1863879..21cb998 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3405,11 +3405,11 @@ int drm_mode_addfb2(struct drm_device *dev,
> if (IS_ERR(fb))
> return PTR_ERR(fb);
>
> - /* Transfer ownership to the filp for reaping on close */
> -
> DRM_DEBUG_KMS("[FB:%d]\n", fb->base.id);
> - mutex_lock(&file_priv->fbs_lock);
> r->fb_id = fb->base.id;
> +
> + /* Transfer ownership to the filp for reaping on close */
> + mutex_lock(&file_priv->fbs_lock);
> list_add(&fb->filp_head, &file_priv->fbs);
> mutex_unlock(&file_priv->fbs_lock);
>
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 09/15] drm/modes: move reference taking into object lookup.
On Fri, Apr 15, 2016 at 03:10:40PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> When we lookup an ref counted object we now take a proper reference
> using kref_get_unless_zero.
>
> Framebuffer lookup no longer needs do this itself.
>
> Convert rmfb to using framebuffer lookup and deal with the fact
> it now gets an extra reference that we have to cleanup. This should
> mean we can avoid holding fb_lock across rmfb. (if I'm wrong let me
> know).
>
> We also now only hold the fbs_lock around the list manipulation.
>
> Signed-off-by: Dave Airlie
Needs the same comment as patch 7 added to the commit message:
"Previously fb refcounting, and especially the weak reference
(kref_get_unless_zero) used in fb lookups have been protected by fb_lock.
But with the refactoring to share refcounting in the drm_mode_object base
class that switched to being protected by idr_mutex, which means fb_lock
critical sections can be reduced."
With that: Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 37 -
> 1 file changed, 20 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 21cb998..e47c4a2 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -364,6 +364,11 @@ static struct drm_mode_object *_object_find(struct
> drm_device *dev,
> if (obj &&
> obj->type == DRM_MODE_OBJECT_BLOB)
> obj = NULL;
> +
> + if (obj && obj->free_cb) {
> + if (!kref_get_unless_zero(&obj->refcount))
> + obj = NULL;
> + }
> mutex_unlock(&dev->mode_config.idr_mutex);
>
> return obj;
> @@ -495,11 +500,8 @@ struct drm_framebuffer *drm_framebuffer_lookup(struct
> drm_device *dev,
>
> mutex_lock(&dev->mode_config.fb_lock);
> obj = _object_find(dev, id, DRM_MODE_OBJECT_FB);
> - if (obj) {
> + if (obj)
> fb = obj_to_fb(obj);
> - if (!kref_get_unless_zero(&fb->base.refcount))
> - fb = NULL;
> - }
> mutex_unlock(&dev->mode_config.fb_lock);
>
> return fb;
> @@ -3434,37 +3436,38 @@ int drm_mode_rmfb(struct drm_device *dev,
> {
> struct drm_framebuffer *fb = NULL;
> struct drm_framebuffer *fbl = NULL;
> - struct drm_mode_object *obj;
> uint32_t *id = data;
> int found = 0;
>
> if (!drm_core_check_feature(dev, DRIVER_MODESET))
> return -EINVAL;
>
> + fb = drm_framebuffer_lookup(dev, *id);
> + if (!fb)
> + return -ENOENT;
> +
> mutex_lock(&file_priv->fbs_lock);
> - mutex_lock(&dev->mode_config.fb_lock);
> - obj = _object_find(dev, *id, DRM_MODE_OBJECT_FB);
> - if (!obj)
> - goto fail_lookup;
> - fb = obj_to_fb(obj);
> list_for_each_entry(fbl, &file_priv->fbs, filp_head)
> if (fb == fbl)
> found = 1;
> - if (!found)
> - goto fail_lookup;
> + if (!found) {
> + mutex_unlock(&file_priv->fbs_lock);
> + goto fail_unref;
> + }
>
> list_del_init(&fb->filp_head);
> - mutex_unlock(&dev->mode_config.fb_lock);
> mutex_unlock(&file_priv->fbs_lock);
>
> + /* we now own the reference that was stored in the fbs list */
> drm_framebuffer_unreference(fb);
>
> - return 0;
> + /* drop the reference we picked up in framebuffer lookup */
> + drm_framebuffer_unreference(fb);
>
> -fail_lookup:
> - mutex_unlock(&dev->mode_config.fb_lock);
> - mutex_unlock(&file_priv->fbs_lock);
> + return 0;
>
> +fail_unref:
> + drm_framebuffer_unreference(fb);
> return -ENOENT;
> }
>
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 10/15] drm/modes: reduce fb_lock to just protecting lists
On Fri, Apr 15, 2016 at 03:10:41PM +1000, Dave Airlie wrote: > From: Dave Airlie > > This reduces the fb_lock to just protecting the num_fb/fb_list. > > I'd like to have some discussion on if this opens up any race > conditions. Here's you're discussion ;-) "Previously fb refcounting, and especially the weak reference (kref_get_unless_zero) used in fb lookups have been protected by fb_lock. But with the refactoring to share refcounting in the drm_mode_object base class that switched to being protected by idr_mutex, which means fb_lock critical sections can be reduced." Reviewed-by: Daniel Vetter > > Signed-off-by: Dave Airlie > --- > drivers/gpu/drm/drm_crtc.c | 9 + > 1 file changed, 1 insertion(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index e47c4a2..46f32f2 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -433,9 +433,7 @@ static void drm_framebuffer_free(struct kref *kref) >* The lookup idr holds a weak reference, which has not necessarily been >* removed at this point. Check for that. >*/ > - mutex_lock(&dev->mode_config.fb_lock); > drm_mode_object_unregister(dev, &fb->base); > - mutex_unlock(&dev->mode_config.fb_lock); > > fb->funcs->destroy(fb); > } > @@ -475,9 +473,9 @@ int drm_framebuffer_init(struct drm_device *dev, struct > drm_framebuffer *fb, > mutex_lock(&dev->mode_config.fb_lock); > dev->mode_config.num_fb++; > list_add(&fb->head, &dev->mode_config.fb_list); > + mutex_unlock(&dev->mode_config.fb_lock); > > drm_mode_object_register(dev, &fb->base); > - mutex_unlock(&dev->mode_config.fb_lock); > out: > return ret; > } > @@ -498,12 +496,9 @@ struct drm_framebuffer *drm_framebuffer_lookup(struct > drm_device *dev, > struct drm_mode_object *obj; > struct drm_framebuffer *fb = NULL; > > - mutex_lock(&dev->mode_config.fb_lock); > obj = _object_find(dev, id, DRM_MODE_OBJECT_FB); > if (obj) > fb = obj_to_fb(obj); > - mutex_unlock(&dev->mode_config.fb_lock); > - > return fb; > } > EXPORT_SYMBOL(drm_framebuffer_lookup); > @@ -526,10 +521,8 @@ void drm_framebuffer_unregister_private(struct > drm_framebuffer *fb) > > dev = fb->dev; > > - mutex_lock(&dev->mode_config.fb_lock); > /* Mark fb as reaped and drop idr ref. */ > drm_mode_object_unregister(dev, &fb->base); > - mutex_unlock(&dev->mode_config.fb_lock); > } > EXPORT_SYMBOL(drm_framebuffer_unregister_private); > > -- > 2.5.5 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 11/15] drm/modes: stop handling framebuffer special
On Fri, Apr 15, 2016 at 03:10:42PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Since ref counting is in the object now we can just call the
> normal interfaces.
>
> Signed-off-by: Dave Airlie
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_crtc.c | 17 ++---
> 1 file changed, 2 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 46f32f2..f6bf828 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -4810,19 +4810,7 @@ bool drm_property_change_valid_get(struct drm_property
> *property,
> if (value == 0)
> return true;
>
> - /* handle refcnt'd objects specially: */
> - if (property->values[0] == DRM_MODE_OBJECT_FB) {
> - struct drm_framebuffer *fb;
> - fb = drm_framebuffer_lookup(property->dev, value);
> - if (fb) {
> - *ref = &fb->base;
> - return true;
> - } else {
> - return false;
> - }
> - } else {
> - return _object_find(property->dev, value,
> property->values[0]) != NULL;
> - }
> + return _object_find(property->dev, value, property->values[0])
> != NULL;
> }
>
> for (i = 0; i < property->num_values; i++)
> @@ -4838,8 +4826,7 @@ void drm_property_change_valid_put(struct drm_property
> *property,
> return;
>
> if (drm_property_type_is(property, DRM_MODE_PROP_OBJECT)) {
> - if (property->values[0] == DRM_MODE_OBJECT_FB)
> - drm_framebuffer_unreference(obj_to_fb(ref));
> + drm_mode_object_unreference(ref);
> } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB))
> drm_property_unreference_blob(obj_to_blob(ref));
> }
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
drm reference counter connectors and fix lifetimes
On Fri, Apr 15, 2016 at 03:10:31PM +1000, Dave Airlie wrote: > I've been trolled since I did MST that I really didn't do a good job > on the connector lifetimes, so I finally felt guilty and had time to try > and fix this up. > > This is a set of patches to handle connector lifetimes so that the connectors > don't go away in the middle of us doing something. I've done some testing > on this with kms_flip on my haswell laptop while undocking etc. > > Daniel has been pestering me to finish it off, so I've cleaned up the last > few things in the mst patches at least for i915 and decided to send it out. Ok, reviewed all the refcounting prep work. Just minor stuff, so I guess you'll pull them into drm-next directly after polishing? I have a bunch of pull requests I'll send out today, so could do a drm-next day. For the actual drm_connector refcounting I'd like to soak the prep patches a bit first, and I also need to think a bit more about those ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[alsa-devel] [PATCH v3 1/2] video: hdmi: add helper function for N and CTS
Hi, [auto build test WARNING on drm/drm-next] [also build test WARNING on v4.6-rc4 next-20160420] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Arnaud-Pouliquen/sti-add-audio-interface-to-the-hdmi-driver/20160421-161330 base: git://people.freedesktop.org/~airlied/linux.git drm-next reproduce: make htmldocs All warnings (new ones prefixed by >>): drivers/gpu/drm/i915/i915_irq.c:2663: warning: No description found for parameter 'fmt' include/drm/drm_crtc.h:364: warning: No description found for parameter 'mode_blob' include/drm/drm_crtc.h:779: warning: No description found for parameter 'name' include/drm/drm_crtc.h:1238: warning: No description found for parameter 'connector_id' include/drm/drm_crtc.h:1238: warning: No description found for parameter 'tile_blob_ptr' include/drm/drm_crtc.h:1277: warning: No description found for parameter 'rotation' include/drm/drm_crtc.h:1539: warning: No description found for parameter 'name' include/drm/drm_crtc.h:1539: warning: No description found for parameter 'mutex' include/drm/drm_crtc.h:1539: warning: No description found for parameter 'helper_private' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'tile_idr' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'connector_ida' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'delayed_event' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'edid_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'dpms_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'path_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'tile_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'plane_type_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'rotation_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'prop_src_x' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'prop_src_y' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'prop_src_w' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'prop_src_h' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'prop_crtc_x' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'prop_crtc_y' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'prop_crtc_w' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'prop_crtc_h' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'prop_fb_id' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'prop_crtc_id' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'prop_active' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'prop_mode_id' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'dvi_i_subconnector_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'dvi_i_select_subconnector_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'tv_subconnector_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'tv_select_subconnector_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'tv_mode_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'tv_left_margin_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'tv_right_margin_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'tv_top_margin_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'tv_bottom_margin_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'tv_brightness_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'tv_contrast_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'tv_flicker_reduction_property' include/drm/drm_crtc.h:2175: warning: No description found for parameter 'tv_overscan_property' inc
[PULL] drm-intel-next
Hi Dave, drm-intel-next-2016-04-11: - make modeset hw state checker atomic aware (Maarten) - close races in gpu stuck detection/seqno reading (Chris) - tons&tons of small improvements from Chris Wilson all over the gem code - more dsi/bxt work from Ramalingam&Jani - macro polish from Joonas - guc fw loading fixes (Arun&Dave) - vmap notifier (acked by Andrew) + i915 support by Chris Wilson - create bottom half for execlist irq processing (Chris Wilson) - vlv/chv pll cleanup (Ville) - rework DP detection, especially sink detection (Shubhangi Shrivastava) - make color manager support fully atomic (Maarten) - avoid livelock on chv in execlist irq handler (Chris) Cheers, Daniel The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9: Linux 4.6-rc2 (2016-04-03 09:09:40 -0500) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2016-04-11 for you to fetch changes up to ba3150ac3876acd082307f142597d3482107facc: drm/i915: Update DRIVER_DATE to 20160411 (2016-04-11 20:20:18 +0200) - make modeset hw state checker atomic aware (Maarten) - close races in gpu stuck detection/seqno reading (Chris) - tons&tons of small improvements from Chris Wilson all over the gem code - more dsi/bxt work from Ramalingam&Jani - macro polish from Joonas - guc fw loading fixes (Arun&Dave) - vmap notifier (acked by Andrew) + i915 support by Chris Wilson - create bottom half for execlist irq processing (Chris Wilson) - vlv/chv pll cleanup (Ville) - rework DP detection, especially sink detection (Shubhangi Shrivastava) - make color manager support fully atomic (Maarten) - avoid livelock on chv in execlist irq handler (Chris) Adam Buchbinder (1): MIPS: Fix misspellings in comments. Adrian Hunter (2): mmc: sdhci: Fix regression setting power on Trats2 board mmc: sdhci-pci: Add support and PCI IDs for more Broxton host controllers Akash Goel (1): drm/i915: Fixup the free space logic in ring_prepare Akinobu Mita (1): spi: omap2-mcspi: fix dma transfer for vmalloced buffer Alban Bedel (3): MIPS: zboot: Fix the build with XZ compression on older GCC versions MIPS: zboot: Remove copied source files on clean MIPS: ath79: Fix the ar913x reference clock rate Alex Deucher (4): drm/amdgpu/gmc: move vram type fetching into sw_init drm/amdgpu/gmc: use proper register for vram type on Fiji drm/amdgpu: print vram type rather than just DDR drm/ttm: use phys_addr_t for ttm_bus_placement Alexander Duyck (3): e1000: Do not overestimate descriptor counts in Tx pre-check e1000: Double Tx descriptors needed check for 82544 GRE: Disable segmentation offloads w/ CSUM and we are encapsulated via FOU Alexandre Courbot (1): drm/nouveau/tegra: acquire and enable reference clock if needed Alexey Brodkin (1): drm: ARM HDLCD - get rid of devm_clk_put() Antony Pavlov (2): dt-bindings: clock: qca,ath79-pll: fix copy-paste typos MIPS: dts: qca: ar9132_tl_wr1043nd_v1.dts: use "ref" for reference clock name Arik Nemtsov (3): mac80211: TDLS: always downgrade invalid chandefs mac80211: TDLS: change BW calculation for WIDER_BW peers mac80211: recalc min_def chanctx even when chandef is identical Arnd Bergmann (6): aacraid: add missing curly braces usb: phy: qcom-8x16: fix regulator API abuse iio: st_magn: always define ST_MAGN_TRIGGER_SET_STATE iommu: provide of_xlate pointer unconditionally IB/mlx5: fix VFs callback function prototypes i40iw: avoid potential uninitialized variable use Arun Siluvery (1): drm/i915/guc: reset GuC and retry on firmware load failure Bart Van Assche (3): scsi: Declare local symbols static scsi_dh_alua: Fix a recently introduced deadlock Revert "ib_srpt: Convert to percpu_ida tag allocation" Bastien Philbert (1): bridge: Fix incorrect variable assignment on error path in br_sysfs_addbr Ben Greear (1): mac80211: ensure no limits on station rhashtable Ben Hutchings (1): i2c: mux: demux-pinctrl: Clean up sysfs attributes Bjorn Helgaas (1): Revert "netpoll: Fix extra refcount release in netpoll_cleanup()" Bjørn Mork (2): drm/i915: fix deadlock on lid open USB: option: add "D-Link DWM-221 B1" device id Boris Ostrovsky (3): xen/apic: Provide Xen-specific version of cpu_present_to_apicid APIC op xen/x86: Call cpu_startup_entry(CPUHP_AP_ONLINE_IDLE) from xen_play_dead() xen/events: Mask a moving irq Calvin Owens (1): mpt3sas: Don't overreach ioc->reply_post[] during initialization Chris Mason (1): Merge branch 'misc-4.6' of git://git.kernel.org/.../kdave/linux into for-linus-4.6 Chris Wilson (29): drm/i915: Rename __force_wake_get to __force_wake_auto drm/i915:
[PULL] topic/struct_mutex
Hi Dave, struct_mutex cleanups and error paths fixes. Unfortunately I didn't manage to get acks from everyone, but this stuff has been hanging out for months now and imo simple enough to just land the remaining few patches. But separate pull request so that you can take a look yourself. Cheers, Daniel The following changes since commit d00b39c17573ece6f5fb1385314877d29f540db8: Merge branch 'drm-next-analogix-dp-v2' of github.com:yakir-Yang/linux into drm-next (2016-04-06 09:57:33 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/struct_mutex-2016-04-21 for you to fetch changes up to f74418a400c62f382228842fd0ce8a05f9069d8c: drm/vma_manage: Drop has_offset (2016-04-20 12:58:53 +0200) Daniel Vetter (12): drm/nouveau: Use unlocked gem unreferencing drm/omapdrm: Use unlocked gem unreferencing drm/qxl: Use unlocked gem unreferencing drm/nouveau: Drop dev->struct_mutex from fbdev init drm/exynos: Drop dev->struct_mutex from mmap offset function drm/exynos: drop struct_mutex from exynos_gem_map_sgt_with_dma drm/exynos: drop struct_mutex from exynos_drm_gem_get_ioctl drm/exynos: drop struct_mutex from fbdev setup drm/vgem: Simplify dumb_map drm/vgem: Move get_pages to gem_create drm/vgem: Drop dev->struct_mutex drm/vma_manage: Drop has_offset drivers/gpu/drm/drm_gem.c | 17 ++ drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 22 +++--- drivers/gpu/drm/exynos/exynos_drm_gem.c | 19 +++- drivers/gpu/drm/i915/i915_gem.c | 3 --- drivers/gpu/drm/nouveau/nouveau_display.c | 2 +- drivers/gpu/drm/nouveau/nouveau_fbcon.c | 5 - drivers/gpu/drm/omapdrm/omap_fbdev.c | 2 +- drivers/gpu/drm/qxl/qxl_fb.c | 4 ++-- drivers/gpu/drm/vgem/vgem_drv.c | 37 +-- include/drm/drm_vma_manager.h | 15 + 10 files changed, 44 insertions(+), 82 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PULL] topic/drm-misc
Hi Dave, misc pull req all over. Biggest thing is the drm_connector_(un)register_all cleanup from Alexey for drivers without the load/unload midlayer hooks. I.e. all the new ones, and a bunch of the pending new atomic drivers depend upon this. Or at least I asked them to rebase ;-) For 4.7 I'd like to get the defio stuff in still (getting into shape), plus there's a bunch of dp aux hacks that Lyude ported from i915 to drm helpers to fix up mst issues. I discussed those with Jani and we agreed that given how long they took to get into shape, the size and trickiness, and that 4.6 is fairly late already, a good soaking in -next is called for. Cheers, Daniel The following changes since commit d00b39c17573ece6f5fb1385314877d29f540db8: Merge branch 'drm-next-analogix-dp-v2' of github.com:yakir-Yang/linux into drm-next (2016-04-06 09:57:33 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-04-21 for you to fetch changes up to 6dc3e22ee197095eb6a6b3119f04f9dc6c2bbf91: drm: Make drm.debug parameter description more helpful (2016-04-21 09:45:12 +0200) Alexey Brodkin (3): drm: Introduce drm_connector_register_all() helper drm: atmel_hldc: Use generic drm_connector_register_all() helper drm: rcar-du: Use generic drm_connector_register_all() helper Chris Wilson (1): drm: Release driver references to handle before making it available again Daniel Vetter (2): drm/bochs: Drop fake gamma support drm/virtio: Drop dummy gamma table support Ezequiel Garcia (2): drm: probe_helper: Hide ugly ifdef drm: Make drm.debug parameter description more helpful Jim Bride (3): drm/edid: Add drm_edid_get_monitor_name() drm/dp/mst: Enhance DP MST debugfs output drm/i915/dp/mst: Add source port info to debugfs output Laurent Pinchart (1): drm: Remove warning from drm_connector_unregister_all() Lionel Landwerlin (1): drm: fix lut value extraction function Liu Ying (1): drm/crtc_helper: Reset empty plane state in drm_helper_crtc_mode_set_base() Lyude (1): drm/dp/mst: Restore primary hub guid on resume Maarten Lankhorst (1): drm/core: Fix ordering in drm_mode_config_cleanup. Robert Foss (1): include/drm: Reword debug categories comment. Ville Syrjälä (1): drm/atomic-helper: Print an error if vblank wait times out drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 30 +- drivers/gpu/drm/bochs/bochs_fbdev.c | 15 --- drivers/gpu/drm/bochs/bochs_kms.c| 7 drivers/gpu/drm/drm_atomic_helper.c | 2 + drivers/gpu/drm/drm_crtc.c | 60 +++- drivers/gpu/drm/drm_crtc_helper.c| 8 ++-- drivers/gpu/drm/drm_dp_mst_topology.c| 41 --- drivers/gpu/drm/drm_drv.c| 20 -- drivers/gpu/drm/drm_edid.c | 51 ++- drivers/gpu/drm/drm_gem.c| 16 drivers/gpu/drm/drm_probe_helper.c | 2 - drivers/gpu/drm/i915/i915_debugfs.c | 3 +- drivers/gpu/drm/rcar-du/rcar_du_drv.c| 9 + drivers/gpu/drm/virtio/virtgpu_display.c | 9 - include/drm/drmP.h | 2 +- include/drm/drm_crtc.h | 13 -- include/drm/drm_edid.h | 8 17 files changed, 183 insertions(+), 113 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 2/2] ARM: dts: add exynos5420-fimd compatible
On 02/15/2016 04:59 AM, Krzysztof Kozlowski wrote: > On 15.02.2016 09:57, Krzysztof Kozlowski wrote: >> On 12.02.2016 22:31, Chanho Park wrote: >>> This patch changes the compatible of exynos5420 fimd >>> to "exynos5420-fimd". To support mic bypass from display >>> path, the new compatible is introduced for exynos5420. >>> >>> Cc: Inki Dae >>> Cc: Kukjin Kim >>> Cc: Krzysztof Kozlowski >>> Signed-off-by: Chanho Park >>> --- >>> arch/arm/boot/dts/exynos5420.dtsi | 1 + >>> 1 file changed, 1 insertion(+) >>> >> >> Looks okay to me and also looks independent from patch #1. I will apply >> it for late v4.6 if patch #1 got accepted by Inki. >> >> Anyway, for reference: >> Reviewed-by: Krzysztof Kozlowski > > Stupid me, of course it cannot go independently through my tree. Please > feel free to take it through drm-exynos with my reviewed-by tag. Inki did not pick it up, so applied now for late v4.7. Best regards, Krzysztof
[PATCH v3 02/19] clk: sunxi: Add display and TCON0 clocks driver
Hi Stephen,
On Fri, Apr 15, 2016 at 03:34:10PM -0700, Stephen Boyd wrote:
> > +static int sun4i_a10_display_reset_xlate(struct reset_controller_dev
> > *rcdev,
> > +const struct of_phandle_args *spec)
> > +{
> > + /* We only have a single reset signal */
> > + return 0;
> > +}
>
> Is there a default function for this case in the reset framework?
No, the reset bindings assumes that you have a cell size of 1, and
it's the only case that's supported by the reset framework default
xlate.
I adressed the rest of your comments.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/cfc59e89/attachment.sig>
[PATCH v3 1/2] video: hdmi: add helper function for N and CTS
Add helper function to compute HDMI CTS and N parameters
Implementation is based on HDMI 1.4b specification.
Signed-off-by: Arnaud Pouliquen
Acked-by: Benjamin Gaignard
Acked-by: Vincent ABRIOU
---
drivers/video/hdmi.c | 202 +++
include/linux/hdmi.h | 22 ++
2 files changed, 224 insertions(+)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..6381ce0 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -1242,3 +1242,205 @@ int hdmi_infoframe_unpack(union hdmi_infoframe *frame,
void *buffer)
return ret;
}
EXPORT_SYMBOL(hdmi_infoframe_unpack);
+
+/**
+ * audio clock regeneration (acr) parameters
+ * N and CTS computation are based on HDMI specification 1.4b
+ */
+enum audio_rate {
+ HDMI_AUDIO_N_CTS_32KHZ,
+ HDMI_AUDIO_N_CTS_44_1KHZ,
+ HDMI_AUDIO_N_CTS_48KHZ,
+};
+
+struct hdmi_audio_acr {
+ unsigned int tmds_clk;
+ struct hdmi_audio_n_cts n_cts;
+};
+
+static const struct hdmi_audio_acr hdmi_audio_standard_acr[3][12] = {
+ { /*32 kHz*/
+ { 25174825, { 4576, 28125, 0 } }, /* 25,20/1.001 MHz */
+ { 2520, { 4096, 25200, 0 } }, /* 25.20MHz */
+ { 2700, { 4096, 27000, 0 } }, /* 27.00MHz */
+ { 27027000, { 4096, 27027, 0 } }, /* 27.00*1.001 MHz */
+ { 5400, { 4096, 54000, 0 } }, /* 54.00MHz */
+ { 54054000, { 4096, 54054, 0 } }, /* 54.00*1.001 MHz */
+ { 74175824, { 11648, 210937, 50 } }, /* 74.25/1.001 MHz */
+ { 7425, { 4096, 74250, 0 } }, /* 74.25MHz */
+ { 148351648, { 11648, 421875, 0 } }, /* 148.50/1.001 MHz */
+ { 14850, { 4096, 148500, 0 } }, /* 148.50 MHz */
+ { 296703296, { 5824, 421875, 0 } }, /* 297/1.001MHz */
+ { 29700, { 3072, 222750, 0 } }, /* 297 MHz */
+ },
+ { /*44.1 kHz, 88.2 kHz 176.4 kHz*/
+ { 25174825, { 7007, 31250, 0 } }, /* 25,20/1.001 MHz */
+ { 2520, { 6272, 28000, 0 } }, /* 25.20MHz */
+ { 2700, { 6272, 3, 0 } }, /* 27.00MHz */
+ { 27027000, { 6272, 30030, 0 } }, /* 27.00*1.001 MHz */
+ { 5400, { 6272, 6, 0 } }, /* 54.00MHz */
+ { 54054000, { 6272, 60060, 0 } }, /* 54.00*1.001 MHz */
+ { 74175824, { 17836, 234375, 0 } }, /* 74.25/1.001 MHz */
+ { 7425, { 6272, 82500, 0 } }, /* 74.25MHz */
+ { 148351648, { 8918, 234375, 0 } }, /* 148.50/1.001 MHz */
+ { 14850, { 6272, 165000, 0 } }, /* 148.50 MHz */
+ { 296703296, { 4459, 234375, 0 } }, /* 297/1.001MHz */
+ { 29700, { 4704, 247500, 0 } }, /* 297 MHz */
+ },
+ { /*48 kHz, 96 kHz 192 kHz*/
+ { 25174825, { 6864, 28125, 0 } }, /* 25,20/1.001 MHz */
+ { 2520, { 6144, 25200, 0 } }, /* 25.20MHz */
+ { 2700, { 6144, 27000, 0 } }, /* 27.00MHz */
+ { 27027000, { 6144, 27027, 0 } }, /* 27.00*1.001 MHz */
+ { 5400, { 6144, 54000, 0 } }, /* 54.00MHz */
+ { 54054000, { 6144, 54054, 0 } }, /* 54.00*1.001 MHz */
+ { 74175824, { 11648, 140625, 0 } }, /* 74.25/1.001 MHz */
+ { 7425, { 6144, 74250, 0 } }, /* 74.25MHz */
+ { 148351648, { 5824, 140625, 0 } }, /* 148.50/1.001 MHz */
+ { 14850, { 6144, 148500, 0 } }, /* 148.50 MHz */
+ { 296703296, { 5824, 281250, 0 } }, /* 297/1.001MHz */
+ { 29700, { 5120, 247500, 0 } }, /* 297 MHz */
+ }
+};
+
+/**
+ * hdmi_audio_get_coherent_n_cts() - compute N and CTS parameters for coherent
+ * clocks. Coherent clock means that audio and TMDS clocks have the same
+ * source (no drifts between clocks).
+ *
+ * @audio_fs: audio frame clock frequency in Hz
+ * @tmds_clk: HDMI TMDS clock frequency in Hz
+ * @n_cts: N and CTS parameter returned to user
+ *
+ * Values computed are based on table described in HDMI specification 1.4b
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int hdmi_audio_get_coherent_n_cts(unsigned int audio_fs,
+ unsigned int tmds_clk,
+ struct hdmi_audio_n_cts *n_cts)
+{
+ int audio_freq_id, i;
+ int rate_coeff = 1;
+ u64 val, min;
+ const struct hdmi_audio_acr *acr_table;
+ const struct hdmi_audio_n_cts *predef_n_cts = NULL;
+
+ switch (audio_fs) {
+ case 32000:
+ audio_freq_id = HDMI_AUDIO_N_CTS_32KHZ;
+ n_cts->n = 4096;
+ break;
+ case 44100:
+
[PATCH v2] drm/panel: simple: Add support for Innolux AT070TN92
Thierry Reding writes: > Applied, thanks. I once read that this is the recommended way to go, instead of specifying the timings in the device tree. Why is this so? Any new display just increases the .text size of the kernel unnessary. Did this idea stem from the era where bootloaders like Barebox couldn't modify the DT ad-hoc before handing it over to the kernel?
[PATCH v3 0/2] sti: add audio interface to the hdmi driver
This patchset implements audio interface in HDMI drm driver. Implementation is
based on
ASoC generic hdmi codec driver( https://patchwork.kernel.org/patch/8713141/).
It also proposes helper functions to compute N and CTS parameters
according to HDMI 1.4b specification.
V3:
- video: hdmi: add helper function for N and CTS
Also used on Mediatek platform
(https://patchwork.kernel.org/patch/8887341)
delta vs V2:
- typo fixes
- if/else code optimisation
- drm: sti: Add ASoC generic hdmi codec support.
- typo fixes
- add audio registers in debugfs information
V2: RFC
https://patchwork.kernel.org/patch/8091531/("video: hdmi: add helper function
for N and CTS")
https://patchwork.kernel.org/patch/8091561/("ASoC: hdmi-codec: Add hdmi-codec
for external HDMI-encoders")
- patch: video: hdmi: add helper function for N and CTS
Fixes based on Russel King remarks
- Duplicate function to have a separte treatment for coherent and
non-coherent clocks
- Add ratio field for alternate CTS value
- Clock frequency in Hz for TMDS and audio clocks
- Add information concerning clocks and CTS calculation.
V1:
This RFC is the implementation of audio HDMI on sti platform based on generic
hdmi-codec driver:
https://patchwork.kernel.org/patch/7215271/ ("ASoC: hdmi-codec: Add
hdmi-codec for external HDMI-encoders")
https://patchwork.kernel.org/patch/8062611/ ("video: hdmi: add helper
function for N and CTS")
Arnaud Pouliquen (2):
drm: sti: Add ASoC generic hdmi codec support.
video: hdmi: add helper function for N and CTS
drivers/gpu/drm/sti/Kconfig| 1 +
drivers/gpu/drm/sti/sti_hdmi.c | 248 ++---
drivers/gpu/drm/sti/sti_hdmi.h | 13 +++
drivers/video/hdmi.c | 202 +
include/linux/hdmi.h | 22
5 files changed, 469 insertions(+), 17 deletions(-)
--
1.9.1
[PATCH v3 2/2] drm: sti: Add ASoC generic hdmi codec support.
Add the interface needed by audio hdmi-codec driver.
Signed-off-by: Arnaud Pouliquen
Acked-by: Benjamin Gaignard
Acked-by: Vincent ABRIOU
---
drivers/gpu/drm/sti/Kconfig| 1 +
drivers/gpu/drm/sti/sti_hdmi.c | 248 ++---
drivers/gpu/drm/sti/sti_hdmi.h | 13 +++
3 files changed, 245 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/sti/Kconfig b/drivers/gpu/drm/sti/Kconfig
index 5ad43a1..494ab25 100644
--- a/drivers/gpu/drm/sti/Kconfig
+++ b/drivers/gpu/drm/sti/Kconfig
@@ -7,5 +7,6 @@ config DRM_STI
select DRM_KMS_CMA_HELPER
select DRM_PANEL
select FW_LOADER
+ select SND_SOC_HDMI_CODEC if SND_SOC
help
Choose this option to enable DRM on STM stiH41x chipset
diff --git a/drivers/gpu/drm/sti/sti_hdmi.c b/drivers/gpu/drm/sti/sti_hdmi.c
index 6ef0715..3a8bd47 100644
--- a/drivers/gpu/drm/sti/sti_hdmi.c
+++ b/drivers/gpu/drm/sti/sti_hdmi.c
@@ -18,6 +18,8 @@
#include
#include
+#include
+
#include "sti_hdmi.h"
#include "sti_hdmi_tx3g4c28phy.h"
#include "sti_hdmi_tx3g0c55phy.h"
@@ -35,6 +37,8 @@
#define HDMI_DFLT_CHL0_DAT 0x0110
#define HDMI_DFLT_CHL1_DAT 0x0114
#define HDMI_DFLT_CHL2_DAT 0x0118
+#define HDMI_AUDIO_CFG 0x0200
+#define HDMI_SPDIF_FIFO_STATUS 0x0204
#define HDMI_SW_DI_1_HEAD_WORD 0x0210
#define HDMI_SW_DI_1_PKT_WORD0 0x0214
#define HDMI_SW_DI_1_PKT_WORD1 0x0218
@@ -44,6 +48,9 @@
#define HDMI_SW_DI_1_PKT_WORD5 0x0228
#define HDMI_SW_DI_1_PKT_WORD6 0x022C
#define HDMI_SW_DI_CFG 0x0230
+#define HDMI_SAMPLE_FLAT_MASK 0x0244
+#define HDMI_AUDN 0x0400
+#define HDMI_AUD_CTS0x0404
#define HDMI_SW_DI_2_HEAD_WORD 0x0600
#define HDMI_SW_DI_2_PKT_WORD0 0x0604
#define HDMI_SW_DI_2_PKT_WORD1 0x0608
@@ -103,6 +110,7 @@
#define HDMI_INT_DLL_LCKBIT(5)
#define HDMI_INT_NEW_FRAME BIT(6)
#define HDMI_INT_GENCTRL_PKTBIT(7)
+#define HDMI_INT_AUDIO_FIFO_XRUNBIT(8)
#define HDMI_INT_SINK_TERM_PRESENT BIT(11)
#define HDMI_DEFAULT_INT (HDMI_INT_SINK_TERM_PRESENT \
@@ -111,6 +119,7 @@
| HDMI_INT_GLOBAL)
#define HDMI_WORKING_INT (HDMI_INT_SINK_TERM_PRESENT \
+ | HDMI_INT_AUDIO_FIFO_XRUN \
| HDMI_INT_GENCTRL_PKT \
| HDMI_INT_NEW_FRAME \
| HDMI_INT_DLL_LCK \
@@ -121,6 +130,27 @@
#define HDMI_STA_SW_RST BIT(1)
+#define HDMI_AUD_CFG_8CH BIT(0)
+#define HDMI_AUD_CFG_SPDIF_DIV_2 BIT(1)
+#define HDMI_AUD_CFG_SPDIF_DIV_3 BIT(2)
+#define HDMI_AUD_CFG_SPDIF_CLK_DIV_4 (BIT(1) | BIT(2))
+#define HDMI_AUD_CFG_CTS_CLK_256FS BIT(12)
+#define HDMI_AUD_CFG_DTS_INVALID BIT(16)
+#define HDMI_AUD_CFG_ONE_BIT_INVALID (BIT(18) | BIT(19) | BIT(20) | BIT(21))
+#define HDMI_AUD_CFG_CH12_VALIDBIT(28)
+#define HDMI_AUD_CFG_CH34_VALIDBIT(29)
+#define HDMI_AUD_CFG_CH56_VALIDBIT(30)
+#define HDMI_AUD_CFG_CH78_VALIDBIT(31)
+
+/* sample flat mask */
+#define HDMI_SAMPLE_FLAT_NO 0
+#define HDMI_SAMPLE_FLAT_SP0 BIT(0)
+#define HDMI_SAMPLE_FLAT_SP1 BIT(1)
+#define HDMI_SAMPLE_FLAT_SP2 BIT(2)
+#define HDMI_SAMPLE_FLAT_SP3 BIT(3)
+#define HDMI_SAMPLE_FLAT_ALL (HDMI_SAMPLE_FLAT_SP0 | HDMI_SAMPLE_FLAT_SP1 |\
+ HDMI_SAMPLE_FLAT_SP2 | HDMI_SAMPLE_FLAT_SP3)
+
#define HDMI_INFOFRAME_HEADER_TYPE(x)(((x) & 0xff) << 0)
#define HDMI_INFOFRAME_HEADER_VERSION(x) (((x) & 0xff) << 8)
#define HDMI_INFOFRAME_HEADER_LEN(x) (((x) & 0x0f) << 16)
@@ -171,6 +201,10 @@ static irqreturn_t hdmi_irq_thread(int irq, void *arg)
wake_up_interruptible(&hdmi->wait_event);
}
+ /* Audio FIFO underrun IRQ */
+ if (hdmi->irq_status & HDMI_INT_AUDIO_FIFO_XRUN)
+ DRM_INFO("Warning: audio FIFO underrun occurs!");
+
return IRQ_HANDLED;
}
@@ -441,26 +475,29 @@ static int hdmi_avi_infoframe_config(struct sti_hdmi
*hdmi)
*/
static int hdmi_audio_infoframe_config(struct sti_hdmi *hdmi)
{
- struct hdmi_audio_infoframe infofame;
+ struct hdmi_audio_params *audio = &hdmi->audio;
u8 buffer[HDMI_INFOFRAME_SIZE(AUDIO)];
- int ret;
-
- ret = hdmi_audio_infoframe_init(&infofame);
- if (ret < 0) {
- DRM_ERROR("failed to setup audio infoframe: %d\n", ret);
- return ret;
- }
-
- infofame.channels = 2;
-
- ret = hdmi_audio_infoframe_pack(&infofame, buffer, sizeof(buffer));
- if (ret < 0) {
- DRM_ERROR("failed to pack audio infoframe: %d\n", ret);
- return ret;
+ int ret, val;
+
+ DRM_DEBUG_DRIVER("enter %s, AIF %s\n", __func__,
+audio->enabled ? "enable" : "disable"
[PATCH v2] drm/msm: Use 64-bit timekeeping
> > How about > > remaining_jiffies = msecs_to_jiffies(ktime_ms_delta(*timeout, now)); > > which only does one 64-bit division, and it's one that we can probably > optimize out in the future (we can check in ktime_ms_delta whether the > difference is more than 2^32 nanoseconds as the fast path). Hi Arnd, I had thought about that, but discard that approach being confused about the truncation. ktime_ms_delta returns s64 and msecs_to_jiffies will truncate that input to int. However, I now realize that for the msecs value to be greater than 32 bits, the time delta has to be >= ((2^29)/(60*60*24*365)) or >= 17 years. So your solution is safe. If that sounds ok, I will send out a v3.
[PATCH v2] drm/msm: Use 64-bit timekeeping
>> which only does one 64-bit division, and it's one that we can probably >> optimize out in the future (we can check in ktime_ms_delta whether the >> difference is more than 2^32 nanoseconds as the fast path). It looks like ktime_divns already has that optimization for 32-bit divisor, so your solution should avoid the 64-bit division.
[PATCH v2] drm/msm: Use 64-bit timekeeping
On Thursday 21 April 2016 04:39:04 Tina Ruchandani wrote:
> >> which only does one 64-bit division, and it's one that we can probably
> >> optimize out in the future (we can check in ktime_ms_delta whether the
> >> difference is more than 2^32 nanoseconds as the fast path).
>
> It looks like ktime_divns already has that optimization for 32-bit divisor,
> so your solution should avoid the 64-bit division.
I meant an optimization for a 32-bit dividend, not divisor,
e.g. doing:
diff --git a/include/linux/ktime.h b/include/linux/ktime.h
index 2b6a204bd8d4..4fbf735ec0af 100644
--- a/include/linux/ktime.h
+++ b/include/linux/ktime.h
@@ -169,13 +169,17 @@ static inline bool ktime_before(const ktime_t cmp1, const
ktime_t cmp2)
extern s64 __ktime_divns(const ktime_t kt, s64 div);
static inline s64 ktime_divns(const ktime_t kt, s64 div)
{
+ s64 ns = kt.tv64;
+
/*
* Negative divisors could cause an inf loop,
* so bug out here.
*/
BUG_ON(div < 0);
- if (__builtin_constant_p(div) && !(div >> 32)) {
- s64 ns = kt.tv64;
+
+ if ((ns >> 32) == 0) {
+ return (s32)ns / div;
+ else if (__builtin_constant_p(div) && !(div >> 32)) {
u64 tmp = ns < 0 ? -ns : ns;
do_div(tmp, div);
I also just looked at the implementation of do_div() in
include/asm-generic/div64.h, and it already does that for
non-constant divisors, but I don't understand __div64_const32()
enough to know if the compiler end up doing the same
optimization for the constant divisor we have here.
Arnd
[Bug 94231] Problems compiling libdrm since glibc 2.23
https://bugs.freedesktop.org/show_bug.cgi?id=94231 --- Comment #19 from Emil Velikov --- That was fast, only a few hours ago the commit landed. No objections about having this in, although let's use AC_CHECK_HEADERS. I'm wondering if we shouldn't give it a day or two before landing though. Obviously waiting for a man-pages release would be a serious overkill (afaict it will be within ~4 months). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/1de6cd60/attachment.html>
libdrm: Patch to compile on hurd.
Hi Tobias, On 21 April 2016 at 06:30, Tobias Frost wrote: > Hallo, > > attached is a patch that makes libdrm compile on hurd. > Thanks for the patch. > (Note: I intentionally said compile, as I have no way to see if it > actually works there.) > Step one is actually making it build and step two involves testing it ;-) I've CC'ed Gary Wong, a gnu developer who has sent patches about mesa in the past. > The patch is created in a way to be neutral on all other archs; > it is mostly about PATH_MAX, which does not exist on that arch. > > Maybe you find the patch useful. > Sure do, just a few suggestions. Can you please split out the include/drm/* change to a separate patch and base it against the kernel UAPI headers. On the PATH_MAX front, please drop the whitespace change, and define PATH_MAX at top level, rather than using MY_PATH_MAX throughout the code. Please CC me on the updated patches and please send them via git send-email. Thanks Emil
[PATCH] drm: Fix compilation on systems that don't provide O_CLOEXEC
On 20 April 2016 at 16:25, Stefan Dirsch wrote: > On Wed, Apr 20, 2016 at 04:47:20PM +0200, Daniel Vetter wrote: >> On Wed, Apr 20, 2016 at 4:39 PM, Stefan Dirsch wrote: >> > Patch suggestion by Thomas Klausner. See also >> > http://mail-index.netbsd.org/pkgsrc-changes/2012/08/13/msg076887.html >> > >> > Signed-off-by: Stefan Dirsch >> >> Fix your OS to have O_CLOEXEC semantics I think is what should happen >> here. It's an obvious race in multi-threaded apps, and you need a fix >> for it anyway. >> -Daniel > > Indeed I figured out the patch is no longer needed and finally removed it. ;-) > No problem Stefan and thanks for starting to get the Suse patches upstreamed. A few friendly suggestions - please correctly the patch author (if not yourself) and don't add their s-o-b unless they have done/agreed so. Thanks, Emil P.S. [Note to self~ish~] Perhaps it's time we unconditionally use O_CLOEXEC in mesa...
[PATCH v3 1/2] video: hdmi: add helper function for N and CTS
Hi Arnaud,
Am Donnerstag, den 21.04.2016, 10:07 +0200 schrieb Arnaud Pouliquen:
> Add helper function to compute HDMI CTS and N parameters
> Implementation is based on HDMI 1.4b specification.
>
> Signed-off-by: Arnaud Pouliquen
> Acked-by: Benjamin Gaignard
> Acked-by: Vincent ABRIOU
Reviewed-by: Philipp Zabel
> ---
> drivers/video/hdmi.c | 202
> +++
> include/linux/hdmi.h | 22 ++
> 2 files changed, 224 insertions(+)
>
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 1626892..6381ce0 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -1242,3 +1242,205 @@ int hdmi_infoframe_unpack(union hdmi_infoframe
> *frame, void *buffer)
> return ret;
> }
> EXPORT_SYMBOL(hdmi_infoframe_unpack);
> +
> +/**
> + * audio clock regeneration (acr) parameters
> + * N and CTS computation are based on HDMI specification 1.4b
> + */
> +enum audio_rate {
> + HDMI_AUDIO_N_CTS_32KHZ,
> + HDMI_AUDIO_N_CTS_44_1KHZ,
> + HDMI_AUDIO_N_CTS_48KHZ,
> +};
> +
> +struct hdmi_audio_acr {
> + unsigned int tmds_clk;
> + struct hdmi_audio_n_cts n_cts;
> +};
> +
> +static const struct hdmi_audio_acr hdmi_audio_standard_acr[3][12] = {
> + { /*32 kHz*/
If you used
[HDMI_AUDIO_N_CTS_32KHZ] = {
instead, that would mirror how the array is indexed via audio_freq_id in
hdmi_audio_get_coherent_n_cts below.
> + { 25174825, { 4576, 28125, 0 } }, /* 25,20/1.001 MHz */
^
s/,/./
> + { 2520, { 4096, 25200, 0 } }, /* 25.20MHz */
> + { 2700, { 4096, 27000, 0 } }, /* 27.00MHz */
> + { 27027000, { 4096, 27027, 0 } }, /* 27.00*1.001 MHz */
> + { 5400, { 4096, 54000, 0 } }, /* 54.00MHz */
> + { 54054000, { 4096, 54054, 0 } }, /* 54.00*1.001 MHz */
> + { 74175824, { 11648, 210937, 50 } }, /* 74.25/1.001 MHz */
> + { 7425, { 4096, 74250, 0 } }, /* 74.25MHz */
> + { 148351648, { 11648, 421875, 0 } }, /* 148.50/1.001 MHz */
> + { 14850, { 4096, 148500, 0 } }, /* 148.50 MHz */
> + { 296703296, { 5824, 421875, 0 } }, /* 297/1.001MHz */
^
Maybe add a comment above that tmds_clk is rounded down?
> + { 29700, { 3072, 222750, 0 } }, /* 297 MHz */
> + },
> + { /*44.1 kHz, 88.2 kHz 176.4 kHz*/
> + { 25174825, { 7007, 31250, 0 } }, /* 25,20/1.001 MHz */
> + { 2520, { 6272, 28000, 0 } }, /* 25.20MHz */
> + { 2700, { 6272, 3, 0 } }, /* 27.00MHz */
> + { 27027000, { 6272, 30030, 0 } }, /* 27.00*1.001 MHz */
> + { 5400, { 6272, 6, 0 } }, /* 54.00MHz */
> + { 54054000, { 6272, 60060, 0 } }, /* 54.00*1.001 MHz */
> + { 74175824, { 17836, 234375, 0 } }, /* 74.25/1.001 MHz */
> + { 7425, { 6272, 82500, 0 } }, /* 74.25MHz */
> + { 148351648, { 8918, 234375, 0 } }, /* 148.50/1.001 MHz */
> + { 14850, { 6272, 165000, 0 } }, /* 148.50 MHz */
> + { 296703296, { 4459, 234375, 0 } }, /* 297/1.001MHz */
> + { 29700, { 4704, 247500, 0 } }, /* 297 MHz */
> + },
> + { /*48 kHz, 96 kHz 192 kHz*/
> + { 25174825, { 6864, 28125, 0 } }, /* 25,20/1.001 MHz */
> + { 2520, { 6144, 25200, 0 } }, /* 25.20MHz */
> + { 2700, { 6144, 27000, 0 } }, /* 27.00MHz */
> + { 27027000, { 6144, 27027, 0 } }, /* 27.00*1.001 MHz */
> + { 5400, { 6144, 54000, 0 } }, /* 54.00MHz */
> + { 54054000, { 6144, 54054, 0 } }, /* 54.00*1.001 MHz */
> + { 74175824, { 11648, 140625, 0 } }, /* 74.25/1.001 MHz */
> + { 7425, { 6144, 74250, 0 } }, /* 74.25MHz */
> + { 148351648, { 5824, 140625, 0 } }, /* 148.50/1.001 MHz */
> + { 14850, { 6144, 148500, 0 } }, /* 148.50 MHz */
> + { 296703296, { 5824, 281250, 0 } }, /* 297/1.001MHz */
> + { 29700, { 5120, 247500, 0 } }, /* 297 MHz */
> + }
> +};
> +
> +/**
> + * hdmi_audio_get_coherent_n_cts() - compute N and CTS parameters for
> coherent
> + * clocks. Coherent clock means that audio and TMDS clocks have the same
> + * source (no drifts between clocks).
> + *
> + * @audio_fs: audio frame clock frequency in Hz
> + * @tmds_clk: HDMI TMDS clock frequency in Hz
> + * @n_cts: N and CTS parameter returned to user
> + *
> + * Values computed are based on table described in HDMI specification 1.4b
> + *
> + * Returns 0 on success or a negative error code on failure.
> + */
> +int hdmi_audio_get_cohere
[PATCH] drm/etnaviv: don't move linear memory window on 3D cores without MC2.0
On cores with MC1.0 the memory window offset is not properly respected
by all engines in the core, leading to different views of the memory
if the offset in non-zero. This causes relocs for those engines to be
wrong and might lead to other subtile problems.
Rather than trying to work around this, just disable the linear memory
window offset for those cores.
Suggested-by: Russell King
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index a30d1c2b0f13..049d00d8ded5 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -572,6 +572,24 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
goto fail;
}
+ /*
+* Set the GPU linear window to be at the end of the DMA window, where
+* the CMA area is likely to reside. This ensures that we are able to
+* map the command buffers while having the linear window overlap as
+* much RAM as possible, so we can optimize mappings for other buffers.
+*
+* For 3D cores only do this if MC2.0 is present, as with MC1.0 it leads
+* to different views of the memory on the individual engines.
+*/
+ if (!(gpu->identity.features & chipFeatures_PIPE_3D) ||
+ (gpu->identity.minor_features0 & chipMinorFeatures0_MC20)) {
+ u32 dma_mask = (u32)dma_get_required_mask(gpu->dev);
+ if (dma_mask < PHYS_OFFSET + SZ_2G)
+ gpu->memory_base = PHYS_OFFSET;
+ else
+ gpu->memory_base = dma_mask - SZ_2G + 1;
+ }
+
ret = etnaviv_hw_reset(gpu);
if (ret)
goto fail;
@@ -1566,7 +1584,6 @@ static int etnaviv_gpu_platform_probe(struct
platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct etnaviv_gpu *gpu;
- u32 dma_mask;
int err = 0;
gpu = devm_kzalloc(dev, sizeof(*gpu), GFP_KERNEL);
@@ -1576,18 +1593,6 @@ static int etnaviv_gpu_platform_probe(struct
platform_device *pdev)
gpu->dev = &pdev->dev;
mutex_init(&gpu->lock);
- /*
-* Set the GPU linear window to be at the end of the DMA window, where
-* the CMA area is likely to reside. This ensures that we are able to
-* map the command buffers while having the linear window overlap as
-* much RAM as possible, so we can optimize mappings for other buffers.
-*/
- dma_mask = (u32)dma_get_required_mask(dev);
- if (dma_mask < PHYS_OFFSET + SZ_2G)
- gpu->memory_base = PHYS_OFFSET;
- else
- gpu->memory_base = dma_mask - SZ_2G + 1;
-
/* Map registers: */
gpu->mmio = etnaviv_ioremap(pdev, NULL, dev_name(gpu->dev));
if (IS_ERR(gpu->mmio))
--
2.8.0.rc3
[Bug 94984] XCom2 crashes with SIGSEGV on radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=94984 --- Comment #4 from Edwin Smith --- Please make sure you attach the save game to the bug as this will help reproduction. Nicolai has a copy of XCOM 2 so should be able to debug this issue. This also sounds like a regression (I don't know if it is Mesa or a Feral update that caused the regression) as we have completed the entire game many, many times on Mesa and we know a lot of Linux users are also playing using Mesa. Also if you attach the save game we can also assist if needed at a later date. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/531b8fef/attachment.html>
[PATCH 2/2] ARM: dts: add exynos5420-fimd compatible
2016-04-21 19:06 GMT+09:00 Krzysztof Kozlowski : > On 02/15/2016 04:59 AM, Krzysztof Kozlowski wrote: >> On 15.02.2016 09:57, Krzysztof Kozlowski wrote: >>> On 12.02.2016 22:31, Chanho Park wrote: This patch changes the compatible of exynos5420 fimd to "exynos5420-fimd". To support mic bypass from display path, the new compatible is introduced for exynos5420. Cc: Inki Dae Cc: Kukjin Kim Cc: Krzysztof Kozlowski Signed-off-by: Chanho Park --- arch/arm/boot/dts/exynos5420.dtsi | 1 + 1 file changed, 1 insertion(+) >>> >>> Looks okay to me and also looks independent from patch #1. I will apply >>> it for late v4.6 if patch #1 got accepted by Inki. >>> >>> Anyway, for reference: >>> Reviewed-by: Krzysztof Kozlowski >> >> Stupid me, of course it cannot go independently through my tree. Please >> feel free to take it through drm-exynos with my reviewed-by tag. > > Inki did not pick it up, so applied now for late v4.7. > Forgot it. Sorry for this Chanho and Krzysztof. Thanks, Inki Dae > Best regards, > Krzysztof > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
i.MX6 imx-drm framebuffer rotation. Kernel 3.14.52.
Am Donnerstag, den 21.04.2016, 15:33 +0300 schrieb Ivan Nikolaenko:
> Hello all!
>
> Mr. Fabio Estevam from freescale community forum advisedto address this
> question to this mail list.
>
> I am using a i.MX6Q SabreSD -based board with 3.14.52 kernel from Jethro
> (2.0) release of FSL-Community-BSP.
>
> I need to do a 180 degree vertical flip of the framebuffer using imx-drm
> upon kernel initialization. But I can see that in the
> ./drivers/video/mxc/mxc_ipuv3_fb.c file there are no support of rotation.
> Howisit meantto do?
No idea about the FSL kernel, but 180° rotation can't be done without
going through the IC, as far as I know. For a straight vertical flip
you'd just have to set the VF bit on the scanout IDMAC channel's CPMEM.
For example as a quick hack on v4.6-rc4:
-8<-
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 681ec6e..37d9ebd 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -291,6 +291,7 @@ int ipu_plane_mode_set(struct ipu_plane *ipu_plane, struct
drm_crtc *crtc,
ipu_dmfc_config_wait4eot(ipu_plane->dmfc, crtc_w);
ipu_cpmem_zero(ipu_plane->ipu_ch);
+ ipu_cpmem_set_rotation(ipu_plane->ipu_ch, IPU_ROTATE_VERT_FLIP);
ipu_cpmem_set_resolution(ipu_plane->ipu_ch, src_w, src_h);
ret = ipu_cpmem_set_fmt(ipu_plane->ipu_ch, fb->pixel_format);
if (ret < 0) {
->8-
I suppose that could be hooked up to the KMS rotation property (reflect-y).
regards
Philipp
[PULL] drm-intel-next
On Thu, Apr 21, 2016 at 11:26:49AM +0200, Daniel Vetter wrote: > Hi Dave, > > drm-intel-next-2016-04-11: > - make modeset hw state checker atomic aware (Maarten) > - close races in gpu stuck detection/seqno reading (Chris) > - tons&tons of small improvements from Chris Wilson all over the gem code > - more dsi/bxt work from Ramalingam&Jani > - macro polish from Joonas > - guc fw loading fixes (Arun&Dave) > - vmap notifier (acked by Andrew) + i915 support by Chris Wilson > - create bottom half for execlist irq processing (Chris Wilson) > - vlv/chv pll cleanup (Ville) > - rework DP detection, especially sink detection (Shubhangi Shrivastava) > - make color manager support fully atomic (Maarten) > - avoid livelock on chv in execlist irq handler (Chris) Gustavo pointed out that there's piles of stuff from Linus' tree in here. I forgot to add: contains backmerge, because Chris needed to get at the core mm notifier for vmap space. As usual the backmerge has it all explained, simply missed to give you a changelog for just the non-upstream changes in here. -Daniel > > Cheers, Daniel > > > The following changes since commit 9735a22799b9214d17d3c231fe377fc852f042e9: > > Linux 4.6-rc2 (2016-04-03 09:09:40 -0500) > > are available in the git repository at: > > git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2016-04-11 > > for you to fetch changes up to ba3150ac3876acd082307f142597d3482107facc: > > drm/i915: Update DRIVER_DATE to 20160411 (2016-04-11 20:20:18 +0200) > > > - make modeset hw state checker atomic aware (Maarten) > - close races in gpu stuck detection/seqno reading (Chris) > - tons&tons of small improvements from Chris Wilson all over the gem code > - more dsi/bxt work from Ramalingam&Jani > - macro polish from Joonas > - guc fw loading fixes (Arun&Dave) > - vmap notifier (acked by Andrew) + i915 support by Chris Wilson > - create bottom half for execlist irq processing (Chris Wilson) > - vlv/chv pll cleanup (Ville) > - rework DP detection, especially sink detection (Shubhangi Shrivastava) > - make color manager support fully atomic (Maarten) > - avoid livelock on chv in execlist irq handler (Chris) > > > Adam Buchbinder (1): > MIPS: Fix misspellings in comments. > > Adrian Hunter (2): > mmc: sdhci: Fix regression setting power on Trats2 board > mmc: sdhci-pci: Add support and PCI IDs for more Broxton host > controllers > > Akash Goel (1): > drm/i915: Fixup the free space logic in ring_prepare > > Akinobu Mita (1): > spi: omap2-mcspi: fix dma transfer for vmalloced buffer > > Alban Bedel (3): > MIPS: zboot: Fix the build with XZ compression on older GCC versions > MIPS: zboot: Remove copied source files on clean > MIPS: ath79: Fix the ar913x reference clock rate > > Alex Deucher (4): > drm/amdgpu/gmc: move vram type fetching into sw_init > drm/amdgpu/gmc: use proper register for vram type on Fiji > drm/amdgpu: print vram type rather than just DDR > drm/ttm: use phys_addr_t for ttm_bus_placement > > Alexander Duyck (3): > e1000: Do not overestimate descriptor counts in Tx pre-check > e1000: Double Tx descriptors needed check for 82544 > GRE: Disable segmentation offloads w/ CSUM and we are encapsulated via > FOU > > Alexandre Courbot (1): > drm/nouveau/tegra: acquire and enable reference clock if needed > > Alexey Brodkin (1): > drm: ARM HDLCD - get rid of devm_clk_put() > > Antony Pavlov (2): > dt-bindings: clock: qca,ath79-pll: fix copy-paste typos > MIPS: dts: qca: ar9132_tl_wr1043nd_v1.dts: use "ref" for reference > clock name > > Arik Nemtsov (3): > mac80211: TDLS: always downgrade invalid chandefs > mac80211: TDLS: change BW calculation for WIDER_BW peers > mac80211: recalc min_def chanctx even when chandef is identical > > Arnd Bergmann (6): > aacraid: add missing curly braces > usb: phy: qcom-8x16: fix regulator API abuse > iio: st_magn: always define ST_MAGN_TRIGGER_SET_STATE > iommu: provide of_xlate pointer unconditionally > IB/mlx5: fix VFs callback function prototypes > i40iw: avoid potential uninitialized variable use > > Arun Siluvery (1): > drm/i915/guc: reset GuC and retry on firmware load failure > > Bart Van Assche (3): > scsi: Declare local symbols static > scsi_dh_alua: Fix a recently introduced deadlock > Revert "ib_srpt: Convert to percpu_ida tag allocation" > > Bastien Philbert (1): > bridge: Fix incorrect variable assignment on error path in > br_sysfs_addbr > > Ben Greear (1): > mac80211: ensure no limits on station rhashtable > > Ben Hutchings (1): > i2c: mux: demux-pinctrl: Clean up sysfs attributes > > Bjorn Helgaas (1): > Revert "netpoll: Fix extra refcount release in netpoll_cleanup()"
[PATCH 2/3] kernel.h: add u64_to_user_ptr()
2016-04-20 Joe Perches :
> On Wed, 2016-04-20 at 16:18 -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > This function had copies in 3 different files. Unify them in kernel.h.
> []
> > diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> []
> > @@ -53,6 +53,12 @@
> >
> > Â #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
> > __must_be_array(arr))
> > Â
> > +static inline void __user *u64_to_user_ptr(u64 address)
> > +{
> > + typecheck(u64, address);
> > + return (void __user *)(uintptr_t)address;
> > +}
> > +
>
> This won't work because by the time address is checked
> address is already u64
>
> This would need to be something like
>
> #define u64_to_user_ptr(x)\
> ({\
> typecheck(u64, x); \
> u64_to_user_ptr(x); \
> })
Indeed, thanks for noting and for the suggestion.
Gustavo
[PATCH 2/3] drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency
Hello Inki,
On 03/28/2016 09:28 PM, Javier Martinez Canillas wrote:
> Commit aeefb36832e5 ("drm/exynos: gsc: add device tree support and remove
> usage of static mappings") made the DRM_EXYNOS_GSC Kconfig symbol to only
> be selectable if the exynos-gsc V4L2 driver isn't enabled, since both use
> the same HW IP block.
>
> But added the dependency as depends on !VIDEO_SAMSUNG_EXYNOS_GSC which is
> not correct since Kconfig expressions are not boolean but tristate. So it
> will only evaluate to 'n' if VIDEO_SAMSUNG_EXYNOS_GSC=y but will evaluate
> to 'm' if VIDEO_SAMSUNG_S5P_G2D=m.
>
> This means that both the V4L2 and DRM drivers can be enabled if the former
> is enabled as a module, which is not what we want.
>
> Signed-off-by: Javier Martinez Canillas
> ---
I see that only patch 1/3 from this series was picked but according to the
conversation with Seung-Woo [0] in the cover letter, the GSC v4l2 and drm
drivers don't support to be simultaneous enabled like is the case for FIMC.
So patch 3/3 is the only one of the series that should be dropped and this
one picked as well.
[0]: https://lkml.org/lkml/2016/3/29/7
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
[PATCH] drm: Fix compilation on systems that don't provide O_CLOEXEC
On Thu, Apr 21, 2016 at 01:37:22PM +0100, Emil Velikov wrote: > On 20 April 2016 at 16:25, Stefan Dirsch wrote: > > On Wed, Apr 20, 2016 at 04:47:20PM +0200, Daniel Vetter wrote: > >> On Wed, Apr 20, 2016 at 4:39 PM, Stefan Dirsch wrote: > >> > Patch suggestion by Thomas Klausner. See also > >> > http://mail-index.netbsd.org/pkgsrc-changes/2012/08/13/msg076887.html > >> > > >> > Signed-off-by: Stefan Dirsch > >> > >> Fix your OS to have O_CLOEXEC semantics I think is what should happen > >> here. It's an obvious race in multi-threaded apps, and you need a fix > >> for it anyway. > >> -Daniel > > > > Indeed I figured out the patch is no longer needed and finally removed it. > > ;-) > > > No problem Stefan and thanks for starting to get the Suse patches upstreamed. You're welcome. I'm trying my best. ;-) > A few friendly suggestions - please correctly the patch author (if not > yourself) and don't add their s-o-b unless they have done/agreed so. Fixed and resent. ;-) Thanks, Stefan Public Key available -- Stefan Dirsch (Res. & Dev.) SUSE LINUX GmbH Tel: 0911-740 53 0MaxfeldstraÃe 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.deGermany --- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) ---
[Bug 115251] amdgpu: Black screen + hang with Kaveri
https://bugzilla.kernel.org/show_bug.cgi?id=115251 --- Comment #4 from Alex Deucher --- Greg still hasn't applied it. -- You are receiving this mail because: You are watching the assignee of the bug.
[patch] drm/rockchip: inno_hdmi: fix an error code
On Fri, Feb 26, 2016 at 02:26:23PM +0800, Yakir Yang wrote:
> Dan,
>
> On 02/26/2016 05:30 AM, Dan Carpenter wrote:
> >We were accidentally returning PTR_ERR(NULL) which means success when we
> >wanted to return a negative error code.
> >
> >Fixes: 412d4ae6b7a5 ('drm/rockchip: hdmi: add Innosilicon HDMI support')
> >Signed-off-by: Dan Carpenter
> Reviewed-by: Yakir Yang
We still need to apply this.
regards,
dan carpenter
[PATCH v4 3/4] devicetree: Add ANX7814 SlimPort transmitter binding.
On Mon, Apr 18, 2016 at 01:26:11PM +0200, Enric Balletbo i Serra wrote: > The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter > designed for portable devices. > > Signed-off-by: Enric Balletbo i Serra > Cc: Rob Herring > --- > Changes since v3: > - Model v10 as regulator (dvdd10-supply) > - Removed the Acked-by: Rob Herring. Guess I need your ack again if you're > agree >with the change. Acked-by: Rob Herring > Changes since v2: > - Add Acked-by: Rob Herring > > Changes since v1: > - Rob Herring: >- Rename cable-det-gpios for hpd-gpios as is more standard >- Fix HDMI output for HDMI input > > .../devicetree/bindings/video/bridge/anx7814.txt | 40 > ++ > 1 file changed, 40 insertions(+) > create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt
[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit
On Thu, Apr 21, 2016 at 12:16 AM, Chris Wilson
wrote:
> On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> > +static int hsw_enable_metric_set(struct drm_i915_private *dev_priv)
> > +{
> > + int ret = i915_oa_select_metric_set_hsw(dev_priv);
> > +
> > + if (ret)
> > + return ret;
> > +
> > + I915_WRITE(GDT_CHICKEN_BITS, GT_NOA_ENABLE);
> > +
> > + /* PRM:
> > + *
> > + * OA unit is using âcrclkâ for its functionality. When trunk
> > + * level clock gating takes place, OA clock would be gated,
> > + * unable to count the events from non-render clock domain.
> > + * Render clock gating must be disabled when OA is enabled to
> > + * count the events from non-render domain. Unit level clock
> > + * gating for RCS should also be disabled.
> > + */
> > + I915_WRITE(GEN7_MISCCPCTL, (I915_READ(GEN7_MISCCPCTL) &
> > + ~GEN7_DOP_CLOCK_GATE_ENABLE));
> > + I915_WRITE(GEN6_UCGCTL1, (I915_READ(GEN6_UCGCTL1) |
> > + GEN6_CSUNIT_CLOCK_GATE_DISABLE));
> > +
> > + config_oa_regs(dev_priv, dev_priv->perf.oa.mux_regs,
> > +dev_priv->perf.oa.mux_regs_len);
> > +
> > + /* It takes a fairly long time for a new MUX configuration to
> > + * be be applied after these register writes. This delay
> > + * duration was derived empirically based on the render_basic
> > + * config but hopefully it covers the maximum configuration
> > + * latency...
> > + */
> > + mdelay(100);
>
> You really want to busy spin for 100ms? msleep() perhaps!
>
Ah, oops, I forgot to change this, thanks!
>
> Did you look for some register you can observe the change in when the
> mux is reconfigured? Is even reading one of the OA registers enough?
>
Although I can't really comprehend why the delay apparently needs to be
quite so long, based on my limited understanding of some of the NOA
michroarchitecture involved here it makes some sense to me there would be a
delay that's also somewhat variable depending on the particular MUX config
and I don't know of a trick for getting explicit feedback of completion
unfortunately.
I did bring this up briefly, recently in discussion with others more
familiar with the HW side of things, but haven't had much feedback on this
so far. afaik other OS drivers aren't currently accounting for a need to
have a delay here.
For reference, 100ms was picked as I was experimenting with stepping up the
delay by orders of magnitude and found 10ms wasn't enough. Potentially I
could experiment further with delays between 10 and 100ms, but I suppose it
won't make a big difference.
>
> > + config_oa_regs(dev_priv, dev_priv->perf.oa.b_counter_regs,
> > +dev_priv->perf.oa.b_counter_regs_len);
> > +
> > + return 0;
> > +}
> > +
> > +static void hsw_disable_metric_set(struct drm_i915_private *dev_priv)
> > +{
> > + I915_WRITE(GEN6_UCGCTL1, (I915_READ(GEN6_UCGCTL1) &
> > + ~GEN6_CSUNIT_CLOCK_GATE_DISABLE));
> > + I915_WRITE(GEN7_MISCCPCTL, (I915_READ(GEN7_MISCCPCTL) |
> > + GEN7_DOP_CLOCK_GATE_ENABLE));
> > +
> > + I915_WRITE(GDT_CHICKEN_BITS, (I915_READ(GDT_CHICKEN_BITS) &
> > + ~GT_NOA_ENABLE));
>
> You didn't preserve any other chicken bits during enable_metric_set.
>
Hmm, good point. I think I'll aim to preserve other bits when setting if
that works, just in case something else needs to fiddle with the same
register later.
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/5400393c/attachment-0001.html>
[Intel-gfx] [PATCH 5/5] drm/i915: Add support for new aspect ratios
On Fri, Mar 25, 2016 at 01:47:35PM +0530, Shashank Sharma wrote: > HDMI 2.0/CEA-861-F introduces two new aspect ratios: > - 64:27 > - 256:135 > > This patch adds support for these aspect ratios in > I915 driver, at various places. > > Signed-off-by: Shashank Sharma Ok, we discussed this a bit internally and I had some questions. Reading this series patches make sense up to this one, but here I have a few questions/comments. > --- > drivers/gpu/drm/drm_modes.c | 12 > drivers/gpu/drm/i915/intel_hdmi.c | 6 ++ > drivers/gpu/drm/i915/intel_sdvo.c | 6 ++ > 3 files changed, 24 insertions(+) > > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c > index 6e66136..11f219a 100644 > --- a/drivers/gpu/drm/drm_modes.c > +++ b/drivers/gpu/drm/drm_modes.c > @@ -1482,6 +1482,12 @@ void drm_mode_convert_to_umode(struct > drm_mode_modeinfo *out, > case HDMI_PICTURE_ASPECT_16_9: > out->flags |= DRM_MODE_FLAG_PAR16_9; > break; > + case HDMI_PICTURE_ASPECT_64_27: > + out->flags |= DRM_MODE_FLAG_PAR64_27; > + break; > + case DRM_MODE_PICTURE_ASPECT_256_135: > + out->flags |= DRM_MODE_FLAG_PAR256_135; > + break; > case HDMI_PICTURE_ASPECT_NONE: > case HDMI_PICTURE_ASPECT_RESERVED: > default: > @@ -1544,6 +1550,12 @@ int drm_mode_convert_umode(struct drm_display_mode > *out, > case DRM_MODE_FLAG_PAR16_9: > out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9; > break; > + case DRM_MODE_FLAG_PAR64_27: > + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27; > + break; > + case DRM_MODE_FLAG_PAR256_135: > + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135; > + break; > default: > out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; > } Above two parts is core enabling, I guess those should be squashed into the preceeding patch? > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c > b/drivers/gpu/drm/i915/intel_hdmi.c > index e2dab48..bc8e2c8 100644 > --- a/drivers/gpu/drm/i915/intel_hdmi.c > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > @@ -1545,6 +1545,12 @@ intel_hdmi_set_property(struct drm_connector > *connector, > case DRM_MODE_PICTURE_ASPECT_16_9: > intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_16_9; > break; > + case DRM_MODE_PICTURE_ASPECT_64_27: > + intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_64_27; > + break; > + case DRM_MODE_PICTURE_ASPECT_256_135: > + intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_256_135; > + break; > default: > return -EINVAL; > } > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c > b/drivers/gpu/drm/i915/intel_sdvo.c > index fae64bc..370e4f9 100644 > --- a/drivers/gpu/drm/i915/intel_sdvo.c > +++ b/drivers/gpu/drm/i915/intel_sdvo.c > @@ -2071,6 +2071,12 @@ intel_sdvo_set_property(struct drm_connector > *connector, > case DRM_MODE_PICTURE_ASPECT_16_9: > intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_16_9; > break; > + case DRM_MODE_PICTURE_ASPECT_64_27: > + intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_64_27; > + break; > + case DRM_MODE_PICTURE_ASPECT_256_135: > + intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_256_135; > + break; > default: > return -EINVAL; > } The trouble with the aspect_ratio prop as currently implemented is that we currently unconditionally overwrite adjusted_mode->picture_aspect_ratio with it. But your patches here move the aspect ratio handling into drm_mode_modeinfo (uabi) and drm_display_mode (kernel-internal), where it imo belongs. But we need to figure out how to the interaction with the property correctly. What's probably needed is a new value in the aspect_ratio enum called "default", which selects the aspect_ratio from the mode. Only when userspace overrides (NONE, or one of the CEA aspect ratios) would we obey the aspect_ratio of the property. Otherwise the aspect ratio stored in the mode would be lost. The other bit that I can't find in this series is making sure we compute the VIC correctly for the new modes. Or does that magically work correctly since we compare the full mode when selecting VICs? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit
On Thu, Apr 21, 2016 at 12:09 AM, Chris Wilson
wrote:
> On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> > +static void i915_oa_stream_enable(struct i915_perf_stream *stream)
> > +{
> > + struct drm_i915_private *dev_priv = stream->dev_priv;
> > +
> > + dev_priv->perf.oa.ops.oa_enable(dev_priv);
> > +
> > + if (dev_priv->perf.oa.periodic)
> > + hrtimer_start(&dev_priv->perf.oa.poll_check_timer,
> > + ns_to_ktime(POLL_PERIOD),
> > + HRTIMER_MODE_REL_PINNED);
> > +}
>
> > +static void i915_oa_stream_disable(struct i915_perf_stream *stream)
> > +{
> > + struct drm_i915_private *dev_priv = stream->dev_priv;
> > +
> > + dev_priv->perf.oa.ops.oa_disable(dev_priv);
> > +
> > + if (dev_priv->perf.oa.periodic)
> > + hrtimer_cancel(&dev_priv->perf.oa.poll_check_timer);
> > +}
>
> > +static enum hrtimer_restart oa_poll_check_timer_cb(struct hrtimer
> *hrtimer)
> > +{
> > + struct drm_i915_private *dev_priv =
> > + container_of(hrtimer, typeof(*dev_priv),
> > + perf.oa.poll_check_timer);
> > +
> > + if (!dev_priv->perf.oa.ops.oa_buffer_is_empty(dev_priv))
> > + wake_up(&dev_priv->perf.oa.poll_wq);
> > +
> > + hrtimer_forward_now(hrtimer, ns_to_ktime(POLL_PERIOD));
> > +
> > + return HRTIMER_RESTART;
> > +}
>
> > @@ -424,8 +1313,37 @@ void i915_perf_init(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = to_i915(dev);
> >
> > + if (!IS_HASWELL(dev))
> > + return;
> > +
> > + hrtimer_init(&dev_priv->perf.oa.poll_check_timer,
> > + CLOCK_MONOTONIC, HRTIMER_MODE_REL);
> > + dev_priv->perf.oa.poll_check_timer.function =
> oa_poll_check_timer_cb;
> > + init_waitqueue_head(&dev_priv->perf.oa.poll_wq);
>
> This timer only serves to wake up pollers / wait_unlocked, right? So why
> is it always running (when the stream is enabled)?
>
> What happens to poll / wait_unlocked if oa.periodic is not set? It seems
> like those functions would block indefinitely.
>
Right, it's unecessary. I'll look at limitting it to just while polling or
for blocking reads.
Good point about the blocking case too.
I just started testing that scenario yesterday, writting an MI_RPC unit
test which opens a stream without requesting periodic sampling, but didn't
poll or read in that case so far so didn't hit this yet.
At least for the read() this is partially considered by returning -EIO if
attempting a blocking read while the stream is disabled, but it doesn't
consider the case that the stream is enabled but periodic sampling isn't
enabled.
Regards,
- Robert
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/e3d73dd4/attachment.html>
[PATCH] libdrm/fourcc: Add formats R8, RG88, GR88
Follow-up of kernel patch:
https://lists.freedesktop.org/archives/dri-devel/2015-July/086041.html
The Kodi/XBMC and ChromeOS developers want to transcode NV12 to RGB
with OpenGL shaders, importing the two source planes through
EGL_EXT_image_dma_buf_import. That requires importing the Y plane as an
R8 EGLImage and the UV plane as either an RG88 or GR88 EGLImage.
Cc: Rainer Hochecker
Cc: Benjamin Widawsky
CC: Chad Versace
Signed-off-by: Dongseong Hwang
---
include/drm/drm_fourcc.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index e741b09..ca2f488 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -34,6 +34,13 @@
/* color index */
#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C */
+/* 8 bpp Red */
+#define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
+
+/* 16 bpp RG */
+#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /*
[15:0] R:G 8:8 little endian */
+#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /*
[15:0] G:R 8:8 little endian */
+
/* 8 bpp RGB */
#define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B
3:3:2 */
#define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R
2:3:3 */
--
2.5.0
[PATCH v12 0/2] staging/android: Sync ABI rework
From: Gustavo Padovan Hi, Here we clean up the Sync ABI and then improve in to a more optimized version. Also it is now less likely to need changes in the future. This is not breaking any upstream user of the sync framework, as no driver wired support for it, so far Android is the only user. A patch to AOSP will be provided to fix it there. We've made the changes in a way that userspace can figure out if the new versions are present and if not fallback to the older ABI version. More information on patch 2 description. To accomplish that we had to create a u64_to_user_ptr() macro so patch 1 adds that and also fixes some places in the kernel that were using (void __user *)(uintptr_t) cast directly. Patch 2 is the actual rework and has Ack from the people interested in it, including Android folks. Gustavo Padovan (2): kernel.h: add u64_to_user_ptr() staging/android: refactor SYNC IOCTLs drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 11 ++-- drivers/gpu/drm/i915/i915_drv.h | 5 -- drivers/gpu/drm/i915/i915_gem.c | 14 ++--- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 14 ++--- drivers/gpu/drm/msm/msm_gem_submit.c | 11 ++-- drivers/staging/android/sync.c | 76 +++- drivers/staging/android/uapi/sync.h | 36 + include/linux/kernel.h | 7 +++ 8 files changed, 94 insertions(+), 80 deletions(-) -- 2.5.5
[PATCH v12 1/2] kernel.h: add u64_to_user_ptr()
From: Gustavo Padovan
This function had copies in 3 different files. Unify them in kernel.h.
Cc: Joe Perches
Cc: Andrew Morton
Cc: David Airlie
Cc: Daniel Vetter
Cc: Rob Clark
Signed-off-by: Gustavo Padovan
---
v2: add typecheck() (comment from Maarten Lankhorst)
v3: make u64_to_user_ptr() a macro (comment from Joe Perches)
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 11 +++
drivers/gpu/drm/i915/i915_drv.h | 5 -
drivers/gpu/drm/i915/i915_gem.c | 14 +++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 14 +++---
drivers/gpu/drm/msm/msm_gem_submit.c | 11 +++
include/linux/kernel.h | 7 +++
6 files changed, 27 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
index 236ada9..afdd55d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
@@ -28,11 +28,6 @@
#define BO_LOCKED 0x4000
#define BO_PINNED 0x2000
-static inline void __user *to_user_ptr(u64 address)
-{
- return (void __user *)(uintptr_t)address;
-}
-
static struct etnaviv_gem_submit *submit_create(struct drm_device *dev,
struct etnaviv_gpu *gpu, size_t nr)
{
@@ -347,21 +342,21 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void
*data,
cmdbuf->exec_state = args->exec_state;
cmdbuf->ctx = file->driver_priv;
- ret = copy_from_user(bos, to_user_ptr(args->bos),
+ ret = copy_from_user(bos, u64_to_user_ptr(args->bos),
args->nr_bos * sizeof(*bos));
if (ret) {
ret = -EFAULT;
goto err_submit_cmds;
}
- ret = copy_from_user(relocs, to_user_ptr(args->relocs),
+ ret = copy_from_user(relocs, u64_to_user_ptr(args->relocs),
args->nr_relocs * sizeof(*relocs));
if (ret) {
ret = -EFAULT;
goto err_submit_cmds;
}
- ret = copy_from_user(stream, to_user_ptr(args->stream),
+ ret = copy_from_user(stream, u64_to_user_ptr(args->stream),
args->stream_size);
if (ret) {
ret = -EFAULT;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1048093..bb624cc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3576,11 +3576,6 @@ static inline i915_reg_t i915_vgacntrl_reg(struct
drm_device *dev)
return VGACNTRL;
}
-static inline void __user *to_user_ptr(u64 address)
-{
- return (void __user *)(uintptr_t)address;
-}
-
static inline unsigned long msecs_to_jiffies_timeout(const unsigned int m)
{
unsigned long j = msecs_to_jiffies(m);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dabc089..2889716 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -324,7 +324,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
{
struct drm_device *dev = obj->base.dev;
void *vaddr = obj->phys_handle->vaddr + args->offset;
- char __user *user_data = to_user_ptr(args->data_ptr);
+ char __user *user_data = u64_to_user_ptr(args->data_ptr);
int ret = 0;
/* We manually control the domain here and pretend that it
@@ -605,7 +605,7 @@ i915_gem_shmem_pread(struct drm_device *dev,
int needs_clflush = 0;
struct sg_page_iter sg_iter;
- user_data = to_user_ptr(args->data_ptr);
+ user_data = u64_to_user_ptr(args->data_ptr);
remain = args->size;
obj_do_bit17_swizzling = i915_gem_object_needs_bit17_swizzle(obj);
@@ -692,7 +692,7 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
return 0;
if (!access_ok(VERIFY_WRITE,
- to_user_ptr(args->data_ptr),
+ u64_to_user_ptr(args->data_ptr),
args->size))
return -EFAULT;
@@ -783,7 +783,7 @@ i915_gem_gtt_pwrite_fast(struct drm_device *dev,
if (ret)
goto out_unpin;
- user_data = to_user_ptr(args->data_ptr);
+ user_data = u64_to_user_ptr(args->data_ptr);
remain = args->size;
offset = i915_gem_obj_ggtt_offset(obj) + args->offset;
@@ -907,7 +907,7 @@ i915_gem_shmem_pwrite(struct drm_device *dev,
int needs_clflush_before = 0;
struct sg_page_iter sg_iter;
- user_data = to_user_ptr(args->data_ptr);
+ user_data = u64_to_user_ptr(args->data_ptr);
remain = args->size;
obj_do_bit17_swizzling = i915_gem_object_needs_bit17_swizzle(obj);
@@ -1036,12 +1036,12 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void
*data,
return 0;
if (!access_ok(VERIFY_READ,
- to_user_ptr(args->data_ptr),
+ u64_to_user_pt
[PATCH v12 2/2] staging/android: refactor SYNC IOCTLs
From: Gustavo Padovan
Change SYNC_IOC_FILE_INFO (former SYNC_IOC_FENCE_INFO) behaviour to avoid
future API breaks and optimize buffer allocation.
Now num_fences can be filled by the caller to inform how many fences it
wants to retrieve from the kernel. If the num_fences passed is greater
than zero info->sync_fence_info should point to a buffer with enough space
to fit all fences.
However if num_fences passed to the kernel is 0, the kernel will reply
with number of fences of the sync_file.
Sending first an ioctl with num_fences = 0 can optimize buffer allocation,
in a first call with num_fences = 0 userspace will receive the actual
number of fences in the num_fences filed.
Then it can allocate a buffer with the correct size on sync_fence_info and
call SYNC_IOC_FILE_INFO again, but now with the actual value of num_fences
in the sync_file.
info->sync_fence_info was converted to __u64 pointer to prevent 32bit
compatibility issues. And a flags member was added.
An example userspace code for the later would be:
struct sync_file_info *info;
int err, size, num_fences;
info = malloc(sizeof(*info));
info.flags = 0;
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
num_fences = info->num_fences;
if (num_fences) {
info.flags = 0;
size = sizeof(struct sync_fence_info) * num_fences;
info->num_fences = num_fences;
info->sync_fence_info = (uint64_t) calloc(num_fences,
sizeof(struct
sync_fence_info));
err = ioctl(fd, SYNC_IOC_FILE_INFO, info);
}
Finally the IOCTLs numbers were changed to avoid any potential old
userspace running the old API to get weird errors. Changing the opcodes
will make them fail right away. This is just a precaution, there no
upstream users of these interfaces yet and the only user is Android, but
we don't expect anyone trying to run android userspace and all it
dependencies on top of upstream kernels.
Signed-off-by: Gustavo Padovan
Reviewed-by: Maarten Lankhorst
Acked-by: Greg Hackmann
Acked-by: Rob Clark
Acked-by: Daniel Vetter
---
v2: fix fence_info memory leak
v3: Comments from Emil Velikov
- improve commit message
- remove __u64 cast
- remove check for output fields in file_info
- clean up sync_fill_fence_info()
Comments from Maarten Lankhorst
- remove in.num_fences && !in.sync_fence_info check
- remove info->len and use only num_fences to calculate size
Comments from Dan Carpenter
- fix info->sync_fence_info documentation
v4: remove allocated struct sync_file_info (comment from Maarten)
v5: merge all commits that were changing the ABI
v6: fix -Wint-to-pointer-cast error on info.sync_fence_info
---
drivers/staging/android/sync.c | 76 -
drivers/staging/android/uapi/sync.h | 36 +-
2 files changed, 67 insertions(+), 45 deletions(-)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 3a8f210..f9c6094 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -445,6 +445,11 @@ static long sync_file_ioctl_merge(struct sync_file
*sync_file,
goto err_put_fd;
}
+ if (data.flags || data.pad) {
+ err = -EINVAL;
+ goto err_put_fd;
+ }
+
fence2 = sync_file_fdget(data.fd2);
if (!fence2) {
err = -ENOENT;
@@ -479,13 +484,9 @@ err_put_fd:
return err;
}
-static int sync_fill_fence_info(struct fence *fence, void *data, int size)
+static void sync_fill_fence_info(struct fence *fence,
+ struct sync_fence_info *info)
{
- struct sync_fence_info *info = data;
-
- if (size < sizeof(*info))
- return -ENOMEM;
-
strlcpy(info->obj_name, fence->ops->get_timeline_name(fence),
sizeof(info->obj_name));
strlcpy(info->driver_name, fence->ops->get_driver_name(fence),
@@ -495,58 +496,63 @@ static int sync_fill_fence_info(struct fence *fence, void
*data, int size)
else
info->status = 0;
info->timestamp_ns = ktime_to_ns(fence->timestamp);
-
- return sizeof(*info);
}
static long sync_file_ioctl_fence_info(struct sync_file *sync_file,
unsigned long arg)
{
- struct sync_file_info *info;
+ struct sync_file_info info;
+ struct sync_fence_info *fence_info = NULL;
__u32 size;
- __u32 len = 0;
int ret, i;
- if (copy_from_user(&size, (void __user *)arg, sizeof(size)))
+ if (copy_from_user(&info, (void __user *)arg, sizeof(info)))
return -EFAULT;
- if (size < sizeof(struct sync_file_info))
+ if (info.flags || info.pad)
return -EINVAL;
- if (size > 4096)
-
[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit
On Wed, Apr 20, 2016 at 11:52 PM, Chris Wilson
wrote:
> On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> > +static int i915_oa_read(struct i915_perf_stream *stream,
> > + struct i915_perf_read_state *read_state)
> > +{
> > + struct drm_i915_private *dev_priv = stream->dev_priv;
> > +
> > + return dev_priv->perf.oa.ops.read(stream, read_state);
> > +}
>
> > + stream->destroy = i915_oa_stream_destroy;
> > + stream->enable = i915_oa_stream_enable;
> > + stream->disable = i915_oa_stream_disable;
> > + stream->can_read = i915_oa_can_read;
> > + stream->wait_unlocked = i915_oa_wait_unlocked;
> > + stream->poll_wait = i915_oa_poll_wait;
> > + stream->read = i915_oa_read;
>
> Why aren't these a const ops table?
>
No particular reason; I guess it just seemed straightforward enough at the
time. I suppose it avoids some redundant pointer indirection and could suit
defining streams in the future that might find it awkward to have static
ops (don't have anything like that in mind though) but it's at the expense
of a slightly larger stream struct (though also don't see that as a concern
currently).
Can change if you like.
Regards,
- Robert
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/a0943589/attachment.html>
[PATCH v2 2/4] dt-bindings: Add jdi lt070me05000 panel bindings
On Wed, Apr 20, 2016 at 03:02:31PM +0530, Vinay Simha BN wrote:
> Add documentation for lt070me05000 panel
>
> Signed-off-by: Vinay Simha BN
> ---
> .../bindings/display/panel/jdi,lt070me05000.txt| 43
> ++
> 1 file changed, 43 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
>
> diff --git
> a/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
> b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
> new file mode 100644
> index 000..ffe0550
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/jdi,lt070me05000.txt
> @@ -0,0 +1,43 @@
> +JDI model LT070ME05000 1200x1920 7" DSI Panel
> +
> +Required properties:
> +- compatible: should be "jdi,lt070me05000"
> +- power-supply: phandle of the regulator that provides the supply voltage
> + IOVCC , power supply for LCM (1.8V)
> +- vddp-supply: phandle of the regulator that provides the supply voltage
> + Power IC supply (3-5V)
> +- dcdc_en-supply: phandle of the regulator that provides the supply voltage
> + Power IC supply enable, High active
> +- reset-gpio: phandle of gpio for reset line
> + This should be 8mA, gpio can be configured using mux and pinctrl.
> + XRES, Reset, Low active
> +- enable-gpio: phandle of gpio for enable line
> + LED_EN, LED backlight enable, High active
These should all be -gpios instead.
> +- vcc-gpio: phandle of regulator/gpio that provides the supply voltage
> + VDD, LED power supply (3-5V)
Is it a regulator or gpio?
> +
> +Optional properties:
> +- pwm-gpio: phandle of gpio/pwm
This should use the PWM binding. It may not be a GPIO on some hosts.
> + pwm backlight control, this should be mapped to the backlight level
> + display brightness (0x51)
> +
> +Example:
> +
> + dsi0: qcom,mdss_dsi at 470 {
> + panel at 0 {
> + compatible = "jdi,lt070me05000";
> + reg = <0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&dsi_panel_pinctrl>;
> +
> + power-supply = <&pm8921_lvs5>;
> + vddp-supply = <&pm8921_l17>;
> + dcdc_en-supply = <&pm8921_lvs7>;
> +
> + reset-gpio = <&tlmm_pinmux 54 0>;
> + enable-gpio = <&pm8921_gpio 36 GPIO_ACTIVE_HIGH>;
> + vcc-gpio = <&pm8921_gpio 23 GPIO_ACTIVE_HIGH>;
> +
> + pwm-gpio = <&pm8921_gpio 26 GPIO_ACTIVE_HIGH>;
> + };
> + };
> --
> 2.1.2
>
[PATCH] drm/i915/vlv: Enable polling when we shut off all power domains
Unfortunately HPD isn't functional once we shut off all of the power
domains. Unfortunately we can end up shutting off all of the power
domains in any situation where we don't have any monitors connected,
essentially breaking hpd for the user unless they reboot with one of
their monitors connected.
In addition, enabling polling has to be done in it's own seperate
worker. The reason for this is that vlv_display_power_well_init/deinit()
will get called during the DRM polling process and try to grab the locks
required for turning on polling and cause a deadlock.
This breaks runtime PM due to the constant wakeups, so this is more of a
temporary workaround then a solution.
Signed-off-by: Lyude
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/i915/intel_display.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 551541b303..f644814 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14531,7 +14531,22 @@ static void intel_setup_outputs(struct drm_device *dev)
intel_dp_is_edp(dev, PORT_C))
intel_dp_init(dev, VLV_DP_C, PORT_C);
- if (IS_CHERRYVIEW(dev)) {
+ if (IS_VALLEYVIEW(dev)) {
+ struct intel_connector *connector;
+
+ /*
+* On vlv, turning off all of the power domains results
+* in a loss of hpd, enable polling on all of the
+* connectors so that drm polls them when this happens
+*/
+ drm_modeset_lock(&dev->mode_config.connection_mutex,
+NULL);
+ for_each_intel_connector(dev, connector) {
+ connector->polled = DRM_CONNECTOR_POLL_CONNECT |
+ DRM_CONNECTOR_POLL_DISCONNECT;
+ }
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+ } else if (IS_CHERRYVIEW(dev)) {
/* eDP not supported on port D, so don't check VBT */
if (I915_READ(CHV_HDMID) & SDVO_DETECTED)
intel_hdmi_init(dev, CHV_HDMID, PORT_D);
--
2.5.5
[PATCH] libdrm/fourcc: Add formats R8, RG88, GR88
On 21 April 2016 at 16:32, Dongseong Hwang wrote: > Follow-up of kernel patch: > https://lists.freedesktop.org/archives/dri-devel/2015-July/086041.html > > The Kodi/XBMC and ChromeOS developers want to transcode NV12 to RGB > with OpenGL shaders, importing the two source planes through > EGL_EXT_image_dma_buf_import. That requires importing the Y plane as an > R8 EGLImage and the UV plane as either an RG88 or GR88 EGLImage. > Can we please add a note about the commit and tree where this is based on. See how Danel Vetter has done it recently (barring the typo -s/fromd/from/). Thank you ! Emil
[PATCH] libdrm/fourcc: Add formats R8, RG88, GR88, NV24, NV42
Follow-up of kernel patch:
https://lists.freedesktop.org/archives/dri-devel/2015-July/086041.html
Generate it using `make headers_install`
ChromeOS will use new format to optimize video decoding.
CC: Stéphane Marchesin
CC: Daniele Castagna
Cc: Rainer Hochecker
Cc: Benjamin Widawsky
CC: Chad Versace
Signed-off-by: Dongseong Hwang
---
include/drm/drm_fourcc.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index e741b09..bf68099 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -34,6 +34,13 @@
/* color index */
#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C */
+/* 8 bpp Red */
+#define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
+
+/* 16 bpp RG */
+#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /*
[15:0] R:G 8:8 little endian */
+#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /*
[15:0] G:R 8:8 little endian */
+
/* 8 bpp RGB */
#define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B
3:3:2 */
#define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R
2:3:3 */
@@ -106,6 +113,8 @@
#define DRM_FORMAT_NV21fourcc_code('N', 'V', '2', '1') /* 2x2
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV16fourcc_code('N', 'V', '1', '6') /* 2x1
subsampled Cr:Cb plane */
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
+#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
* 3 plane YCbCr
@@ -216,7 +225,7 @@
* - multiple of 128 pixels for the width
* - multiple of 32 pixels for the height
*
- * For more information: see
http://linuxtv.org/downloads/v4l-dvb-apis/re32.html
+ * For more information: see
https://linuxtv.org/downloads/v4l-dvb-apis/re32.html
*/
#define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1)
--
2.5.0
[PATCH] libdrm/fourcc: Add formats R8, RG88, GR88, NV24, NV42
Hi Stéphane and Daniele,
Could you give me lgtm?
Daniel wants someone from client side to ack this change in order to land
it.
Kind Regards,
Dongseong
On Thu, Apr 21, 2016 at 7:02 PM, Dongseong Hwang
wrote:
> Follow-up of kernel patch:
> https://lists.freedesktop.org/archives/dri-devel/2015-July/086041.html
>
> Generate it using `make headers_install`
>
> ChromeOS will use new format to optimize video decoding.
>
> CC: Stéphane Marchesin
> CC: Daniele Castagna
> Cc: Rainer Hochecker
> Cc: Benjamin Widawsky
> CC: Chad Versace
> Signed-off-by: Dongseong Hwang
> ---
> include/drm/drm_fourcc.h | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index e741b09..bf68099 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -34,6 +34,13 @@
> /* color index */
> #define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C
> */
>
> +/* 8 bpp Red */
> +#define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R
> */
> +
> +/* 16 bpp RG */
> +#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /*
> [15:0] R:G 8:8 little endian */
> +#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /*
> [15:0] G:R 8:8 little endian */
> +
> /* 8 bpp RGB */
> #define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0]
> R:G:B 3:3:2 */
> #define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0]
> B:G:R 2:3:3 */
> @@ -106,6 +113,8 @@
> #define DRM_FORMAT_NV21fourcc_code('N', 'V', '2', '1') /*
> 2x2 subsampled Cb:Cr plane */
> #define DRM_FORMAT_NV16fourcc_code('N', 'V', '1', '6') /*
> 2x1 subsampled Cr:Cb plane */
> #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /*
> 2x1 subsampled Cb:Cr plane */
> +#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
> non-subsampled Cr:Cb plane */
> +#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
> non-subsampled Cb:Cr plane */
>
> /*
> * 3 plane YCbCr
> @@ -216,7 +225,7 @@
> * - multiple of 128 pixels for the width
> * - multiple of 32 pixels for the height
> *
> - * For more information: see
> http://linuxtv.org/downloads/v4l-dvb-apis/re32.html
> + * For more information: see
> https://linuxtv.org/downloads/v4l-dvb-apis/re32.html
> */
> #define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1)
>
> --
> 2.5.0
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/0aec95a3/attachment.html>
[PATCH 1/2] drm: rcar-du: Add Z-order support for VSP planes
On Thu, Apr 21, 2016 at 04:14:12AM +0300, Laurent Pinchart wrote:
> Make the Z-order of VSP planes configurable through the zpos property,
> exactly as for the native DU planes.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 16
> drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 ++
> 2 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index de7ef041182b..62e9619eaea4 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -180,8 +180,9 @@ static void rcar_du_vsp_plane_setup(struct
> rcar_du_vsp_plane *plane)
>
> WARN_ON(!pixelformat);
>
> - vsp1_du_atomic_update(plane->vsp->vsp, plane->index, pixelformat,
> - fb->pitches[0], paddr, &src, &dst);
> + vsp1_du_atomic_update_zpos(plane->vsp->vsp, plane->index, pixelformat,
> +fb->pitches[0], paddr, &src, &dst,
> +state->zpos);
> }
>
> static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
> @@ -220,8 +221,8 @@ static void rcar_du_vsp_plane_atomic_update(struct
> drm_plane *plane,
> if (plane->state->crtc)
> rcar_du_vsp_plane_setup(rplane);
> else
> - vsp1_du_atomic_update(rplane->vsp->vsp, rplane->index, 0, 0, 0,
> - NULL, NULL);
> + vsp1_du_atomic_update_zpos(rplane->vsp->vsp, rplane->index,
> +0, 0, 0, NULL, NULL, 0);
> }
>
> static const struct drm_plane_helper_funcs rcar_du_vsp_plane_helper_funcs = {
> @@ -269,6 +270,7 @@ static void rcar_du_vsp_plane_reset(struct drm_plane
> *plane)
> return;
>
> state->alpha = 255;
> + state->zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
>
> plane->state = &state->state;
> plane->state->plane = plane;
> @@ -283,6 +285,8 @@ static int rcar_du_vsp_plane_atomic_set_property(struct
> drm_plane *plane,
>
> if (property == rcdu->props.alpha)
> rstate->alpha = val;
> + else if (property == rcdu->props.zpos)
> + rstate->zpos = val;
> else
> return -EINVAL;
>
> @@ -299,6 +303,8 @@ static int rcar_du_vsp_plane_atomic_get_property(struct
> drm_plane *plane,
>
> if (property == rcdu->props.alpha)
> *val = rstate->alpha;
> + else if (property == rcdu->props.zpos)
> + *val = rstate->zpos;
> else
> return -EINVAL;
>
> @@ -378,6 +384,8 @@ int rcar_du_vsp_init(struct rcar_du_vsp *vsp)
>
> drm_object_attach_property(&plane->plane.base,
> rcdu->props.alpha, 255);
> + drm_object_attach_property(&plane->plane.base,
> +rcdu->props.zpos, 1);
> }
>
> return 0;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> index df3bf3805c69..510dcc9c6816 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> @@ -44,6 +44,7 @@ static inline struct rcar_du_vsp_plane
> *to_rcar_vsp_plane(struct drm_plane *p)
> * @state: base DRM plane state
> * @format: information about the pixel format used by the plane
> * @alpha: value of the plane alpha property
> + * @zpos: value of the plane zpos property
> */
> struct rcar_du_vsp_plane_state {
> struct drm_plane_state state;
> @@ -51,6 +52,7 @@ struct rcar_du_vsp_plane_state {
> const struct rcar_du_format_info *format;
>
> unsigned int alpha;
> + unsigned int zpos;
There's lots of effort by various people to create a generic zpos/blending
set of properties. Care to jump onto that effort and making it finally
happen for real? I kinda don't want to have a propliferation of slightly
diffferent zpos/blending props across all the drivers ...
-Daniel
> };
>
> static inline struct rcar_du_vsp_plane_state *
> --
> 2.7.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit
On Wed, Apr 20, 2016 at 10:11 PM, Chris Wilson
wrote:
> On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> > +static void gen7_update_oacontrol_locked(struct drm_i915_private
> *dev_priv)
> > +{
> > + assert_spin_locked(&dev_priv->perf.hook_lock);
> > +
> > + if (dev_priv->perf.oa.exclusive_stream->enabled) {
> > + unsigned long ctx_id = 0;
> > +
> > + if (dev_priv->perf.oa.exclusive_stream->ctx)
> > + ctx_id = dev_priv->perf.oa.specific_ctx_id;
> > +
> > + if (dev_priv->perf.oa.exclusive_stream->ctx == NULL ||
> ctx_id) {
> > + bool periodic = dev_priv->perf.oa.periodic;
> > + u32 period_exponent =
> dev_priv->perf.oa.period_exponent;
> > + u32 report_format =
> dev_priv->perf.oa.oa_buffer.format;
> > +
> > + I915_WRITE(GEN7_OACONTROL,
> > +(ctx_id & GEN7_OACONTROL_CTX_MASK) |
> > +(period_exponent <<
> > + GEN7_OACONTROL_TIMER_PERIOD_SHIFT) |
> > +(periodic ?
> > + GEN7_OACONTROL_TIMER_ENABLE : 0) |
> > +(report_format <<
> > + GEN7_OACONTROL_FORMAT_SHIFT) |
> > +(ctx_id ?
> > + GEN7_OACONTROL_PER_CTX_ENABLE : 0) |
> > +GEN7_OACONTROL_ENABLE);
>
> So this works by only recording when the OACONTROL context address
> matches the CCID.
>
> Rather than hooking into switch context and checking every batch whether
> you have the exclusive context in case it changed address, you could
> just pin the exclusive context when told by the user to bind perf to
> that context. Then it will also have the same address until oa is
> finished (and releases it vma pin).
>
Yeah, this was the approach I first went with when the driver was perf
based, though we ended up deciding to got with hooking into pinning and
updating the OA state in the end.
E.g. for reference:
https://lists.freedesktop.org/archives/intel-gfx/2014-November/055385.html
(wow, sad face after seeing how long I've been kicking this stuff)
I'd prefer to stick with this approach now, unless you see a big problem
with it.
Regards,
- Robert
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/2276a1b8/attachment-0001.html>
[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit
On Thu, Apr 21, 2016 at 04:43:19PM +0100, Robert Bragg wrote:
>On Wed, Apr 20, 2016 at 11:52 PM, Chris Wilson
><[1]chris at chris-wilson.co.uk> wrote:
>
> On Wed, Apr 20, 2016 at 03:23:10PM +0100, Robert Bragg wrote:
> > +static int i915_oa_read(struct i915_perf_stream *stream,
> > +Â Â Â Â Â Â Â Â Â Â Â struct i915_perf_read_state
> *read_state)
> > +{
> > +Â Â Â struct drm_i915_private *dev_priv = stream->dev_priv;
> > +
> > +Â Â Â return dev_priv->perf.oa.ops.read(stream, read_state);
> > +}
>
> > +Â Â Â stream->destroy = i915_oa_stream_destroy;
> > +Â Â Â stream->enable = i915_oa_stream_enable;
> > +Â Â Â stream->disable = i915_oa_stream_disable;
> > +Â Â Â stream->can_read = i915_oa_can_read;
> > +Â Â Â stream->wait_unlocked = i915_oa_wait_unlocked;
> > +Â Â Â stream->poll_wait = i915_oa_poll_wait;
> > +Â Â Â stream->read = i915_oa_read;
>
> Why aren't these a const ops table?
>
>No particular reason; I guess it just seemed straightforward enough at the
>time. I suppose it avoids some redundant pointer indirection and could
>suit defining streams in the future that might find it awkward to have
>static ops (don't have anything like that in mind though) but it's at the
>expense of a slightly larger stream struct (though also don't see that as
>a concern currently).
>
>Can change if you like.
I think it is safe to say it is considered best practice to have vfunc
tables in read-only memory. Certainly raises an eyebrow when they look
like they could be modified on the fly.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
[PATCH v3 04/19] clk: sunxi: Add TCON channel1 clock
On Fri, Apr 15, 2016 at 03:39:36PM -0700, Stephen Boyd wrote: > On 03/23, Maxime Ripard wrote: > > The TCON is a controller generating the timings to output videos signals, > > acting like both a CRTC and an encoder. > > > > It has two channels depending on the output, each channel being driven by > > its own clock (and own clock controller). > > > > Add a driver for the channel 1 clock. > > > > Signed-off-by: Maxime Ripard > > Acked-by: Rob Herring > > --- > > Acked-by: Stephen Boyd Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/2a0917b5/attachment.sig>
[Bug 93144] [radeonsi] Alien: Isolation feature request
https://bugs.freedesktop.org/show_bug.cgi?id=93144 --- Comment #37 from Nicolai H�hnle --- Can you open a new bug report for this and provide an apitrace? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/e5381b59/attachment.html>
[PATCH] libdrm/fourcc: Add formats R8, RG88, GR88
yes, I'll send new patch without footer.
On Tue, Apr 12, 2016 at 7:15 PM, Daniel Vetter wrote:
> On Tue, Apr 12, 2016 at 12:57:45PM +, Hwang, Dongseong wrote:
> > Follow-up of the kernel patch:
> https://lists.freedesktop.org/archives/dri-devel/2015-July/086041.html
> >
> > The Kodi/XBMC and ChromeOS developers want to transcode NV12 to RGB
> > with OpenGL shaders, importing the two source planes through
> > EGL_EXT_image_dma_buf_import. That requires importing the Y plane as an
> > R8 EGLImage and the UV plane as either an RG88 or GR88 EGLImage.
> >
> > CC: Peter Frühberger
> > Cc: Rainer Hochecker
> > Cc: Benjamin Widawsky
> > CC: Chad Versace
> > Signed-off-by: Dongseong Hwang
> > ---
> > include/drm/drm_fourcc.h | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> > index e741b09..ca2f488 100644
> > --- a/include/drm/drm_fourcc.h
> > +++ b/include/drm/drm_fourcc.h
> > @@ -34,6 +34,13 @@
> > /* color index */
> > #define DRM_FORMAT_C8fourcc_code('C', '8', ' ', ' ') /*
> [7:0] C */
> >
> > +/* 8 bpp Red */
> > +#define DRM_FORMAT_R8fourcc_code('R', '8', ' ', ' ') /*
> [7:0] R */
> > +
> > +/* 16 bpp RG */
> > +#define DRM_FORMAT_RG88 fourcc_code('R', 'G', '8', '8') /*
> [15:0] R:G 8:8 little endian */
> > +#define DRM_FORMAT_GR88 fourcc_code('G', 'R', '8', '8') /*
> [15:0] G:R 8:8 little endian */
> > +
> > /* 8 bpp RGB */
> > #define DRM_FORMAT_RGB332fourcc_code('R', 'G', 'B', '8') /* [7:0]
> R:G:B 3:3:2 */
> > #define DRM_FORMAT_BGR233fourcc_code('B', 'G', 'R', '8') /* [7:0]
> B:G:R 2:3:3 */
> > --
> > 2.5.0
> > -
> > Intel Finland Oy
> > Registered Address: PL 281, 00181 Helsinki
> > Business Identity Code: 0357606 - 4
> > Domiciled in Helsinki
> >
> > This e-mail and any attachments may contain confidential material for
> > the sole use of the intended recipient(s). Any review or distribution
> > by others is strictly prohibited. If you are not the intended
> > recipient, please contact the sender and delete all copies.
>
> You need to resend without this footer, otherwise I can't merge the patch.
> -Daniel
>
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> -
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki
> Business Identity Code: 0357606 - 4
> Domiciled in Helsinki
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/e92b7ede/attachment.html>
[PATCH] libdrm/fourcc: Add formats R8, RG88, GR88
Ok, I'll send new patch with the commit and tree. Thanks and Regards, Dongseong On Thu, Apr 21, 2016 at 7:02 PM, Emil Velikov wrote: > On 21 April 2016 at 16:32, Dongseong Hwang > wrote: > > Follow-up of kernel patch: > https://lists.freedesktop.org/archives/dri-devel/2015-July/086041.html > > > > The Kodi/XBMC and ChromeOS developers want to transcode NV12 to RGB > > with OpenGL shaders, importing the two source planes through > > EGL_EXT_image_dma_buf_import. That requires importing the Y plane as an > > R8 EGLImage and the UV plane as either an RG88 or GR88 EGLImage. > > > > Can we please add a note about the commit and tree where this is based on. > See how Danel Vetter has done it recently (barring the typo > -s/fromd/from/). > > Thank you ! > Emil > -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/01cf1f29/attachment-0001.html>
[PATCH] libdrm/fourcc: Add formats R8, RG88, GR88, NV24, NV42
As it's landed in kernel, it doesn't need ack from client users.
Sorry for noise.
In addition, I'll send new patch with tree and commit sha info.
- Dongseong
On Thu, Apr 21, 2016 at 7:06 PM, Hwang, Dongseong wrote:
> Hi Stéphane and Daniele,
>
> Could you give me lgtm?
> Daniel wants someone from client side to ack this change in order to land
> it.
>
> Kind Regards,
> Dongseong
>
> On Thu, Apr 21, 2016 at 7:02 PM, Dongseong Hwang <
> dongseong.hwang at intel.com> wrote:
>
>> Follow-up of kernel patch:
>> https://lists.freedesktop.org/archives/dri-devel/2015-July/086041.html
>>
>> Generate it using `make headers_install`
>>
>> ChromeOS will use new format to optimize video decoding.
>>
>> CC: Stéphane Marchesin
>> CC: Daniele Castagna
>> Cc: Rainer Hochecker
>> Cc: Benjamin Widawsky
>> CC: Chad Versace
>> Signed-off-by: Dongseong Hwang
>> ---
>> include/drm/drm_fourcc.h | 11 ++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
>> index e741b09..bf68099 100644
>> --- a/include/drm/drm_fourcc.h
>> +++ b/include/drm/drm_fourcc.h
>> @@ -34,6 +34,13 @@
>> /* color index */
>> #define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0]
>> C */
>>
>> +/* 8 bpp Red */
>> +#define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0]
>> R */
>> +
>> +/* 16 bpp RG */
>> +#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8')
>> /* [15:0] R:G 8:8 little endian */
>> +#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8')
>> /* [15:0] G:R 8:8 little endian */
>> +
>> /* 8 bpp RGB */
>> #define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0]
>> R:G:B 3:3:2 */
>> #define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0]
>> B:G:R 2:3:3 */
>> @@ -106,6 +113,8 @@
>> #define DRM_FORMAT_NV21fourcc_code('N', 'V', '2', '1')
>> /* 2x2 subsampled Cb:Cr plane */
>> #define DRM_FORMAT_NV16fourcc_code('N', 'V', '1', '6')
>> /* 2x1 subsampled Cr:Cb plane */
>> #define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1')
>> /* 2x1 subsampled Cb:Cr plane */
>> +#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4')
>> /* non-subsampled Cr:Cb plane */
>> +#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2')
>> /* non-subsampled Cb:Cr plane */
>>
>> /*
>> * 3 plane YCbCr
>> @@ -216,7 +225,7 @@
>> * - multiple of 128 pixels for the width
>> * - multiple of 32 pixels for the height
>> *
>> - * For more information: see
>> http://linuxtv.org/downloads/v4l-dvb-apis/re32.html
>> + * For more information: see
>> https://linuxtv.org/downloads/v4l-dvb-apis/re32.html
>> */
>> #define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG,
>> 1)
>>
>> --
>> 2.5.0
>>
>>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160421/93efe6d1/attachment.html>
[PATCH v2] libdrm/fourcc: Add formats R8, RG88, GR88, NV24, NV42
Produced from headers_install of 9dabb0053b63bc32ab6ad5d13209d1e43395313f
(drm-intel-nightly) in the kernel.
ChromeOS will use new format to optimize video decoding.
CC: Stéphane Marchesin
CC: Daniele Castagna
CC: Emil Velikov
Cc: Rainer Hochecker
Cc: Benjamin Widawsky
CC: Chad Versace
Signed-off-by: Dongseong Hwang
---
include/drm/drm_fourcc.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index e741b09..bf68099 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -34,6 +34,13 @@
/* color index */
#define DRM_FORMAT_C8 fourcc_code('C', '8', ' ', ' ') /* [7:0] C */
+/* 8 bpp Red */
+#define DRM_FORMAT_R8 fourcc_code('R', '8', ' ', ' ') /* [7:0] R */
+
+/* 16 bpp RG */
+#define DRM_FORMAT_RG88fourcc_code('R', 'G', '8', '8') /*
[15:0] R:G 8:8 little endian */
+#define DRM_FORMAT_GR88fourcc_code('G', 'R', '8', '8') /*
[15:0] G:R 8:8 little endian */
+
/* 8 bpp RGB */
#define DRM_FORMAT_RGB332 fourcc_code('R', 'G', 'B', '8') /* [7:0] R:G:B
3:3:2 */
#define DRM_FORMAT_BGR233 fourcc_code('B', 'G', 'R', '8') /* [7:0] B:G:R
2:3:3 */
@@ -106,6 +113,8 @@
#define DRM_FORMAT_NV21fourcc_code('N', 'V', '2', '1') /* 2x2
subsampled Cb:Cr plane */
#define DRM_FORMAT_NV16fourcc_code('N', 'V', '1', '6') /* 2x1
subsampled Cr:Cb plane */
#define DRM_FORMAT_NV61fourcc_code('N', 'V', '6', '1') /* 2x1
subsampled Cb:Cr plane */
+#define DRM_FORMAT_NV24fourcc_code('N', 'V', '2', '4') /*
non-subsampled Cr:Cb plane */
+#define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /*
non-subsampled Cb:Cr plane */
/*
* 3 plane YCbCr
@@ -216,7 +225,7 @@
* - multiple of 128 pixels for the width
* - multiple of 32 pixels for the height
*
- * For more information: see
http://linuxtv.org/downloads/v4l-dvb-apis/re32.html
+ * For more information: see
https://linuxtv.org/downloads/v4l-dvb-apis/re32.html
*/
#define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1)
--
2.5.0
[PATCH v2] libdrm/fourcc: Add formats R8, RG88, GR88, NV24, NV42
On 21 April 2016 at 18:46, Dongseong Hwang wrote: > Produced from headers_install of 9dabb0053b63bc32ab6ad5d13209d1e43395313f > (drm-intel-nightly) in the kernel. > > ChromeOS will use new format to optimize video decoding. > Did you check before sending the patch out ? As mentioned over IRC a few times - there's no need for the update.danvet already sorted it out. Also, I realise that CrOS development is quite high paced, although some of us prefer quality over quantity. Meaning: don't send multiple emails (spam?) if you have not covered (ideally) all the concerns mentioned. Not doing so is one of the ways to alienate developers. Pretty please ? Thanks Emil
[Intel-gfx] [PATCH] drm: i915: Improve behavior in case of broken HDMI EDID
Daniel,
Thanks a lot for the quick reply!
On 20 Apr 01:34 PM, Daniel Vetter wrote:
> On Tue, Apr 19, 2016 at 02:31:13PM -0300, Ezequiel Garcia wrote:
> > Currently, our implementation of drm_connector_funcs.detect is
> > based on getting a valid EDID.
> >
> > This requirement makes the driver fail to detect connected
> > connectors in case of EDID corruption, which in turn prevents
> > from falling back to modes provided by builtin or user-provided
> > EDIDs.
>
> Imo, this should be fixed in the probe helpers. Something like the below
> might make sense:
>
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index e714b5a7955f..d3b9dc7535da 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -214,7 +214,10 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
> else
> connector->status = connector_status_disconnected;
> if (connector->funcs->force)
> - connector->funcs->force(connector);
> + connector->funcs->force(connector);
> + } else if (connector->override_edid){
> + connector->status = connector_status_connected;
> + connector->funcs->force(connector);
> } else {
> connector->status = connector->funcs->detect(connector, true);
> }
>
>
> It should do what you want it to do, still allow us to override force
> state manually and also fix things up for every, not just i915-hdmi. Also,
> much smaller patch.
>
The patch you are proposing doesn't seem to be related
to the issue I want to fix, so maybe my explanation is still
unclear. After re-reading my commit log, I came to realize
I'm still not explaining the issue properly.
Let me try again :-)
A user can connect any kind of HDMI monitor to the box, and
the kernel should be able to output some video, even when the
HDMI monitor is a piece of crap and sends completely broken EDID.
Currently, the i915 driver uses the return value of intel_hdmi_set_edid()
to set the connector status. IOW, the connector status is set to "connected"
*only* if the EDID is correct, and is left as "disconnected" if the EDID
is corrupt.
However, the connector status can be detected by just probing
the I2C bus (drm_probe_ddc).
The DRM probe helper relies on the .detect callback to decide if
the modes' fallbacks, EDID provided modes, etc are going to be set.
It only set those modes if the .detect callback handler returns
a "connected" status and does nothing if .detect returns
"disconnected".
If the connector is reported as "disconnected" it will skip it and
the user won't be able to use it (except if the state is forced
with a parameter).
I am currently shipping intel boxes without monitors, and the
user can connect its own monitor. I can't know before hand
what device is going to be plugged (neither on which output
connector, HDMI, DVI, etc)... so I am not able to force any state.
The patch I am proposing makes the kernel work without any
user intervention, in the face of corrupted EDID coming out of
a monitor. This works because the .detect logic after my patch
just checks if a I2C device is present in the bus to mark the
connector as "connected" and does not use the EDID parsing for that.
In fact, the EDID parsing is moved to .get_modes() since they're
not really used before. This at the very least, is consistent with
how other drivers work (I'm not inventing anything).
Maybe the following commit log is better. How does it look now?
--8<--
drm: i915: Fix HDMI connector status detection in case of broken EDID
The i915 DRM driver attempts to parse the EDID in the HDMI connector
.detect callback and use the return status of intel_hdmi_set_edid()
to decide if the connector status is connected or disconnected.
The problem is that intel_hdmi_set_edid() fails if the EDID is not
correct (i.e: corrupted) and so .detect will wrongly report to the
DRM core that the connector is disconnected.
It's totally acceptable to use a HDMI connector even in the case of
a broken EDID, by using the CONFIG_DRM_LOAD_EDID_FIRMWARE
and noedid fallback options. The only thing that .detect should
check is that there is a device answering in the correct I2C address
and bus.
So this patch changes the .detect logic to just check the DDC presence
to decide the connector status, so the core can set the EDID fallbacks.
Also, checking for the EDID in the .connect callback doesn't seem to be
correct since that should only check that the connector has been hooked
so this patch also moves the EDID parsing logic to the .get_modes handler
when the modes are actually needed and filled to report to user-space.
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
[PATCH 2/8] drm/udl: Change drm_fb_helper_sys_*() calls to sys_*()
Den 21.04.2016 09:28, skrev Daniel Vetter:
> On Wed, Apr 20, 2016 at 08:15:30PM +0200, Noralf Trønnes wrote:
>> Den 20.04.2016 19:42, skrev Daniel Vetter:
>>> On Wed, Apr 20, 2016 at 05:25:23PM +0200, Noralf Trønnes wrote:
Now that drm_fb_helper gets deferred io support, the
drm_fb_helper_sys_{fillrect,copyarea,imageblit} functions will schedule
the worker that calls the deferred_io callback. This will break this
driver so use the sys_{fillrect,copyarea,imageblit} functions directly.
Signed-off-by: Noralf Trønnes
>>> I think this intermediately breaks the build, if you disable fbdev
>>> support. That's now supported in the fbdev helpers core generically across
>>> all drivers.
>>>
>>> Not sure how to best fix this up, since the only way would be to squash
>>> these patches, plus generic deferred io plus the conversion patches for
>>> udl/qxl all into one. Tricky.
>> Yes you're right, I missed that.
>> How about this:
>> #ifdef CONFIG_FB
>> sys_fillrect(info, rect);
>> #endif
>>
>> The later patch will then remove this ugliness...
> Yeah I think we have to bite the bullet and take this temporary ugliness
> :(
Turns out the #ifdef isn't necessary since FB is always selected.
Both udl and qxl have this:
select DRM_KMS_HELPER
select DRM_KMS_FB_HELPER
And then we have:
config DRM_KMS_HELPER
tristate
depends on DRM
config DRM_KMS_FB_HELPER
bool
depends on DRM_KMS_HELPER
select FB
...
select FB_SYS_FILLRECT
select FB_SYS_COPYAREA
select FB_SYS_IMAGEBLIT
Noralf.
[PATCH] drm/exynos/hdmi: Don't print error on deferral due to regulators
The regulators may not be available just because their driver's probe
function was just not executed and so the regulators not registered.
So, in this case the Exynos HDMI driver should not print logs since
a -EPROBE_DEFER is not really an error and that will just pollute
the kernel log and confuse users.
This patch prevents the following misleading messages to be printed:
[1.443638] [drm:hdmi_probe] *ERROR* failed to get regulators
[1.449326] [drm:hdmi_probe] *ERROR* hdmi_resources_init failed
Reported-by: Krzysztof Kozlowski
Signed-off-by: Javier Martinez Canillas
---
The real fix for these kind of issues is to change the device model
core to support device dependencies so the number of probe deferral
should be minimal or non-existent, instead of fixing on each driver.
But there have been different attempts [0,1] to implement this and
there doesn't seem that this will be solved in the short term.
[0]: https://lkml.org/lkml/2014/5/12/452
[1]: https://lkml.org/lkml/2015/5/25/251
drivers/gpu/drm/exynos/exynos_hdmi.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index e148d728e28c..dcac78b8aa16 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1728,7 +1728,8 @@ static int hdmi_resources_init(struct hdmi_context *hdata)
}
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(supply),
hdata->regul_bulk);
if (ret) {
- DRM_ERROR("failed to get regulators\n");
+ if (ret != -EPROBE_DEFER)
+ DRM_ERROR("failed to get regulators\n");
return ret;
}
@@ -1852,7 +1853,8 @@ static int hdmi_probe(struct platform_device *pdev)
ret = hdmi_resources_init(hdata);
if (ret) {
- DRM_ERROR("hdmi_resources_init failed\n");
+ if (ret != -EPROBE_DEFER)
+ DRM_ERROR("hdmi_resources_init failed\n");
return ret;
}
--
2.5.5
[PATCH 4/8] drm/fb-helper: Add fb_deferred_io support
Den 20.04.2016 17:25, skrev Noralf Trønnes:
> This adds deferred io support if CONFIG_FB_DEFERRED_IO is enabled.
> Accumulated fbdev framebuffer changes are signaled using the callback
> (struct drm_framebuffer_funcs *)->dirty()
>
> The drm_fb_helper_sys_*() functions will accumulate changes and
> schedule fb_info.deferred_work _if_ fb_info.fbdefio is set.
> This worker is used by the deferred io mmap code to signal that it
> has been collecting page faults. The page faults and/or other changes
> are then merged into a drm_clip_rect and passed to the framebuffer
> dirty() function.
>
> The driver is responsible for setting up the fb_info.fbdefio structure
> and calling fb_deferred_io_init() using the provided callback:
> (struct fb_deferred_io).deferred_io = drm_fb_helper_deferred_io;
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_fb_helper.c | 119
> +++-
> include/drm/drm_fb_helper.h | 15 +
> 2 files changed, 133 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
[...]
> +#ifdef CONFIG_FB_DEFERRED_IO
> +/**
> + * drm_fb_helper_deferred_io() - (struct fb_deferred_io *)->deferred_io
> callback
> + * function
> + *
> + * This function always runs in process context (struct delayed_work) and
> calls
> + * the (struct drm_framebuffer_funcs)->dirty function with the collected
> + * damage. There's no need to worry about the possibility that the fb_sys_*()
> + * functions could be running in atomic context. They only schedule the
> + * delayed worker which then calls this deferred_io callback.
> + */
> +void drm_fb_helper_deferred_io(struct fb_info *info,
> +struct list_head *pagelist)
> +{
> + struct drm_fb_helper *helper = info->par;
> + unsigned long start, end, min, max;
> + struct drm_clip_rect clip;
> + unsigned long flags;
> + struct page *page;
> +
> + if (!helper->fb->funcs->dirty)
> + return;
> +
> + spin_lock_irqsave(&helper->dirty_lock, flags);
> + clip = helper->dirty_clip;
> + drm_clip_rect_reset(&helper->dirty_clip);
> + spin_unlock_irqrestore(&helper->dirty_lock, flags);
> +
> + min = ULONG_MAX;
> + max = 0;
> + list_for_each_entry(page, pagelist, lru) {
> + start = page->index << PAGE_SHIFT;
> + end = start + PAGE_SIZE - 1;
> + min = min(min, start);
> + max = max(max, end);
> + }
> +
> + if (min < max) {
> + struct drm_clip_rect mmap_clip;
> +
> + mmap_clip.x1 = 0;
> + mmap_clip.x2 = info->var.xres;
> + mmap_clip.y1 = min / info->fix.line_length;
> + mmap_clip.y2 = min_t(u32, max / info->fix.line_length,
> + info->var.yres);
> + drm_clip_rect_merge(&clip, &mmap_clip, 1, 0, 0, 0);
> + }
> +
> + if (!drm_clip_rect_is_empty(&clip))
> + helper->fb->funcs->dirty(helper->fb, NULL, 0, 0, &clip, 1);
> +}
> +EXPORT_SYMBOL(drm_fb_helper_deferred_io);
There is one thing I have wondered about when it comes to deferred io and
long run times for the defio worker with my displays:
Userspace writes to some pages then the deferred io worker kicks off and
runs for 100ms holding the page list mutex. While this is happening,
userspace writes to a new page triggering a page_mkwrite. Now this
function has to wait for the mutex to be released.
Who is actually waiting here and is there a problem that this can last
for 100ms?
Excerpt from drivers/video/fbdev/core/fb_defio.c:
/* vm_ops->page_mkwrite handler */
static int fb_deferred_io_mkwrite(struct vm_area_struct *vma,
struct vm_fault *vmf)
{
...
/* this is a callback we get when userspace first tries to
write to the page. we schedule a workqueue. that workqueue
will eventually mkclean the touched pages and execute the
deferred framebuffer IO. then if userspace touches a page
again, we repeat the same scheme */
...
/* protect against the workqueue changing the page list */
mutex_lock(&fbdefio->lock);
...
/*
* We want the page to remain locked from ->page_mkwrite until
* the PTE is marked dirty to avoid page_mkclean() being called
* before the PTE is updated, which would leave the page ignored
* by defio.
* Do this by locking the page here and informing the caller
* about it with VM_FAULT_LOCKED.
*/
lock_page(page);
/* we loop through the pagelist before adding in order
to keep the pagelist sorted */
list_for_each_entry(cur, &fbdefio->pagelist, lru) {
/* this check is to catch the case where a new
process could start writing to the same page
through a new pte. this new access can cause the
mkwrite even when the original ps's pte is marked
writable */
if (unlike
[PATCH 00/24] drm: add extern C guard for the UAPI headers
[Re-sending to the correct mailing list. Apologies if you've seen it already]
Hi all, David Howells
Dave Airlie pointed out that "polluting" the headers in a manner as seen
with this series might not be too wise. David H, can we hear your view
on the topic ?
Note that these headers are meant to be used by more than just Linux
(various BSD and Solaris come to mind), making things more complicated.
The change:
As some of you may know there are some subtle distinctions between C and
C++ structs/enums, thus one should wrap/annotate them roughly like below.
...
#if defined(__cplusplus)
extern "C" {
#endif
struct foo {
int bar;
...
};
...
#if defined(__cplusplus)
}
#endif
In order to work around the lack of these users can wrap the header
inclusion in the same way. For example:
...
#if defined(__cplusplus)
extern "C" {
#endif
#include
#if defined(__cplusplus)
}
#endif
Yet we should avoid this approach, as it might cause issues [1] [2] [3].
Thus here is a series which systematically updates all the UAPI headers
in one go.
I would prefer if we get this merged in one go. Daniel, is it possible
to go through drm-misc ? The series is already based on it.
Maintainers, does this sound reasonable, can we get a few acks ?
Thanks
Emil
[1]
http://developers.redhat.com/blog/2016/02/29/why-cstdlib-is-more-complicated-than-you-might-think/
[2] https://isocpp.org/wiki/faq/mixing-c-and-cpp
[3]
http://www.oracle.com/technetwork/articles/servers-storage-dev/mixingcandcpluspluscode-305840.html
Cc: Alex Deucher
Cc: Andrzej Hajda
Cc: Ben Skeggs
Cc: Brian Paul
Cc: Christian Gmeiner
Cc: Christian König
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: David Howells
Cc: Eric Anholt
Cc: Erik Faye-Lund
Cc: Gerd Hoffmann
Cc: Inki Dae
Cc: Jani Nikula
Cc: Laurent Pinchart
Cc: Lucas Stach
Cc: Michel Dänzer
Cc: Rob Clark
Cc: Russell King
Cc: Sinclair Yeh
Cc: Thierry Reding
Cc: Thomas Hellstrom
Cc: Tomi Valkeinen
Emil Velikov (24):
drm/amdgpu: add extern C guard for the UAPI header
drm/armada: add extern C guard for the UAPI header
drm: add extern C guard for the UAPI headers
drm/etnaviv: add extern C guard for the UAPI header
drm/exynos: add extern C guard for the UAPI header
drm/i810: add extern C guard for the UAPI header
drm/i915: add extern C guard for the UAPI header
drm/mga: add extern C guard for the UAPI header
drm/msm: add extern C guard for the UAPI header
drm/nouveau: add extern C guard for the UAPI header
drm/nouveau: drop drm/ prefix from include
drm/omap: add extern C guard for the UAPI header
drm/qxl: add extern C guard for the UAPI header
drm/qxl: remove XXX comment from the UAPI header
drm/r128: add extern C guard for the UAPI header
drm/radeon: add extern C guard for the UAPI header
drm/savage: add extern C guard for the UAPI header
drm/sis: add extern C guard for the UAPI header
drm/sis: add missing include drm.h for the UAPI header
drm/tegra: add extern C guard for the UAPI header
drm/vc4: add extern C guard for the UAPI header
drm/via: add extern C guard for the UAPI header
drm/virgl: add extern C guard for the UAPI header
drm/vmwgfx: add extern C guard for the UAPI header
include/uapi/drm/amdgpu_drm.h | 8
include/uapi/drm/armada_drm.h | 8
include/uapi/drm/drm.h | 16
include/uapi/drm/drm_fourcc.h | 8
include/uapi/drm/drm_mode.h| 8
include/uapi/drm/drm_sarea.h | 8
include/uapi/drm/etnaviv_drm.h | 8
include/uapi/drm/exynos_drm.h | 8
include/uapi/drm/i810_drm.h| 8
include/uapi/drm/i915_drm.h| 8
include/uapi/drm/mga_drm.h | 8
include/uapi/drm/msm_drm.h | 8
include/uapi/drm/nouveau_drm.h | 10 +-
include/uapi/drm/omap_drm.h| 8
include/uapi/drm/qxl_drm.h | 9 -
include/uapi/drm/r128_drm.h| 8
include/uapi/drm/radeon_drm.h | 8
include/uapi/drm/savage_drm.h | 8
include/uapi/drm/sis_drm.h | 10 ++
include/uapi/drm/tegra_drm.h | 8
include/uapi/drm/vc4_drm.h | 8
include/uapi/drm/via_drm.h | 8
include/uapi/drm/virtgpu_drm.h | 8
include/uapi/drm/vmwgfx_drm.h | 9 +
24 files changed, 204 insertions(+), 2 deletions(-)
--
2.6.2
[PATCH 01/24] drm/amdgpu: add extern C guard for the UAPI header
Cc: Alex Deucher
Cc: Christian König
Signed-off-by: Emil Velikov
---
include/uapi/drm/amdgpu_drm.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
index 453a76a..cdecf87 100644
--- a/include/uapi/drm/amdgpu_drm.h
+++ b/include/uapi/drm/amdgpu_drm.h
@@ -34,6 +34,10 @@
#include "drm.h"
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
#define DRM_AMDGPU_GEM_CREATE 0x00
#define DRM_AMDGPU_GEM_MMAP0x01
#define DRM_AMDGPU_CTX 0x02
@@ -642,4 +646,8 @@ struct drm_amdgpu_info_hw_ip {
#define AMDGPU_FAMILY_VI 130 /* Iceland, Tonga */
#define AMDGPU_FAMILY_CZ 135 /* Carrizo, Stoney */
+#if defined(__cplusplus)
+}
+#endif
+
#endif
--
2.6.2
[PATCH 06/24] drm/i810: add extern C guard for the UAPI header
Cc: Daniel Vetter
Signed-off-by: Emil Velikov
---
Daniel,
Based on earlier chat that his file has never been used by userspace,
should we just move it for internal usage (to include/drm) ?
Regards,
Emil
---
include/uapi/drm/i810_drm.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/uapi/drm/i810_drm.h b/include/uapi/drm/i810_drm.h
index bdb0287..6e6cf86 100644
--- a/include/uapi/drm/i810_drm.h
+++ b/include/uapi/drm/i810_drm.h
@@ -3,6 +3,10 @@
#include "drm.h"
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
/* WARNING: These defines must be the same as what the Xserver uses.
* if you change them, you must change the defines in the Xserver.
*/
@@ -280,4 +284,8 @@ typedef struct _drm_i810_mc {
unsigned int last_render; /* Last Render Request */
} drm_i810_mc_t;
+#if defined(__cplusplus)
+}
+#endif
+
#endif /* _I810_DRM_H_ */
--
2.6.2
[PATCH 07/24] drm/i915: add extern C guard for the UAPI header
Cc: Daniel Vetter
Cc: Jani Nikula
Signed-off-by: Emil Velikov
---
include/uapi/drm/i915_drm.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index a5524cc..c17d63d 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -29,6 +29,10 @@
#include "drm.h"
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
/* Please note that modifications to all structs defined here are
* subject to backwards-compatibility constraints.
*/
@@ -1170,4 +1174,8 @@ struct drm_i915_gem_context_param {
__u64 value;
};
+#if defined(__cplusplus)
+}
+#endif
+
#endif /* _UAPI_I915_DRM_H_ */
--
2.6.2
