[ANN] HDMI CEC Status Update
For those who are interested in HDMI CEC support I made a little status document that I intend to keep up to date: https://hverkuil.home.xs4all.nl/cec-status.txt My goal is to get CEC supported for any mainlined HDMI driver where the hardware supports CEC. If anyone is working on a CEC driver that I don't know already about, just drop me an email so I can update the status. I also started maintaining a list of DisplayPort to HDMI adapters that support CEC. If you have one that works and is not on the list, then please let me know. Seeing /dev/cecX is not enough, some adapters do not connect the CEC pin, so they won't be able to detect any other CEC devices. See the test instructions in the cec-status.txt file on how to make sure the adapter has a working CEC pin. I plan to do some more testing this week, so hopefully the list will expand. Thanks! Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99488] [r600g]ImageMagick issues in Gaussian Blur kernel
https://bugs.freedesktop.org/show_bug.cgi?id=99488 --- Comment #18 from Jan Vesely --- (In reply to nixscripter from comment #17) > It took longer than I expected, but I'm calling it good. Thanks for all your > work on this! > > Marking RESOLVED FIXED. not sure 'fixed' is the right word. I see 8 ERRORS/FAILS in ImageMagick test suite, each corresponding to an assertion failure. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 01/10] drm: Add drm_{crtc/encoder/connector}_mode_valid()
On Thu, May 25, 2017 at 03:19:13PM +0100, Jose Abreu wrote:
> Add a new helper to call crtc->mode_valid, connector->mode_valid
> and encoder->mode_valid callbacks.
>
> Suggested-by: Ville Syrjälä
> Signed-off-by: Jose Abreu
> Reviewed-by: Daniel Vetter
> Reviewed-by: Andrzej Hajda
> Cc: Carlos Palminha
> Cc: Dave Airlie
>
> Changes v2->v3:
> - Move helpers to drm_probe_helper.c (Daniel)
> - Squeeze patches that introduce helpers into a single
> one (Daniel)
>
> Signed-off-by: Jose Abreu
> ---
> drivers/gpu/drm/drm_crtc_helper_internal.h | 13 ++
> drivers/gpu/drm/drm_probe_helper.c | 38
> ++
> 2 files changed, 51 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc_helper_internal.h
> b/drivers/gpu/drm/drm_crtc_helper_internal.h
> index 28295e5..97dfe20 100644
> --- a/drivers/gpu/drm/drm_crtc_helper_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_helper_internal.h
> @@ -26,7 +26,11 @@
> * implementation details and are not exported to drivers.
> */
>
> +#include
> +#include
> #include
> +#include
> +#include
>
> /* drm_fb_helper.c */
> #ifdef CONFIG_DRM_FBDEV_EMULATION
> @@ -62,4 +66,13 @@ static inline int drm_dp_aux_register_devnode(struct
> drm_dp_aux *aux)
> static inline void drm_dp_aux_unregister_devnode(struct drm_dp_aux *aux)
> {
> }
> +
> +/* drm_probe_helper.c */
> +enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc,
> + const struct drm_display_mode *mode);
> +enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
> + const struct drm_display_mode
> *mode);
> +enum drm_mode_status drm_connector_mode_valid(struct drm_connector
> *connector,
> + struct drm_display_mode *mode);
> +
This here is the end of the CONFIG_DRM_DP_AUX_CHARDEV #else block, I've
moved them out to make this compile here.
-Daniel
> #endif
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 1b0c14a..f01abdc 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -38,6 +38,9 @@
> #include
> #include
> #include
> +#include
> +
> +#include "drm_crtc_helper_internal.h"
>
> /**
> * DOC: output probing helper overview
> @@ -113,6 +116,41 @@ static int drm_helper_probe_add_cmdline_mode(struct
> drm_connector *connector)
> return 1;
> }
>
> +enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc,
> + const struct drm_display_mode *mode)
> +{
> + const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
> +
> + if (!crtc_funcs || !crtc_funcs->mode_valid)
> + return MODE_OK;
> +
> + return crtc_funcs->mode_valid(crtc, mode);
> +}
> +
> +enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
> + const struct drm_display_mode *mode)
> +{
> + const struct drm_encoder_helper_funcs *encoder_funcs =
> + encoder->helper_private;
> +
> + if (!encoder_funcs || !encoder_funcs->mode_valid)
> + return MODE_OK;
> +
> + return encoder_funcs->mode_valid(encoder, mode);
> +}
> +
> +enum drm_mode_status drm_connector_mode_valid(struct drm_connector
> *connector,
> + struct drm_display_mode *mode)
> +{
> + const struct drm_connector_helper_funcs *connector_funcs =
> + connector->helper_private;
> +
> + if (!connector_funcs || !connector_funcs->mode_valid)
> + return MODE_OK;
> +
> + return connector_funcs->mode_valid(connector, mode);
> +}
> +
> #define DRM_OUTPUT_POLL_PERIOD (10*HZ)
> /**
> * drm_kms_helper_poll_enable - re-enable output polling.
> --
> 1.9.1
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101229] Global screen tearing (scrolling, Hz miss-match?)
https://bugs.freedesktop.org/show_bug.cgi?id=101229 Bug ID: 101229 Summary: Global screen tearing (scrolling, Hz miss-match?) Product: Mesa Version: 17.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: paul.hancock.17041...@live.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 131571 --> https://bugs.freedesktop.org/attachment.cgi?id=131571&action=edit glxinfo System exhibits uncontrolled screen-tearing that can be seen when moving windows, watching videos or playing games, or any graphical movement in general. The tearing gradually shifts up or down the screen, suggesting its a cycle frequency miss-match (or floating-point error). Has affected mesa 12 and kernel 4.8 onwards. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Do not call drm_dev_unregister twice on drm_unplug_dev
On 30/05/17 05:13 AM, Chris Wilson wrote:
> On Mon, May 29, 2017 at 09:04:07PM +0200, Daniel Vetter wrote:
>> On Mon, May 29, 2017 at 09:02:38PM +0200, Daniel Vetter wrote:
>>> On Sun, May 28, 2017 at 07:16:55PM +0200, Hans de Goede wrote:
Since commit a39be606f99d ("drm: Do a full device unregister when
unplugging") drm_unplug_dev has been calling drm_dev_unregister followed
by a drm_put_dev when open_count reaches 0. This drm_put_dev calls
drm_dev_unregister again. Since drm_dev_unregister is not protected
against being called multiple times this leads to havoc.
This commit fixes this by calling drm_dev_unref instead of drm_put_dev.
Fixes: a39be606f99d ("drm: Do a full device unregister when unplugging")
Cc: Chris Wilson
>
>> One more: When fixing a regression pls cc author/reviewer of the offending
>> patch, for the learning. Adding Chris.
>
> I was CC'ed, the ml stripping headers again?
If you have the "Avoid duplicate copies of messages?" option enabled in
your dri-devel mailing list membership configuration, mailman will
remove you from Cc in the posts it distributes to subscribers. Consider
disabling that option.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 31/37] drm/stm: Drop drm_vblank_cleanup
On 05/24/2017 04:52 PM, Daniel Vetter wrote:
> Again seems just cargo-culted.
>
> Cc: Yannick Fertre
> Cc: Philippe Cornu
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/stm/ltdc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
> index 700cc0800e51..1b9483d4f2a4 100644
> --- a/drivers/gpu/drm/stm/ltdc.c
> +++ b/drivers/gpu/drm/stm/ltdc.c
> @@ -1144,8 +1144,6 @@ void ltdc_unload(struct drm_device *ddev)
>
> DRM_DEBUG_DRIVER("\n");
>
> - drm_vblank_cleanup(ddev);
> -
> if (ldev->panel)
> drm_panel_detach(ldev->panel);
>
>
Acked-by: Philippe Cornu
Many thanks
Philippe
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/gvt: remove redundant -Wall
ping for review ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11] drm: Unplug drm device when unregistering it (v8)
On Mon, May 29, 2017 at 5:25 PM, Chris Wilson wrote:
> convince us to look into this patch again?
> -Chris
>
>> >
>> > drivers/gpu/drm/drm_drv.c | 26 ++
>> > drivers/gpu/drm/udl/udl_drv.c | 3 ++-
>> > include/drm/drmP.h| 6 --
>> > include/drm/drm_drv.h | 1 -
>> > 4 files changed, 12 insertions(+), 24 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> > index b5c6bb4..e1da4d1 100644
>> > --- a/drivers/gpu/drm/drm_drv.c
>> > +++ b/drivers/gpu/drm/drm_drv.c
>> > @@ -355,22 +355,6 @@ void drm_put_dev(struct drm_device *dev)
>> > }
>> > EXPORT_SYMBOL(drm_put_dev);
>> >
>> > -void drm_unplug_dev(struct drm_device *dev)
>> > -{
>> > - /* for a USB device */
>> > - drm_dev_unregister(dev);
>> > -
>> > - mutex_lock(&drm_global_mutex);
>> > -
>> > - drm_device_set_unplugged(dev);
>> > -
>> > - if (dev->open_count == 0) {
>> > - drm_put_dev(dev);
>> > - }
>> > - mutex_unlock(&drm_global_mutex);
>> > -}
>> > -EXPORT_SYMBOL(drm_unplug_dev);
>> > -
>> > /*
>> > * DRM internal mount
>> > * We want to be able to allocate our own "struct address_space" to
>> > control
>> > @@ -733,6 +717,13 @@ static void remove_compat_control_link(struct
>> > drm_device *dev)
>> > kfree(name);
>> > }
>> >
>> > +static inline void drm_device_set_plug_state(struct drm_device *dev,
>> > +bool plugged)
>> > +{
>> > + smp_wmb();
>> > + atomic_set(&dev->unplugged, !plugged);
>> > +}
>> > +
>> > /**
>> > * drm_dev_register - Register DRM device
>> > * @dev: Device to register
>> > @@ -787,6 +778,8 @@ int drm_dev_register(struct drm_device *dev, unsigned
>> > long flags)
>> > if (drm_core_check_feature(dev, DRIVER_MODESET))
>> > drm_modeset_register_all(dev);
>> >
>> > + drm_device_set_plug_state(dev, true);
>> > +
>> > ret = 0;
>> >
>> > DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
>> > @@ -826,6 +819,7 @@ void drm_dev_unregister(struct drm_device *dev)
>> > drm_lastclose(dev);
>> >
>> > dev->registered = false;
>> > + drm_device_set_plug_state(dev, false);
>> >
>> > if (drm_core_check_feature(dev, DRIVER_MODESET))
>> > drm_modeset_unregister_all(dev);
>> > diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
>> > index cd8b017..fc73e24 100644
>> > --- a/drivers/gpu/drm/udl/udl_drv.c
>> > +++ b/drivers/gpu/drm/udl/udl_drv.c
>> > @@ -108,7 +108,8 @@ static void udl_usb_disconnect(struct usb_interface
>> > *interface)
>> > drm_kms_helper_poll_disable(dev);
>> > udl_fbdev_unplug(dev);
>> > udl_drop_usb(dev);
>> > - drm_unplug_dev(dev);
>> > + drm_dev_unregister(dev);
>> > + drm_dev_unref(dev);
>> > }
>> >
>> > /*
>> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
>> > index 3bfafcd..980a204 100644
>> > --- a/include/drm/drmP.h
>> > +++ b/include/drm/drmP.h
>> > @@ -488,12 +488,6 @@ static __inline__ int drm_core_check_feature(struct
>> > drm_device *dev,
>> > return ((dev->driver->driver_features & feature) ? 1 : 0);
>> > }
>> >
>> > -static inline void drm_device_set_unplugged(struct drm_device *dev)
>> > -{
>> > - smp_wmb();
>> > - atomic_set(&dev->unplugged, 1);
>> > -}
>> > -
>> > static inline int drm_device_is_unplugged(struct drm_device *dev)
>> > {
>> > int ret = atomic_read(&dev->unplugged);
>> > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
>> > index 0fefc3f..eb63078 100644
>> > --- a/include/drm/drm_drv.h
>> > +++ b/include/drm/drm_drv.h
>> > @@ -544,7 +544,6 @@ void drm_dev_unregister(struct drm_device *dev);
>> > void drm_dev_ref(struct drm_device *dev);
>> > void drm_dev_unref(struct drm_device *dev);
>> > void drm_put_dev(struct drm_device *dev);
>> > -void drm_unplug_dev(struct drm_device *dev);
>> >
>> > int drm_dev_set_unique(struct drm_device *dev, const char *name);
>
I have no experience writing drivers. So, feel free to disregard my
suggestion if it does not makes sense. I'm trying to update a driver
for a USB device and Hans is helping me with it. I had some problems
when plugging and unplugging the device and ended finding Jeffy's
patch. I made the same changes to the driver I was working on and it
behaved a bit better. When I told Hans about it, he found the problem
with the calls in drm_release.
I'm not sure what is the best way to fix/improve the situation but,
wouldn't it be a good idea to guard dangerous calls like unregister or
unplug so that there are no side effects if they are called more times
then they should? I mean, if a driver does so, it is already broken,
but I think that keeping the kernel safe is a better choice, no?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 20/29] sync_file.txt: standardize document format
Em Wed, 24 May 2017 22:36:36 -0300 Gustavo Padovan escreveu: > Hi Mauro, > > 2017-05-18 Mauro Carvalho Chehab : > > > Each text file under Documentation follows a different > > format. Some doesn't even have titles! > > > > Change its representation to follow the adopted standard, > > using ReST markups for it to be parseable by Sphinx: > > - Use markup for document title and authorship; > > - Mark literal blocks; > > - Use a numbered list for references. > > > > Signed-off-by: Mauro Carvalho Chehab > > --- > > Documentation/sync_file.txt | 23 +-- > > 1 file changed, 13 insertions(+), 10 deletions(-) > > We went ahead and applied this to drm-misc-next. Thanks. OK! Thanks! Mauro ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] drm/exynos: use drm_for_each_connector_iter()
2017년 05월 12일 04:10에 Gustavo Padovan 이(가) 쓴 글:
> From: Gustavo Padovan
>
> Drop legacy drm_for_each_connector() in favor of the race-free
> drm_for_each_connector_iter()
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Signed-off-by: Gustavo Padovan
Seems this patch with other could go to drm-misc.
Signed-off-by : Inki Dae
Thanks,
Inki Dae
>
> ---
> only built-tested!
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index 09d3c4c..db6ef2d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -177,12 +177,13 @@ static int exynos_drm_suspend(struct device *dev)
> {
> struct drm_device *drm_dev = dev_get_drvdata(dev);
> struct drm_connector *connector;
> + struct drm_connector_list_iter conn_iter;
>
> if (pm_runtime_suspended(dev) || !drm_dev)
> return 0;
>
> - drm_modeset_lock_all(drm_dev);
> - drm_for_each_connector(connector, drm_dev) {
> + drm_connector_list_iter_begin(drm_dev, &conn_iter);
> + drm_for_each_connector_iter(connector, &conn_iter) {
> int old_dpms = connector->dpms;
>
> if (connector->funcs->dpms)
> @@ -191,7 +192,7 @@ static int exynos_drm_suspend(struct device *dev)
> /* Set the old mode back to the connector for resume */
> connector->dpms = old_dpms;
> }
> - drm_modeset_unlock_all(drm_dev);
> + drm_connector_list_iter_end(&conn_iter);
>
> return 0;
> }
> @@ -200,12 +201,13 @@ static int exynos_drm_resume(struct device *dev)
> {
> struct drm_device *drm_dev = dev_get_drvdata(dev);
> struct drm_connector *connector;
> + struct drm_connector_list_iter conn_iter;
>
> if (pm_runtime_suspended(dev) || !drm_dev)
> return 0;
>
> - drm_modeset_lock_all(drm_dev);
> - drm_for_each_connector(connector, drm_dev) {
> + drm_connector_list_iter_begin(drm_dev, &conn_iter);
> + drm_for_each_connector_iter(connector, &conn_iter) {
> if (connector->funcs->dpms) {
> int dpms = connector->dpms;
>
> @@ -213,7 +215,7 @@ static int exynos_drm_resume(struct device *dev)
> connector->funcs->dpms(connector, dpms);
> }
> }
> - drm_modeset_unlock_all(drm_dev);
> + drm_connector_list_iter_end(&conn_iter);
>
> return 0;
> }
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 18/37] drm/exynos: Drop drm_vblank_cleanup
Hi Daniel, 2017년 05월 24일 23:51에 Daniel Vetter 이(가) 쓴 글: > Only in the load failure path, where the hardware is quiet anyway. > > Cc: Inki Dae > Cc: Joonyoung Shim > Cc: Seung-Woo Kim > Cc: Kyungmin Park > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c > b/drivers/gpu/drm/exynos/exynos_drm_drv.c > index 50294a7bd29d..1c814b9342af 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c > @@ -376,7 +376,7 @@ static int exynos_drm_bind(struct device *dev) > /* Probe non kms sub drivers and virtual display driver. */ > ret = exynos_drm_device_subdrv_probe(drm); > if (ret) > - goto err_cleanup_vblank; > + goto err_unbind_all; With this change shouldn't you post the patch to remove drm_vblank_init and setup vblank stuff in drm_crtc_init together? I couldn't find the relevant patch on your patch series[1]. As of now, I think resource leak would happen with this patch only. Thanks, Inki Dae [1] http://www.spinics.net/lists/dri-devel/msg142387.html > > drm_mode_config_reset(drm); > > @@ -407,8 +407,6 @@ static int exynos_drm_bind(struct device *dev) > exynos_drm_fbdev_fini(drm); > drm_kms_helper_poll_fini(drm); > exynos_drm_device_subdrv_remove(drm); > -err_cleanup_vblank: > - drm_vblank_cleanup(drm); > err_unbind_all: > component_unbind_all(drm->dev, drm); > err_mode_config_cleanup: > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next
Hi Dave, Entire pile of tags since the previous pull got hold up: drm-intel-next-2017-05-29: More stuff for 4.13: - skl+ wm fixes from Mahesh Kumar - some refactor and tests for i915_sw_fence (Chris) - tune execlist/scheduler code (Chris) - g4x,g33 gpu reset improvements (Chris, Mika) - guc code cleanup (Michal Wajdeczko, Michał Winiarski) - dp aux backlight improvements (Puthikorn Voravootivat) - buffer based guc/host communication (Michal Wajdeczko) drm-intel-next-2017-05-15: Another pile of stuff for 4.12: - OA improvements and fixes from Robert Bragg - fixes for the dp aux backlight driver (Puthikorn Voravootivat) - no RCU during shrinking (unfortunately), from Joonas - small atomic leftovers (better unpin, statified hw verifier), from Maarten - g4x wm fixes (Ville) - piles of cursor fixes/improvements (Ville) - g4x overlay plane support (Ville) - prep for new guc logging/notification (Michal Wajdeczko) - pile of static checker appeasement from Imre - implement dma_buf->kmap, good for testing (Chris) - fine-tune ring handling (Chris) drm-intel-next-2017-05-02: Somehow not much these 2 weeks ... - (hopefully) stability fixes for byt/bsw gt wake (Chris) - tighten up requests (especially restarts) checks and debug tracking (Chris) - unify context handling more for gen5+ (Chris+Joonas) - oddball bugfixes as usual drm-intel-next-2017-04-18: First slice of 4.13 features: new uabi: - extend error state dumping to include non-batch buffers requested by userspace (Chris), so that mesa gets more useful error state dumps - reapply the link status patch, for handlig dp link failures (Manasi). This needs updated -modesetting to work correctly. - Add new _WC cache domain, our assumption that wc can be subsumed by the existing cache domains didn't pan out (Chris) feature work: - first pile of conversion to atomic properties for connectors (Maarten) - refactor dp link rate handling code and related areas (Jani) - split engine info into class and runtime stuff (Oscar Mateo) - more robust wait_for_register code (Chris, Michal Wajdeczko) - fix rcu issues in the shrinker and simplify locking (Joonas) - guc/huc for glk (Anusha) - enable atomic modesetting for vlv/chv (Ville), plus final fixes for that Note that this has a nasty-looking conflict with drm-misc, but just take the code from this pull and s/DRM_ROTATE/DRM_MODE_ROTATE/ to make it compile and you should be good. Also, can you pls roll forward to -rc3? We need a pm patch in there for drm-intel. Cheers, Daniel The following changes since commit 8b03d1ed2c43a2ba5ef3381322ee4515b97381bf: Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-next (2017-05-02 04:46:01 +1000) are available in the git repository at: git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-next-2017-05-29 for you to fetch changes up to cd9f4688a3297c0df0eecc2adaae5812d3e5b997: drm/i915: Update DRIVER_DATE to 20170529 (2017-05-29 09:00:58 +0200) More stuff for 4.13: - skl+ wm fixes from Mahesh Kumar - some refactor and tests for i915_sw_fence (Chris) - tune execlist/scheduler code (Chris) - g4x,g33 gpu reset improvements (Chris, Mika) - guc code cleanup (Michal Wajdeczko, Michał Winiarski) - dp aux backlight improvements (Puthikorn Voravootivat) - buffer based guc/host communication (Michal Wajdeczko) Ander Conselvan de Oliveira (2): drm/i915/glk: Don't allow 12 bpc when htotal is too big drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages Andrea Arcangeli (1): i915: initialize the free_list of the fencing atomic_helper Anusha Srivatsa (3): drm/i915/GuC/GLK: Load GuC on GLK drm/i915/GLK/HuC: Load HuC on GLK drm/i915/huc: Update GLK HuC version Arkadiusz Hiler (1): drm/i915/gen9: Reintroduce WaEnableYV12BugFixInHalfSliceChicken7 Chris Wilson (72): drm/i915: intel_ring.engine is unused drm/i915: Onion unwind for intel_init_ring_common() drm/i915: Park the signaler before sleeping drm/i915: Apply a cond_resched() to the saturated signaler drm/i915: Use the right mapping_gfp_mask for final shmem allocation drm/i915: Assert the engine is idle before overwiting the HWS drm/i915: Advance ring->head fully when idle drm/i915: The shrinker already acquires struct_mutex, so call it unlocked drm/i915: Drain any freed objects prior to hibernation drm/i915: Break up long runs of freeing objects drm/i915: Insert cond_resched() into i915_gem_free_objects drm/i915: Use drm_i915_private directly from debugfs drm/i915: Stop second guessing the caller for intel_uncore_wait_for_register() drm/i915: Stop sleeping from inside gen6_bsd_submit_request() drm/i915: Acquire uncore.lock over intel_uncore_wait_for_register() drm/i915: Use __i
[Bug 100306] System randomly freezes or crashes to the login screen, glitches until rebooted
https://bugs.freedesktop.org/show_bug.cgi?id=100306 --- Comment #27 from MirceaKitsune --- In weekly news, it appears a recent openSUSE Tumbleweed snapshot (which among other changes upgraded Mesa 17.0.5 to 17.1.0) made the issue a lot rarer for the time being: Until this snapshot it was even happening twice a day, hence why it was starting to drive me nuts... now I only seem to get this freeze every 2-3 days of uptime, which is so much more bearable! I worry whether the next snapshot will make the issue more frequent again rather than better... clearly it's one of the important system packages that's messing with it, but I still have no idea which and how. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v11] drm: Unplug drm device when unregistering it (v8)
On Fri, Apr 14, 2017 at 11:15:04AM -0400, Sean Paul wrote:
> On Thu, Apr 13, 2017 at 03:32:44PM +0800, Jeffy Chen wrote:
> > After unbinding drm, the user space may still owns the drm dev fd, and
> > may still be able to call drm ioctl.
> >
> > We're using an unplugged state to prevent something like that, so let's
> > reuse it here.
> >
> > Also drop drm_unplug_dev, because it would be unused after other changes.
> >
> > Verified on rk3399 chromebook kevin(with cros 4.4 kernel), no more crashes
> > when unbinding drm with ui service still running.
> >
> > v2: Fix some commit messages.
> > v3: Reuse unplug status.
> > v4: Add drm_device_set_plug_state helper.
> > v5: Fix hang when unregistering drm dev with open_count 0.
> > v6: Move drm_device_set_plug_state into drm_drv.
> > v7: Add missing drm_dev_unref in udl_drv.
> > v8: Fix compiler errors after enable udl.
> >
> > Signed-off-by: Jeffy Chen
> >
> > ---
>
> Hi Jeffy,
> Given the trouble we've had with this patch already, coupled with the fact
> that
> unbinding while userspace is active is a contrived/pathological case, I don't
> think it's worth picking this patch upstream.
>
> If it's really causing issues downstream, you can add my Reviewed-by for a
> CHROMIUM
> patch, but I'd rather not carry patches in the CrOS repo if we don't need to.
Would a
Fixes: a39be606f99d ("drm: Do a full device unregister when unplugging")
Reported-by: Marco Diego Aurélio Mesquita
Cc: Hans de Goede
convince us to look into this patch again?
-Chris
> >
> > drivers/gpu/drm/drm_drv.c | 26 ++
> > drivers/gpu/drm/udl/udl_drv.c | 3 ++-
> > include/drm/drmP.h| 6 --
> > include/drm/drm_drv.h | 1 -
> > 4 files changed, 12 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index b5c6bb4..e1da4d1 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -355,22 +355,6 @@ void drm_put_dev(struct drm_device *dev)
> > }
> > EXPORT_SYMBOL(drm_put_dev);
> >
> > -void drm_unplug_dev(struct drm_device *dev)
> > -{
> > - /* for a USB device */
> > - drm_dev_unregister(dev);
> > -
> > - mutex_lock(&drm_global_mutex);
> > -
> > - drm_device_set_unplugged(dev);
> > -
> > - if (dev->open_count == 0) {
> > - drm_put_dev(dev);
> > - }
> > - mutex_unlock(&drm_global_mutex);
> > -}
> > -EXPORT_SYMBOL(drm_unplug_dev);
> > -
> > /*
> > * DRM internal mount
> > * We want to be able to allocate our own "struct address_space" to control
> > @@ -733,6 +717,13 @@ static void remove_compat_control_link(struct
> > drm_device *dev)
> > kfree(name);
> > }
> >
> > +static inline void drm_device_set_plug_state(struct drm_device *dev,
> > +bool plugged)
> > +{
> > + smp_wmb();
> > + atomic_set(&dev->unplugged, !plugged);
> > +}
> > +
> > /**
> > * drm_dev_register - Register DRM device
> > * @dev: Device to register
> > @@ -787,6 +778,8 @@ int drm_dev_register(struct drm_device *dev, unsigned
> > long flags)
> > if (drm_core_check_feature(dev, DRIVER_MODESET))
> > drm_modeset_register_all(dev);
> >
> > + drm_device_set_plug_state(dev, true);
> > +
> > ret = 0;
> >
> > DRM_INFO("Initialized %s %d.%d.%d %s for %s on minor %d\n",
> > @@ -826,6 +819,7 @@ void drm_dev_unregister(struct drm_device *dev)
> > drm_lastclose(dev);
> >
> > dev->registered = false;
> > + drm_device_set_plug_state(dev, false);
> >
> > if (drm_core_check_feature(dev, DRIVER_MODESET))
> > drm_modeset_unregister_all(dev);
> > diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
> > index cd8b017..fc73e24 100644
> > --- a/drivers/gpu/drm/udl/udl_drv.c
> > +++ b/drivers/gpu/drm/udl/udl_drv.c
> > @@ -108,7 +108,8 @@ static void udl_usb_disconnect(struct usb_interface
> > *interface)
> > drm_kms_helper_poll_disable(dev);
> > udl_fbdev_unplug(dev);
> > udl_drop_usb(dev);
> > - drm_unplug_dev(dev);
> > + drm_dev_unregister(dev);
> > + drm_dev_unref(dev);
> > }
> >
> > /*
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index 3bfafcd..980a204 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -488,12 +488,6 @@ static __inline__ int drm_core_check_feature(struct
> > drm_device *dev,
> > return ((dev->driver->driver_features & feature) ? 1 : 0);
> > }
> >
> > -static inline void drm_device_set_unplugged(struct drm_device *dev)
> > -{
> > - smp_wmb();
> > - atomic_set(&dev->unplugged, 1);
> > -}
> > -
> > static inline int drm_device_is_unplugged(struct drm_device *dev)
> > {
> > int ret = atomic_read(&dev->unplugged);
> > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > index 0fefc3f..eb63078 100644
> > --- a/include/drm/drm_drv.h
> > +++ b/include/drm/drm_drv.h
> > @@ -544,7 +544,6 @@ void drm_dev_unregister(struct drm_device *dev)
Re: [PATCH v2] drm: Do not call drm_dev_unregister twice on drm_unplug_dev
On Mon, May 29, 2017 at 09:04:07PM +0200, Daniel Vetter wrote:
> On Mon, May 29, 2017 at 09:02:38PM +0200, Daniel Vetter wrote:
> > On Sun, May 28, 2017 at 07:16:55PM +0200, Hans de Goede wrote:
> > > Since commit a39be606f99d ("drm: Do a full device unregister when
> > > unplugging") drm_unplug_dev has been calling drm_dev_unregister followed
> > > by a drm_put_dev when open_count reaches 0. This drm_put_dev calls
> > > drm_dev_unregister again. Since drm_dev_unregister is not protected
> > > against being called multiple times this leads to havoc.
> > >
> > > This commit fixes this by calling drm_dev_unref instead of drm_put_dev.
> > >
> > > Fixes: a39be606f99d ("drm: Do a full device unregister when unplugging")
> > > Cc: Chris Wilson
> One more: When fixing a regression pls cc author/reviewer of the offending
> patch, for the learning. Adding Chris.
I was CC'ed, the ml stripping headers again?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Do not call drm_dev_unregister twice on drm_unplug_dev
On Sun, May 28, 2017 at 07:16:55PM +0200, Hans de Goede wrote:
> Since commit a39be606f99d ("drm: Do a full device unregister when
> unplugging") drm_unplug_dev has been calling drm_dev_unregister followed
> by a drm_put_dev when open_count reaches 0. This drm_put_dev calls
> drm_dev_unregister again. Since drm_dev_unregister is not protected
> against being called multiple times this leads to havoc.
>
> This commit fixes this by calling drm_dev_unref instead of drm_put_dev.
>
> Fixes: a39be606f99d ("drm: Do a full device unregister when unplugging")
> Cc: Chris Wilson
> Cc: Marco Diego Aurélio Mesquita
> Reported-by: Marco Diego Aurélio Mesquita
> Signed-off-by: Hans de Goede
> ---
> Note I don't have any USB display devices at hand for testing atm so
> this patch has only been compile tested.
Not tested it either, but yes we do end up calling
drm_device_unregister() twice and indeed that looks bad.
This morning I was thinking about kselftests to simulate the different
conditions and avoid us having to get our hands dirty with real hw. It
also reminded me of https://patchwork.kernel.org/patch/9678823/ which
has the tantalising prospect of removing drm_unplug_dev() entirely.
Another benefit is the removal of one more call to drm_put_dev() which
has been deprecated for a while.
The patch definitely fixes a bug at first glance, but I wonder if it is
really telling me that the call to drm_device_unregister() here is the
fundamental issue. But I am short of actual answers.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 04/10] drm: Use mode_valid() in atomic modeset
On Thu, May 25, 2017 at 03:19:16PM +0100, Jose Abreu wrote:
> This patches makes use of the new mode_valid() callbacks introduced
> previously to validate the full video pipeline when modesetting.
>
> This calls the connector->mode_valid(), encoder->mode_valid(),
> bridge->mode_valid() and crtc->mode_valid() so that we can
> make sure that the mode will be accepted in every components.
>
> Signed-off-by: Jose Abreu
> Reviewed-by: Daniel Vetter
> Reviewed-by: Andrzej Hajda
> Cc: Carlos Palminha
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: Andrzej Hajda
> Cc: Archit Taneja
> Cc: Laurent Pinchart
>
> Changes v1->v2:
> - Removed call to connector->mode_valid (Ville, Daniel)
> - Changed function name (Ville)
> - Use for_each_new_connector_in_state (Ville)
> - Do not validate if connector and mode didn't change (Ville)
> - Use new helpers to call mode_valid
>
> Signed-off-by: Jose Abreu
Ok, merged up to this one to drm-misc-next, thanks a lot. I'll leave
merging the conversion patches to respective maintainers.
-Daniel
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 76
> +++--
> 1 file changed, 73 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 6426339..21afca4 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -32,6 +32,7 @@
> #include
> #include
>
> +#include "drm_crtc_helper_internal.h"
> #include "drm_crtc_internal.h"
>
> /**
> @@ -452,6 +453,69 @@ static int handle_conflicting_encoders(struct
> drm_atomic_state *state,
> return 0;
> }
>
> +static enum drm_mode_status mode_valid_path(struct drm_connector *connector,
> + struct drm_encoder *encoder,
> + struct drm_crtc *crtc,
> + struct drm_display_mode *mode)
> +{
> + enum drm_mode_status ret;
> +
> + ret = drm_encoder_mode_valid(encoder, mode);
> + if (ret != MODE_OK) {
> + DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] mode_valid() failed\n",
> + encoder->base.id, encoder->name);
> + return ret;
> + }
> +
> + ret = drm_bridge_mode_valid(encoder->bridge, mode);
> + if (ret != MODE_OK) {
> + DRM_DEBUG_ATOMIC("[BRIDGE] mode_valid() failed\n");
> + return ret;
> + }
> +
> + ret = drm_crtc_mode_valid(crtc, mode);
> + if (ret != MODE_OK) {
> + DRM_DEBUG_ATOMIC("[CRTC:%d:%s] mode_valid() failed\n",
> + crtc->base.id, crtc->name);
> + return ret;
> + }
> +
> + return ret;
> +}
> +
> +static int
> +mode_valid(struct drm_atomic_state *state)
> +{
> + struct drm_connector_state *conn_state;
> + struct drm_connector *connector;
> + int i;
> +
> + for_each_new_connector_in_state(state, connector, conn_state, i) {
> + struct drm_encoder *encoder = conn_state->best_encoder;
> + struct drm_crtc *crtc = conn_state->crtc;
> + struct drm_crtc_state *crtc_state;
> + enum drm_mode_status mode_status;
> + struct drm_display_mode *mode;
> +
> + if (!crtc || !encoder)
> + continue;
> +
> + crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
> + if (!crtc_state)
> + continue;
> + if (!crtc_state->mode_changed &&
> !crtc_state->connectors_changed)
> + continue;
> +
> + mode = &crtc_state->mode;
> +
> + mode_status = mode_valid_path(connector, encoder, crtc, mode);
> + if (mode_status != MODE_OK)
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> /**
> * drm_atomic_helper_check_modeset - validate state object for modeset
> changes
> * @dev: DRM device
> @@ -466,13 +530,15 @@ static int handle_conflicting_encoders(struct
> drm_atomic_state *state,
> * 2. &drm_connector_helper_funcs.atomic_check to validate the connector
> state.
> * 3. If it's determined a modeset is needed then all connectors on the
> affected crtc
> *crtc are added and &drm_connector_helper_funcs.atomic_check is run on
> them.
> - * 4. &drm_bridge_funcs.mode_fixup is called on all encoder bridges.
> - * 5. &drm_encoder_helper_funcs.atomic_check is called to validate any
> encoder state.
> + * 4. &drm_encoder_helper_funcs.mode_valid, &drm_bridge_funcs.mode_valid and
> + *&drm_crtc_helper_funcs.mode_valid are called on the affected
> components.
> + * 5. &drm_bridge_funcs.mode_fixup is called on all encoder bridges.
> + * 6. &drm_encoder_helper_funcs.atomic_check is called to validate any
> encoder state.
> *This function is only called when the encoder will be part of a
> configured crtc,
> *it must no
Re: [PATCH 07/37] drm: Extract drm_vblank.[hc]
On 2017-05-24 07:51, Daniel Vetter wrote: > drm_irq.c contains both the irq helper library (optional) and the > vblank support (optional, but part of the modeset uapi, and doesn't > require the use of the irq helpers at all. > > Split this up for more clarity of the scope of the individual bits. > > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/drm-kms.rst |4 +- > drivers/gpu/drm/drm_irq.c | 1623 +--- > drivers/gpu/drm/drm_vblank.c | 1645 > + > include/drm/drmP.h|5 +- > include/drm/drm_file.h|1 + > include/drm/drm_irq.h | 158 +--- > include/drm/drm_prime.h |2 + > include/drm/drm_vblank.h | 181 + > 8 files changed, 1857 insertions(+), 1762 deletions(-) > create mode 100644 drivers/gpu/drm/drm_vblank.c > create mode 100644 include/drm/drm_vblank.h > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > index bfecd21a8cdf..2d77c9580164 100644 > --- a/Documentation/gpu/drm-kms.rst > +++ b/Documentation/gpu/drm-kms.rst > @@ -612,8 +612,8 @@ operation handler. > Vertical Blanking and Interrupt Handling Functions Reference > > > -.. kernel-doc:: include/drm/drm_irq.h > +.. kernel-doc:: include/drm/drm_vblank.h > :internal: > > -.. kernel-doc:: drivers/gpu/drm/drm_irq.c > +.. kernel-doc:: drivers/gpu/drm/drm_vblank.c Is that removing drm_irq from kernel-docs? Why? At least the C files seems to contain valid kernel docs... > :export: > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c > index c7debaad67f8..28d736c3fcb4 100644 > --- a/drivers/gpu/drm/drm_irq.c > +++ b/drivers/gpu/drm/drm_irq.c > /** > * drm_irq_install - install IRQ handler > @@ -571,7 +176,7 @@ int drm_irq_uninstall(struct drm_device *dev) > > WARN_ON(drm_core_check_feature(dev, DRIVER_MODESET)); > > - vblank_disable_and_save(dev, i); > + drm_vblank_disable_and_save(dev, i); This leads to: drivers/gpu/drm/drm_irq.c: In function 'drm_irq_uninstall': drivers/gpu/drm/drm_irq.c:179:4: error: implicit declaration of function 'drm_vblank_disable_and_save' [-Werror=implicit-function-declaration] drm_vblank_disable_and_save(dev, i); ^ Since you moved the function to drm_vblank.c, I guess you have to add a deceleration in drm_vblank.h? -- Stefan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm_atomic_helper_resume() locking changes in v4.12
On Mon, May 29, 2017 at 05:29:55PM +0300, Jyri Sarha wrote: > Hi, > I have "WARN_ON(!drm_modeset_is_locked(&crtc->mutex))" in tilcdc crtc > enable and disable callbacks. Now those warnings are firing when > resuming from suspend and I see that "drm_modeset_lock_all(dev)" has > been removed from "drm_atomic_helper_resume()". > > I guess I should remove those warnings from tilcdc since no other driver > has such warnings in place, but it still seems odd to me that the crtc > enable or disable maybe called without the crtc modeset lock. Ok, thought about why no one else hit this, and the reason is that requiring the modeset locks in the commit function (well the hw commit in commit_tail when using the helpers) is indeed wrong: nonblocking commits don't hold the locks (it might block the next operation). You can check for the modeset locks in your ->mode_fixup or ->atomic_check callbacks though. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fix locking in drm_atomic_helper_resume
In the conversion to drop drm_modeset_lock_all and the magic implicit
context I failed to realize that _resume starts out with a pile of
state copies, but not with the locks. And hence drm_atomic_commit
won't grab these for us.
Cc: Jyri Sarha
Fixes: a5b8444e289c ("drm/atomic-helper: remove modeset_lock_all from
helper_resume")
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Signed-off-by: Daniel Vetter
---
Needs to be applied to drm-misc-fixes for 4.12.
-Daniel
---
drivers/gpu/drm/drm_atomic_helper.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index af07368846e0..a61291c29567 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2669,7 +2669,12 @@ int drm_atomic_helper_resume(struct drm_device *dev,
drm_modeset_acquire_init(&ctx, 0);
while (1) {
+ err = drm_modeset_lock_all_ctx(dev, &ctx);
+ if (err)
+ goto out;
+
err = drm_atomic_helper_commit_duplicated_state(state, &ctx);
+out:
if (err != -EDEADLK)
break;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm_atomic_helper_resume() locking changes in v4.12
On Mon, May 29, 2017 at 05:29:55PM +0300, Jyri Sarha wrote: > Hi, > I have "WARN_ON(!drm_modeset_is_locked(&crtc->mutex))" in tilcdc crtc > enable and disable callbacks. Now those warnings are firing when > resuming from suspend and I see that "drm_modeset_lock_all(dev)" has > been removed from "drm_atomic_helper_resume()". > > I guess I should remove those warnings from tilcdc since no other driver > has such warnings in place, but it still seems odd to me that the crtc > enable or disable maybe called without the crtc modeset lock. > > Is there something wrong with drm_atomic_helper_resume() locking or am > just confused about how the locking in drm works? (The later is probably > true in any case) Oversight in the conversion, i.e. thanks for reporting this bug I'll type the patch to fix it asap :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Do not call drm_dev_unregister twice on drm_unplug_dev
On Mon, May 29, 2017 at 09:02:38PM +0200, Daniel Vetter wrote:
> On Sun, May 28, 2017 at 07:16:55PM +0200, Hans de Goede wrote:
> > Since commit a39be606f99d ("drm: Do a full device unregister when
> > unplugging") drm_unplug_dev has been calling drm_dev_unregister followed
> > by a drm_put_dev when open_count reaches 0. This drm_put_dev calls
> > drm_dev_unregister again. Since drm_dev_unregister is not protected
> > against being called multiple times this leads to havoc.
> >
> > This commit fixes this by calling drm_dev_unref instead of drm_put_dev.
> >
> > Fixes: a39be606f99d ("drm: Do a full device unregister when unplugging")
> > Cc: Chris Wilson
> > Cc: Marco Diego Aurélio Mesquita
> > Reported-by: Marco Diego Aurélio Mesquita
> > Signed-off-by: Hans de Goede
> > ---
> > Note I don't have any USB display devices at hand for testing atm so
> > this patch has only been compile tested.
> > ---
> > Changes in v2:
> > -Remove unnecessary mutex changes
>
> Offending patch is in 4.8 ... do we need cc: stable? Does this need a
> bugreport link?
One more: When fixing a regression pls cc author/reviewer of the offending
patch, for the learning. Adding Chris.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Do not call drm_dev_unregister twice on drm_unplug_dev
On Sun, May 28, 2017 at 07:16:55PM +0200, Hans de Goede wrote:
> Since commit a39be606f99d ("drm: Do a full device unregister when
> unplugging") drm_unplug_dev has been calling drm_dev_unregister followed
> by a drm_put_dev when open_count reaches 0. This drm_put_dev calls
> drm_dev_unregister again. Since drm_dev_unregister is not protected
> against being called multiple times this leads to havoc.
>
> This commit fixes this by calling drm_dev_unref instead of drm_put_dev.
>
> Fixes: a39be606f99d ("drm: Do a full device unregister when unplugging")
> Cc: Chris Wilson
> Cc: Marco Diego Aurélio Mesquita
> Reported-by: Marco Diego Aurélio Mesquita
> Signed-off-by: Hans de Goede
> ---
> Note I don't have any USB display devices at hand for testing atm so
> this patch has only been compile tested.
> ---
> Changes in v2:
> -Remove unnecessary mutex changes
Offending patch is in 4.8 ... do we need cc: stable? Does this need a
bugreport link?
-Daniel
> ---
> drivers/gpu/drm/drm_drv.c | 6 +++---
> drivers/gpu/drm/drm_file.c | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index b5c6bb46a425..30b5382bf877 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -364,9 +364,9 @@ void drm_unplug_dev(struct drm_device *dev)
>
> drm_device_set_unplugged(dev);
>
> - if (dev->open_count == 0) {
> - drm_put_dev(dev);
> - }
> + if (dev->open_count == 0)
> + drm_dev_unref(dev);
> +
> mutex_unlock(&drm_global_mutex);
> }
> EXPORT_SYMBOL(drm_unplug_dev);
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 3783b659cd38..edba71c8ccc3 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -424,7 +424,7 @@ int drm_release(struct inode *inode, struct file *filp)
> if (!--dev->open_count) {
> drm_lastclose(dev);
> if (drm_device_is_unplugged(dev))
> - drm_put_dev(dev);
> + drm_dev_unref(dev);
> }
> mutex_unlock(&drm_global_mutex);
>
> --
> 2.13.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 7/7] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
On Fri, May 26, 2017 at 12:20:48PM +0200, Hans Verkuil wrote:
> On 05/26/2017 09:15 AM, Daniel Vetter wrote:
> > On Thu, May 25, 2017 at 05:06:26PM +0200, Hans Verkuil wrote:
> >> From: Hans Verkuil
> >>
> >> Implement support for this DisplayPort feature.
> >>
> >> The cec device is created whenever it detects an adapter that
> >> has this feature. It is only removed when a new adapter is connected
> >> that does not support this. If a new adapter is connected that has
> >> different properties than the previous one, then the old cec device is
> >> unregistered and a new one is registered to replace the old one.
> >>
> >> Signed-off-by: Hans Verkuil
> >
> > Some small comments below.
> >
> >> ---
> >> drivers/gpu/drm/i915/Kconfig| 11 ++
> >> drivers/gpu/drm/i915/intel_dp.c | 46
> >> +
> >> 2 files changed, 53 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> >> index a5cd5dacf055..f317b13a1409 100644
> >> --- a/drivers/gpu/drm/i915/Kconfig
> >> +++ b/drivers/gpu/drm/i915/Kconfig
> >> @@ -124,6 +124,17 @@ config DRM_I915_GVT_KVMGT
> >> Choose this option if you want to enable KVMGT support for
> >> Intel GVT-g.
> >>
> >> +config DRM_I915_DP_CEC
> >> + tristate "Enable DisplayPort CEC-Tunneling-over-AUX HDMI support"
> >> + depends on DRM_I915 && CEC_CORE
> >> + select DRM_DP_CEC
> >> + help
> >> +Choose this option if you want to enable HDMI CEC support for
> >> +DisplayPort/USB-C to HDMI adapters.
> >> +
> >> +Note: not all adapters support this feature, and even for those
> >> +that do support this often do not hook up the CEC pin.
> >
> > Why Kconfig? There's not anything else optional in i915.ko (except debug
> > stuff ofc), since generally just not worth the pain. Also doesn't seem to
> > be wired up at all :-)
>
> It selects DRM_DP_CEC, but you're right, it can be dropped.
>
> >
> >> +
> >> menu "drm/i915 Debugging"
> >> depends on DRM_I915
> >> depends on EXPERT
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> >> b/drivers/gpu/drm/i915/intel_dp.c
> >> index ee77b519835c..38e17ee2548d 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -32,6 +32,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -1405,6 +1406,7 @@ static void intel_aux_reg_init(struct intel_dp
> >> *intel_dp)
> >> static void
> >> intel_dp_aux_fini(struct intel_dp *intel_dp)
> >> {
> >> + cec_unregister_adapter(intel_dp->aux.cec_adap);
> >>kfree(intel_dp->aux.name);
> >> }
> >>
> >> @@ -4179,6 +4181,33 @@ intel_dp_check_mst_status(struct intel_dp *intel_dp)
> >>return -EINVAL;
> >> }
> >>
> >> +static bool
> >> +intel_dp_check_cec_status(struct intel_dp *intel_dp)
> >> +{
> >> + bool handled = false;
> >> +
> >> + for (;;) {
> >> + u8 cec_irq;
> >> + int ret;
> >> +
> >> + ret = drm_dp_dpcd_readb(&intel_dp->aux,
> >> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
> >> + &cec_irq);
> >> + if (ret < 0 || !(cec_irq & DP_CEC_IRQ))
> >> + return handled;
> >> +
> >> + cec_irq &= ~DP_CEC_IRQ;
> >> + drm_dp_cec_irq(&intel_dp->aux);
> >> + handled = true;
> >> +
> >> + ret = drm_dp_dpcd_writeb(&intel_dp->aux,
> >> + DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1,
> >> + cec_irq);
> >> + if (ret < 0)
> >> + return handled;
> >> + }
> >> +}
> >
> > Shouldn't the above be a helper in the cec library? Doesn't look i915
> > specific to me at least ...
>
> Good point, this can be moved to drm_dp_cec_irq().
>
> >
> >> +
> >> static void
> >> intel_dp_retrain_link(struct intel_dp *intel_dp)
> >> {
> >> @@ -4553,6 +4582,7 @@ intel_dp_set_edid(struct intel_dp *intel_dp)
> >>intel_dp->has_audio = intel_dp->force_audio == HDMI_AUDIO_ON;
> >>else
> >>intel_dp->has_audio = drm_detect_monitor_audio(edid);
> >> + cec_s_phys_addr_from_edid(intel_dp->aux.cec_adap, edid);
> >> }
> >>
> >> static void
> >> @@ -4562,6 +4592,7 @@ intel_dp_unset_edid(struct intel_dp *intel_dp)
> >>
> >>kfree(intel_connector->detect_edid);
> >>intel_connector->detect_edid = NULL;
> >> + cec_phys_addr_invalidate(intel_dp->aux.cec_adap);
> >>
> >>intel_dp->has_audio = false;
> >> }
> >> @@ -4582,13 +4613,17 @@ intel_dp_long_pulse(struct intel_connector
> >> *intel_connector)
> >>intel_display_power_get(to_i915(dev), intel_dp->aux_power_domain);
> >>
> >>/* Can't disconnect eDP, but you can close the lid... */
> >> - if (is_edp(intel_dp))
> >> + if (is_edp(intel_dp)) {
> >>status = edp_detect(intel_dp);
> >> - else if (intel_digital_port_connected(to_i915(dev),
> >> -
Re: [PATCH 08/37] drm/doc: Polish irq helper documentation
On Thu, May 25, 2017 at 12:46:29AM -0700, Stefan Agner wrote: > On 2017-05-24 07:51, Daniel Vetter wrote: > > Pull a (much shorter) overview into drm_irq.c, and instead put the > > callback documentation into in-line comments in drm_drv.h. > > Looks good and just found all I needed to know to fix IRQ registration > in fsl dcu. > > Reviewed-by: Stefan Agner Can you pls ack/review the previous patch 7 too? I can't apply this one here with the other one ... Thanks, Daniel > > > > > Signed-off-by: Daniel Vetter > > --- > > Documentation/gpu/drm-internals.rst | 62 > > + > > drivers/gpu/drm/drm_irq.c | 30 +++--- > > drivers/gpu/drm/drm_vblank.c| 3 ++ > > include/drm/drmP.h | 9 -- > > include/drm/drm_drv.h | 33 ++-- > > 5 files changed, 74 insertions(+), 63 deletions(-) > > > > diff --git a/Documentation/gpu/drm-internals.rst > > b/Documentation/gpu/drm-internals.rst > > index d218dd29221a..82b406d3d377 100644 > > --- a/Documentation/gpu/drm-internals.rst > > +++ b/Documentation/gpu/drm-internals.rst > > @@ -149,60 +149,14 @@ Device Instance and Driver Handling > > Driver Load > > --- > > > > -IRQ Registration > > - > > - > > -The DRM core tries to facilitate IRQ handler registration and > > -unregistration by providing :c:func:`drm_irq_install()` and > > -:c:func:`drm_irq_uninstall()` functions. Those functions only > > -support a single interrupt per device, devices that use more than one > > -IRQs need to be handled manually. > > - > > -Managed IRQ Registration > > - > > - > > -:c:func:`drm_irq_install()` starts by calling the irq_preinstall > > -driver operation. The operation is optional and must make sure that the > > -interrupt will not get fired by clearing all pending interrupt flags or > > -disabling the interrupt. > > - > > -The passed-in IRQ will then be requested by a call to > > -:c:func:`request_irq()`. If the DRIVER_IRQ_SHARED driver feature > > -flag is set, a shared (IRQF_SHARED) IRQ handler will be requested. > > - > > -The IRQ handler function must be provided as the mandatory irq_handler > > -driver operation. It will get passed directly to > > -:c:func:`request_irq()` and thus has the same prototype as all IRQ > > -handlers. It will get called with a pointer to the DRM device as the > > -second argument. > > - > > -Finally the function calls the optional irq_postinstall driver > > -operation. The operation usually enables interrupts (excluding the > > -vblank interrupt, which is enabled separately), but drivers may choose > > -to enable/disable interrupts at a different time. > > - > > -:c:func:`drm_irq_uninstall()` is similarly used to uninstall an > > -IRQ handler. It starts by waking up all processes waiting on a vblank > > -interrupt to make sure they don't hang, and then calls the optional > > -irq_uninstall driver operation. The operation must disable all hardware > > -interrupts. Finally the function frees the IRQ by calling > > -:c:func:`free_irq()`. > > - > > -Manual IRQ Registration > > -''' > > - > > -Drivers that require multiple interrupt handlers can't use the managed > > -IRQ registration functions. In that case IRQs must be registered and > > -unregistered manually (usually with the :c:func:`request_irq()` and > > -:c:func:`free_irq()` functions, or their :c:func:`devm_request_irq()` and > > -:c:func:`devm_free_irq()` equivalents). > > - > > -When manually registering IRQs, drivers must not set the > > -DRIVER_HAVE_IRQ driver feature flag, and must not provide the > > -irq_handler driver operation. They must set the :c:type:`struct > > -drm_device ` irq_enabled field to 1 upon > > -registration of the IRQs, and clear it to 0 after unregistering the > > -IRQs. > > +IRQ Helper Library > > +~~ > > + > > +.. kernel-doc:: drivers/gpu/drm/drm_irq.c > > + :doc: irq helpers > > + > > +.. kernel-doc:: drivers/gpu/drm/drm_irq.c > > + :export: > > > > Memory Manager Initialization > > ~ > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c > > index 28d736c3fcb4..3b04c25100ae 100644 > > --- a/drivers/gpu/drm/drm_irq.c > > +++ b/drivers/gpu/drm/drm_irq.c > > @@ -62,19 +62,39 @@ > > #include "drm_internal.h" > > > > /** > > + * DOC: irq helpers > > + * > > + * The DRM core provides very simple support helpers to enable IRQ > > handling on a > > + * device through the drm_irq_install() and drm_irq_uninstall() functions. > > This > > + * only supports devices with a single interrupt on the main device stored > > in > > + * &drm_device.dev and set as the device paramter in drm_dev_alloc(). > > + * > > + * These IRQ helpers are strictly optional. Drivers which roll their own > > only > > + * need to set &drm_device.irq_enabled to signal the DRM core that vblank > > + * interrupts are working. Since these helpers d
[PATCH 03/15] drm: zte: use devm_of_platform_populate()
Use devm_of_platform_populate() to be sure that of_platform_depopulate is called when removing the driver. Signed-off-by: Benjamin Gaignard CC: Shawn Guo CC: David Airlie CC: dri-devel@lists.freedesktop.org CC: linux-ker...@vger.kernel.org --- drivers/gpu/drm/zte/zx_drm_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c b/drivers/gpu/drm/zte/zx_drm_drv.c index 614e854..f2b1e5f 100644 --- a/drivers/gpu/drm/zte/zx_drm_drv.c +++ b/drivers/gpu/drm/zte/zx_drm_drv.c @@ -196,7 +196,7 @@ static int zx_drm_probe(struct platform_device *pdev) struct component_match *match = NULL; int ret; - ret = of_platform_populate(parent, NULL, NULL, dev); + ret = devm_of_platform_populate(dev); if (ret) return ret; -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/15] drm: msm: use devm_of_platform_populate()
Use devm_of_platform_populate() to simplify driver code.
Signed-off-by: Benjamin Gaignard
CC: Rob Clark
CC: David Airlie
CC: linux-arm-...@vger.kernel.org
CC: dri-devel@lists.freedesktop.org
CC: freedr...@lists.freedesktop.org
CC: linux-ker...@vger.kernel.org
---
drivers/gpu/drm/msm/msm_drv.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 87b5695..545fb6f 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -969,7 +969,7 @@ static int add_display_components(struct device *dev,
* to our components list.
*/
if (of_device_is_compatible(dev->of_node, "qcom,mdss")) {
- ret = of_platform_populate(dev->of_node, NULL, NULL, dev);
+ ret = devm_of_platform_populate(dev);
if (ret) {
dev_err(dev, "failed to populate children devices\n");
return ret;
@@ -978,7 +978,6 @@ static int add_display_components(struct device *dev,
mdp_dev = device_find_child(dev, NULL, compare_name_mdp);
if (!mdp_dev) {
dev_err(dev, "failed to find MDSS MDP node\n");
- of_platform_depopulate(dev);
return -ENODEV;
}
@@ -992,11 +991,7 @@ static int add_display_components(struct device *dev,
mdp_dev = dev;
}
- ret = add_components_mdp(mdp_dev, matchptr);
- if (ret)
- of_platform_depopulate(dev);
-
- return ret;
+ return add_components_mdp(mdp_dev, matchptr);
}
/*
@@ -1072,7 +1067,6 @@ static int msm_pdev_probe(struct platform_device *pdev)
static int msm_pdev_remove(struct platform_device *pdev)
{
component_master_del(&pdev->dev, &msm_drm_ops);
- of_platform_depopulate(&pdev->dev);
return 0;
}
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/15] make more driver use devm_of_platform_populate()
Number of calls to of_platform_populate() aren't unbalanced by a call to of_platform_depopulate() that could generate issue will loading/unloading the drivers. Make those drivers use devm_of_platform_populate() fix the problem without need to add remove function. In some case replacing of_platform_populate() by devm_of_platform_populate() allow to delete driver remove function and save some lines of code. This series of patches based on v4.12-rc3 tag. CC: Alexandre Torgue CC: David Airlie CC: Fabrice Gasnier CC: Hartmut Knaack CC: Jaroslav Kysela CC: Javier Martinez Canillas CC: Jonathan Cameron CC: Krzysztof Kozlowski CC: Kukjin Kim CC: Kyungmin Park CC: Lars-Peter Clausen CC: Lee Jones CC: Liam Girdwood CC: Mark Brown CC: Mauro Carvalho Chehab CC: Olivier Moysan CC: Rob Clark CC: Shawn Guo CC: Sylwester Nawrocki CC: Takashi Iwai CC: Tony Lindgren CC: linux-...@vger.kernel.org CC: linux-arm-ker...@lists.infradead.org CC: linux-ker...@vger.kernel.org CC: dri-devel@lists.freedesktop.org CC: linux-arm-...@vger.kernel.org CC: freedr...@lists.freedesktop.org CC: linux-samsung-...@vger.kernel.org CC: alsa-de...@alsa-project.org CC: linux-me...@vger.kernel.org Benjamin Gaignard (15): iio: adc: stm32: use devm_of_platform_populate() iio: dac: stm32: use devm_of_platform_populate() drm: zte: use devm_of_platform_populate() drm: msm: use devm_of_platform_populate() mfd: stm32-timers: use devm_of_platform_populate mfd: atmel: use devm_of_platform_populate() mfd: cros_ec: use devm_of_platform_populate() mfd: exynos: use devm_of_platform_populate() mfd: fsl-imx25: use devm_of_platform_populate() mfd: motorola-cpcap: use devm_of_platform_populate() mfd: palmas: use devm_of_platform_populate() mfd: qcom-spmi-pmic: use devm_of_platform_populate() mfd: smsc-ece: use devm_of_platform_populate() sound: stm32: use devm_of_platform_populate() media: exynos4-is: use devm_of_platform_populate() drivers/gpu/drm/msm/msm_drv.c | 10 ++ drivers/gpu/drm/zte/zx_drm_drv.c| 2 +- drivers/iio/adc/stm32-adc-core.c| 4 +--- drivers/iio/dac/stm32-dac-core.c| 3 +-- drivers/media/platform/exynos4-is/fimc-is.c | 7 ++- drivers/mfd/atmel-flexcom.c | 2 +- drivers/mfd/cros_ec.c | 2 +- drivers/mfd/exynos-lpass.c | 2 +- drivers/mfd/fsl-imx25-tsadc.c | 5 + drivers/mfd/motorola-cpcap.c| 13 + drivers/mfd/palmas.c| 2 +- drivers/mfd/qcom-spmi-pmic.c| 9 + drivers/mfd/smsc-ece1099.c | 3 +-- drivers/mfd/stm32-timers.c | 10 +- sound/soc/stm/stm32_sai.c | 11 +-- 15 files changed, 17 insertions(+), 68 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm_atomic_helper_resume() locking changes in v4.12
Hi, I have "WARN_ON(!drm_modeset_is_locked(&crtc->mutex))" in tilcdc crtc enable and disable callbacks. Now those warnings are firing when resuming from suspend and I see that "drm_modeset_lock_all(dev)" has been removed from "drm_atomic_helper_resume()". I guess I should remove those warnings from tilcdc since no other driver has such warnings in place, but it still seems odd to me that the crtc enable or disable maybe called without the crtc modeset lock. Is there something wrong with drm_atomic_helper_resume() locking or am just confused about how the locking in drm works? (The later is probably true in any case) Best regards, Jyri ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/meson: Fix driver bind when only CVBS is available
While introducing HDMI support, component matching on connectors node
were bypassed since no driver would actually bind on the DT node.
But when only a CVBS connector is present, only a single node is found
in the graph, but ignored and a NULL match table is given to the
component code.
This code permits bypassing the components framework by binding directly
the DRM driver when no components needs to be loaded.
Fixes: a41e82e6c457 ("drm/meson: Add support for components")
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_drv.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 75382f5..10b227d 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -152,7 +152,7 @@ static bool meson_vpu_has_available_connectors(struct
device *dev)
.max_register = 0x1000,
};
-static int meson_drv_bind(struct device *dev)
+static int meson_drv_bind_master(struct device *dev, bool has_components)
{
struct platform_device *pdev = to_platform_device(dev);
struct meson_drm *priv;
@@ -233,10 +233,12 @@ static int meson_drv_bind(struct device *dev)
if (ret)
goto free_drm;
- ret = component_bind_all(drm->dev, drm);
- if (ret) {
- dev_err(drm->dev, "Couldn't bind all components\n");
- goto free_drm;
+ if (has_components) {
+ ret = component_bind_all(drm->dev, drm);
+ if (ret) {
+ dev_err(drm->dev, "Couldn't bind all components\n");
+ goto free_drm;
+ }
}
ret = meson_plane_create(priv);
@@ -276,6 +278,11 @@ static int meson_drv_bind(struct device *dev)
return ret;
}
+static int meson_drv_bind(struct device *dev)
+{
+ return meson_drv_bind_master(dev, true);
+}
+
static void meson_drv_unbind(struct device *dev)
{
struct drm_device *drm = dev_get_drvdata(dev);
@@ -357,6 +364,9 @@ static int meson_drv_probe(struct platform_device *pdev)
count += meson_probe_remote(pdev, &match, np, remote);
}
+ if (count && !match)
+ return meson_drv_bind_master(&pdev->dev, false);
+
/* If some endpoints were found, initialize the nodes */
if (count) {
dev_info(&pdev->dev, "Queued %d outputs on vpu\n", count);
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-fixes
Hi Dave, fixes all around, including GVT. I guess Joonas' RCU sync fix is the most important one. I've got the DP quirk stuff I asked about sitting on a branch, feeding to drm-tip too, hoping to get a bit more testing on it. I'll send a separate pull request for it later this week. BR, Jani. The following changes since commit 2f720aac936dc7a301b757d3b197d86c333d59b8: drm/i915: don't do allocate_va_range again on PIN_UPDATE (2017-05-15 14:44:33 +0300) are available in the git repository at: git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2017-05-29 for you to fetch changes up to 9bd9590997b92fbd79fd028f704f6c584b4439d7: drm/i915: Stop pretending to mask/unmask LPE audio interrupts (2017-05-26 11:51:18 +0300) drm/i915 fixes for v4.12-rc4 Changbin Du (1): drm/i915/gvt: clean up unsubmited workloads before destroying kmem cache Chris Wilson (1): drm/i915/selftests: Silence compiler warning in igt_ctx_exec Chuanxiao Dong (2): drm/i915: set initialised only when init_context callback is NULL drm/i915/gvt: Disable compression workaround for Gen9 Daniel Vetter (1): Revert "drm/i915: Restore lost "Initialized i915" welcome message" Hans de Goede (1): drm/i915: Fix new -Wint-in-bool-context gcc compiler warning Jani Nikula (1): Merge tag 'gvt-fixes-2017-05-25' of https://github.com/01org/gvt-linux into drm-intel-fixes Joonas Lahtinen (1): drm/i915: Do not sync RCU during shrinking Matthew Auld (1): drm/i915: use vma->size for appgtt allocate_va_range Ville Syrjälä (1): drm/i915: Stop pretending to mask/unmask LPE audio interrupts drivers/gpu/drm/i915/gvt/execlist.c | 30 --- drivers/gpu/drm/i915/gvt/handlers.c | 30 +-- drivers/gpu/drm/i915/i915_drv.c | 4 --- drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +- drivers/gpu/drm/i915/i915_gem_shrinker.c | 5 drivers/gpu/drm/i915/i915_irq.c | 15 -- drivers/gpu/drm/i915/i915_reg.h | 2 +- drivers/gpu/drm/i915/intel_lpe_audio.c| 36 --- drivers/gpu/drm/i915/intel_lrc.c | 2 +- drivers/gpu/drm/i915/selftests/i915_gem_context.c | 8 +++-- 10 files changed, 55 insertions(+), 79 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99349] Failed to build shader (translation from TGSI)
https://bugs.freedesktop.org/show_bug.cgi?id=99349 --- Comment #11 from Gert Wollny --- Created attachment 131567 --> https://bugs.freedesktop.org/attachment.cgi?id=131567&action=edit TGSI for failing shader This is the failing shader. For some reasons 151 GPRs are allocate as TEMP but only 40 actually appear as source for an operation, the remaining ones are all only targets and discarded. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] Android's major/minor/makedev live in
On 28 May 2017 at 15:38, Rob Herring wrote: > On Mon, May 22, 2017 at 11:06 AM, Emil Velikov > wrote: >> On 20 May 2017 at 19:24, enh wrote: >>> Bug: https://github.com/android-ndk/ndk/issues/398 >>> --- >>> Android.common.mk | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/Android.common.mk b/Android.common.mk >>> index 35c0f02c..b45ca10f 100644 >>> --- a/Android.common.mk >>> +++ b/Android.common.mk >>> @@ -1,5 +1,6 @@ >>> # XXX: Consider moving these to config.h analogous to autoconf. >>> LOCAL_CFLAGS += \ >>> + -DMAJOR_IN_SYSMACROS=1 \ >>> -DHAVE_VISIBILITY=1 \ >>> -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1 >>> >>> -- >> Thanks Elliott. >> >> Couple of tips for the future: >> Please set your name - $git config --global user.name "Elliott Hughes". >> If using git send-email is not possible, ensure that your client does >> not mangle with the patch. >> >> Rob, Mauro >> Gents can you check if this patch plays well on your setups. I don't >> want to break things on your end. > > Definitely needed or AOSP master breaks. I've applied it (and a fix > because I forgot the trailing '\'). > Glad to hear that it works as expected. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v5)
Am 29.05.2017 um 09:30 schrieb Dave Airlie:
From: Dave Airlie
This creates a new command submission chunk for amdgpu
to add in and out sync objects around the submission.
Sync objects are managed via the drm syncobj ioctls.
The command submission interface is enhanced with two new
chunks, one for syncobj pre submission dependencies,
and one for post submission sync obj signalling,
and just takes a list of handles for each.
This is based on work originally done by David Zhou at AMD,
with input from Christian Konig on what things should look like.
In theory VkFences could be backed with sync objects and
just get passed into the cs as syncobj handles as well.
NOTE: this interface addition needs a version bump to expose
it to userspace.
TODO: update to dep_sync when rebasing onto amdgpu master.
(with this - r-b from Christian)
v1.1: keep file reference on import.
v2: move to using syncobjs
v2.1: change some APIs to just use p pointer.
v3: make more robust against CS failures, we now add the
wait sems but only remove them once the CS job has been
submitted.
v4: rewrite names of API and base on new syncobj code.
v5: move post deps earlier, rename some apis
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 87 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
include/uapi/drm/amdgpu_drm.h | 6 +++
3 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 30225d7..3cbd547 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "amdgpu.h"
#include "amdgpu_trace.h"
@@ -226,6 +227,8 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void *data)
break;
case AMDGPU_CHUNK_ID_DEPENDENCIES:
+ case AMDGPU_CHUNK_ID_SYNCOBJ_IN:
+ case AMDGPU_CHUNK_ID_SYNCOBJ_OUT:
break;
default:
@@ -1040,6 +1043,40 @@ static int amdgpu_cs_process_fence_dep(struct
amdgpu_cs_parser *p,
return 0;
}
+static int amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
+uint32_t handle)
+{
+ int r;
+ struct dma_fence *fence;
+ r = drm_syncobj_fence_get(p->filp, handle, &fence);
+ if (r)
+ return r;
+
+ r = amdgpu_sync_fence(p->adev, &p->job->sync, fence);
+ dma_fence_put(fence);
+
+ return r;
+}
+
+static int amdgpu_cs_process_syncobj_in_dep(struct amdgpu_cs_parser *p,
+ struct amdgpu_cs_chunk *chunk)
+{
+ unsigned num_deps;
+ int i, r;
+ struct drm_amdgpu_cs_chunk_sem *deps;
+
+ deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+ num_deps = chunk->length_dw * 4 /
+ sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+ for (i = 0; i < num_deps; ++i) {
+ r = amdgpu_syncobj_lookup_and_add_to_sync(p, deps[i].handle);
+ if (r)
+ return r;
+ }
+ return 0;
+}
+
static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
struct amdgpu_cs_parser *p)
{
@@ -1054,12 +1091,54 @@ static int amdgpu_cs_dependencies(struct amdgpu_device
*adev,
r = amdgpu_cs_process_fence_dep(p, chunk);
if (r)
return r;
+ } else if (chunk->chunk_id == AMDGPU_CHUNK_ID_SYNCOBJ_IN) {
+ r = amdgpu_cs_process_syncobj_in_dep(p, chunk);
+ if (r)
+ return r;
}
}
return 0;
}
+static int amdgpu_cs_process_syncobj_out_dep(struct amdgpu_cs_parser *p,
+struct amdgpu_cs_chunk *chunk)
+{
+ unsigned num_deps;
+ int i, r;
+ struct drm_amdgpu_cs_chunk_sem *deps;
+
+ deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+ num_deps = chunk->length_dw * 4 /
+ sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+ for (i = 0; i < num_deps; ++i) {
+ r = drm_syncobj_replace_fence(p->filp, deps[i].handle,
+ p->fence);
+ if (r)
+ return r;
Thinking more about it, here is still a problem with the handling.
Imagine you have multiple semaphores to signal and only the last handle
is invalid.
So if you have n handles then the sync objects 1..(n-1) will get a fence
which is never signaled because n aborts the command submission.
I think the only valid approach to handle this is to resolve the handles
upfront during the initial parsing of the chunks.
Christian.
+ }
+ return 0;
+}
+
+static int amdgpu_cs_post_
Re: [PATCH 23/37] drm/imx: Drop drm_vblank_cleanup
Hi Daniel, On Wed, 2017-05-24 at 16:51 +0200, Daniel Vetter wrote: > It's only done in the driver load error path, where vblanks don't need > to be quiescent anyway. And that's all drm_vblank_cleanup does, since > the core will release the vblank allocations on its own already. So > drop it. Thank you for cleaning this up and improving the docs. From the function name and kerneldoc comment, it was really not clear that this function is already called in the drm_device release path. I think the comment is slightly misleading though, as drm_vblank_cleanup does call kfree(dev->vblank). > Cc: Philipp Zabel > Signed-off-by: Daniel Vetter > > --- > drivers/gpu/drm/imx/imx-drm-core.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c > b/drivers/gpu/drm/imx/imx-drm-core.c > index 50add2f9e250..95e2181963d9 100644 > --- a/drivers/gpu/drm/imx/imx-drm-core.c > +++ b/drivers/gpu/drm/imx/imx-drm-core.c > @@ -278,7 +278,7 @@ static int imx_drm_bind(struct device *dev) > /* Now try and bind all our sub-components */ > ret = component_bind_all(dev, drm); > if (ret) > - goto err_vblank; > + goto err_kms; > > drm_mode_config_reset(drm); > > @@ -316,8 +316,6 @@ static int imx_drm_bind(struct device *dev) > err_unbind: > #endif > component_unbind_all(drm->dev, drm); > -err_vblank: > - drm_vblank_cleanup(drm); > err_kms: > drm_mode_config_cleanup(drm); > err_unref: As I understand, the drm_dev_unref(drm) that follows this causes drm_dev_release -> drm_dev_fini -> drm_vblank_cleanup to be called, so Acked-by: Philipp Zabel regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database
On Thu, 18 May 2017, "Pandiyan, Dhinakaran"
wrote:
> On Thu, 2017-05-18 at 14:10 +0300, Jani Nikula wrote:
>> Face the fact, there are Display Port sink and branch devices out there
>> in the wild that don't follow the Display Port specifications, or they
>> have bugs, or just otherwise require special treatment. Start a common
>> quirk database the drivers can query based on the DP device
>> identification. At least for now, we leave the workarounds for the
>> drivers to implement as they see fit.
>>
>> For starters, add a branch device that can't handle full 24-bit main
>> link Mdiv and Ndiv main link attributes properly. Naturally, the
>> workaround of reducing main link attributes for all devices ended up in
>> regressions for other devices. So here we are.
>>
>> v2: Rebase on DRM DP desc read helpers
>>
>> v3: Fix the OUI memcmp blunder (Clint)
>>
>> Cc: Ville Syrjälä
>> Cc: Dhinakaran Pandiyan
>> Cc: Clint Taylor
>> Cc: Adam Jackson
>> Cc: Harry Wentland
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_dp_helper.c | 52
>> +++--
>> include/drm/drm_dp_helper.h | 32 +
>> 2 files changed, 82 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index 52e0ca9a5bb1..213fb837e1c4 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>
>
>> + * enum drm_dp_quirk - Display Port sink/branch device specific quirks
>> + *
>> + * Display Port sink and branch devices in the wild have a variety of bugs,
>> try
>> + * to collect them here. The quirks are shared, but it's up to the drivers
>> to
>> + * implement workarounds for them.
>> + */
>> +enum drm_dp_quirk {
>> +/**
>> + * @DP_DPCD_QUIRK_LIMITED_M_N:
>> + *
>> + * The device requires main link attributes Mdiv and Ndiv to be limited
>
> s/Mdiv/Mvid
> s/Ndiv/Nvid
Thanks, I took the liberty of fixing this while applying.
BR,
Jani.
>
>> + * to 16 bits.
>> + */
>> +DP_DPCD_QUIRK_LIMITED_M_N,
>> +};
--
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/dp: start a DPCD based DP sink/branch device quirk database
On Thu, 18 May 2017, Clint Taylor wrote:
> On 05/18/2017 04:10 AM, Jani Nikula wrote:
>> Face the fact, there are Display Port sink and branch devices out there
>> in the wild that don't follow the Display Port specifications, or they
>> have bugs, or just otherwise require special treatment. Start a common
>> quirk database the drivers can query based on the DP device
>> identification. At least for now, we leave the workarounds for the
>> drivers to implement as they see fit.
>>
>> For starters, add a branch device that can't handle full 24-bit main
>> link Mdiv and Ndiv main link attributes properly. Naturally, the
>> workaround of reducing main link attributes for all devices ended up in
>> regressions for other devices. So here we are.
>>
>> v2: Rebase on DRM DP desc read helpers
>>
>> v3: Fix the OUI memcmp blunder (Clint)
>
> Tested-by: Clinton Taylor
> Reviewed-by: Clinton Taylor
I pushed the series to drm-intel topic/dp-quirks branch based on
v4.12-rc3, with the goal of merging this to v4.12. Thanks for the review
and testing so far; would you mind giving that branch a go too, to
ensure I didn't screw anything up while applying?
BR,
Jani.
>
>>
>> Cc: Ville Syrjälä
>> Cc: Dhinakaran Pandiyan
>> Cc: Clint Taylor
>> Cc: Adam Jackson
>> Cc: Harry Wentland
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_dp_helper.c | 52
>> +++--
>> include/drm/drm_dp_helper.h | 32 +
>> 2 files changed, 82 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index 52e0ca9a5bb1..213fb837e1c4 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -1209,6 +1209,51 @@ int drm_dp_stop_crc(struct drm_dp_aux *aux)
>> }
>> EXPORT_SYMBOL(drm_dp_stop_crc);
>>
>> +struct dpcd_quirk {
>> +u8 oui[3];
>> +bool is_branch;
>> +u32 quirks;
>> +};
>> +
>> +#define OUI(first, second, third) { (first), (second), (third) }
>> +
>> +static const struct dpcd_quirk dpcd_quirk_list[] = {
>> +/* Analogix 7737 needs reduced M and N at HBR2 link rates */
>> +{ OUI(0x00, 0x22, 0xb9), true, BIT(DP_DPCD_QUIRK_LIMITED_M_N) },
>> +};
>> +
>> +#undef OUI
>> +
>> +/*
>> + * Get a bit mask of DPCD quirks for the sink/branch device identified by
>> + * ident. The quirk data is shared but it's up to the drivers to act on the
>> + * data.
>> + *
>> + * For now, only the OUI (first three bytes) is used, but this may be
>> extended
>> + * to device identification string and hardware/firmware revisions later.
>> + */
>> +static u32
>> +drm_dp_get_quirks(const struct drm_dp_dpcd_ident *ident, bool is_branch)
>> +{
>> +const struct dpcd_quirk *quirk;
>> +u32 quirks = 0;
>> +int i;
>> +
>> +for (i = 0; i < ARRAY_SIZE(dpcd_quirk_list); i++) {
>> +quirk = &dpcd_quirk_list[i];
>> +
>> +if (quirk->is_branch != is_branch)
>> +continue;
>> +
>> +if (memcmp(quirk->oui, ident->oui, sizeof(ident->oui)) != 0)
>> +continue;
>> +
>> +quirks |= quirk->quirks;
>> +}
>> +
>> +return quirks;
>> +}
>> +
>> /**
>>* drm_dp_read_desc - read sink/branch descriptor from DPCD
>>* @aux: DisplayPort AUX channel
>> @@ -1231,14 +1276,17 @@ int drm_dp_read_desc(struct drm_dp_aux *aux, struct
>> drm_dp_desc *desc,
>> if (ret < 0)
>> return ret;
>>
>> +desc->quirks = drm_dp_get_quirks(ident, is_branch);
>> +
>> dev_id_len = strnlen(ident->device_id, sizeof(ident->device_id));
>>
>> -DRM_DEBUG_KMS("DP %s: OUI %*phD dev-ID %*pE HW-rev %d.%d SW-rev
>> %d.%d\n",
>> +DRM_DEBUG_KMS("DP %s: OUI %*phD dev-ID %*pE HW-rev %d.%d SW-rev %d.%d
>> quirks 0x%04x\n",
>>is_branch ? "branch" : "sink",
>>(int)sizeof(ident->oui), ident->oui,
>>dev_id_len, ident->device_id,
>>ident->hw_rev >> 4, ident->hw_rev & 0xf,
>> - ident->sw_major_rev, ident->sw_minor_rev);
>> + ident->sw_major_rev, ident->sw_minor_rev,
>> + desc->quirks);
>>
>> return 0;
>> }
>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>> index aee5b96b51d7..717cb8496725 100644
>> --- a/include/drm/drm_dp_helper.h
>> +++ b/include/drm/drm_dp_helper.h
>> @@ -1090,12 +1090,44 @@ struct drm_dp_dpcd_ident {
>> /**
>>* struct drm_dp_desc - DP branch/sink device descriptor
>>* @ident: DP device identification from DPCD 0x400 (sink) or 0x500
>> (branch).
>> + * @quirks: Quirks; use drm_dp_has_quirk() to query for the quirks.
>>*/
>> struct drm_dp_desc {
>> struct drm_dp_dpcd_ident ident;
>> +u32 quirks;
>> };
>>
>> int drm_dp_read_desc(struct drm_dp_aux *aux, struct drm_dp_desc *desc,
>> bool is_branch);
>>
>> +/**
>> + * enum drm_dp_quirk - Display Po
Re: [PATCH v5 07/10] drm/bridge/synopsys: dw-hdmi: Use bridge->mode_valid() callback
On 05/25/2017 04:19 PM, Jose Abreu wrote:
> Now that we have a callback to check if bridge supports a given mode
> we can use it in Synopsys Designware HDMI bridge so that we restrict
> the number of probbed modes to the ones we can actually display.
>
> Also, there is no need to use mode_fixup() callback as mode_valid()
> will handle the mode validation.
>
> NOTE: Only compile tested
> NOTE 2: I also had to change the pdata declaration of mode_valid
> custom callback so that the passed modes are const. I also changed
> in the platforms I found. Not even compiled it though.
>
> Signed-off-by: Jose Abreu
> Acked-by: Neil Armstrong
> Cc: Carlos Palminha
> Cc: Daniel Vetter
> Cc: Archit Taneja
> Cc: Andrzej Hajda
> Cc: Laurent Pinchart
> Cc: David Airlie
> Cc: Philipp Zabel
> Cc: Carlo Caione
> Cc: Kevin Hilman
> Cc: Mark Yao
> Cc: Heiko Stuebner
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 40
> +
> drivers/gpu/drm/imx/dw_hdmi-imx.c | 4 +--
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +-
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 2 +-
> include/drm/bridge/dw_hdmi.h| 2 +-
> 5 files changed, 17 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 8737de8..038dc43 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1907,24 +1907,6 @@ static int dw_hdmi_connector_get_modes(struct
> drm_connector *connector)
> return ret;
> }
>
> -static enum drm_mode_status
> -dw_hdmi_connector_mode_valid(struct drm_connector *connector,
> - struct drm_display_mode *mode)
> -{
> - struct dw_hdmi *hdmi = container_of(connector,
> -struct dw_hdmi, connector);
> - enum drm_mode_status mode_status = MODE_OK;
> -
> - /* We don't support double-clocked modes */
> - if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> - return MODE_BAD;
> -
> - if (hdmi->plat_data->mode_valid)
> - mode_status = hdmi->plat_data->mode_valid(connector, mode);
> -
> - return mode_status;
> -}
> -
> static void dw_hdmi_connector_force(struct drm_connector *connector)
> {
> struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
> @@ -1950,7 +1932,6 @@ static void dw_hdmi_connector_force(struct
> drm_connector *connector)
>
> static const struct drm_connector_helper_funcs
> dw_hdmi_connector_helper_funcs = {
> .get_modes = dw_hdmi_connector_get_modes,
> - .mode_valid = dw_hdmi_connector_mode_valid,
> .best_encoder = drm_atomic_helper_best_encoder,
> };
>
> @@ -1973,18 +1954,21 @@ static int dw_hdmi_bridge_attach(struct drm_bridge
> *bridge)
> return 0;
> }
>
> -static bool dw_hdmi_bridge_mode_fixup(struct drm_bridge *bridge,
> - const struct drm_display_mode *orig_mode,
> - struct drm_display_mode *mode)
> +static enum drm_mode_status dw_hdmi_bridge_mode_valid(struct drm_bridge
> *bridge,
> + const struct
> drm_display_mode *mode)
> {
> struct dw_hdmi *hdmi = bridge->driver_private;
> struct drm_connector *connector = &hdmi->connector;
> - enum drm_mode_status status;
> + enum drm_mode_status mode_status = MODE_OK;
>
> - status = dw_hdmi_connector_mode_valid(connector, mode);
> - if (status != MODE_OK)
> - return false;
> - return true;
> + /* We don't support double-clocked modes */
> + if (mode->flags & DRM_MODE_FLAG_DBLCLK)
> + return MODE_BAD;
> +
> + if (hdmi->plat_data->mode_valid)
> + mode_status = hdmi->plat_data->mode_valid(connector, mode);
> +
> + return mode_status;
> }
>
> static void dw_hdmi_bridge_mode_set(struct drm_bridge *bridge,
> @@ -2028,7 +2012,7 @@ static void dw_hdmi_bridge_enable(struct drm_bridge
> *bridge)
> .enable = dw_hdmi_bridge_enable,
> .disable = dw_hdmi_bridge_disable,
> .mode_set = dw_hdmi_bridge_mode_set,
> - .mode_fixup = dw_hdmi_bridge_mode_fixup,
> + .mode_valid = dw_hdmi_bridge_mode_valid,
> };
>
> static irqreturn_t dw_hdmi_i2c_irq(struct dw_hdmi *hdmi)
> diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
> b/drivers/gpu/drm/imx/dw_hdmi-imx.c
> index f039641..5f561c8 100644
> --- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
> +++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
> @@ -148,7 +148,7 @@ static int dw_hdmi_imx_atomic_check(struct drm_encoder
> *encoder,
> };
>
> static enum drm_mode_status imx6q_hdmi_mode_valid(struct drm_connector *con,
> - struct drm_display_mode *mode)
> + const struct drm_display_mode
> *mode)
> {
> if (mode->clock < 13500)
> return MODE_CLOCK_LOW;
[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=99851 --- Comment #43 from erhar...@mailbox.org --- What would be the best way to do this? Start a 2nd bisect in search for the commit which causes/fixes the boot failure and exclude/include it in my 1st bisect? Sorry, I don't have that much experience in bisecting the kernel. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate
https://bugs.freedesktop.org/show_bug.cgi?id=93826 --- Comment #51 from Eike --- I just received my replacement MG279Q, here is what changed and what didn't. The monitor OSD still reports 139Hz instead of 144, BUT all artifacts (vertical lines) are gone. So to everyone who has these issues ( comment #50 ) with an Asus MG279Q, I recommend RMAing the monitor with a description of your issues. I don't know if the fixes are incorporated into the standard firmware already or if Asus only applies them if you ask for it. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101213] Kernel 4.11: amdgpu regression causes artifacts with OLAND amd gpu gcn 1.0
https://bugs.freedesktop.org/show_bug.cgi?id=101213 --- Comment #4 from siyia --- ooops yeah so should i close this issue? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101213] Kernel 4.11: amdgpu regression causes artifacts with OLAND amd gpu gcn 1.0
https://bugs.freedesktop.org/show_bug.cgi?id=101213 --- Comment #3 from Michel Dänzer --- It's a different bugzilla. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101213] Kernel 4.11: amdgpu regression causes artifacts with OLAND amd gpu gcn 1.0
https://bugs.freedesktop.org/show_bug.cgi?id=101213 siyia changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from siyia --- Seems to be, trying to mark as duplicate but says bug 194761 doesnt exist lol. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/11] drm: sun4i: Add support for the HDMI controller
On Sat, May 27, 2017 at 06:09:25PM +0200, Maxime Ripard wrote: > Hi, > > Here is an attempt at getting the HDMI controller running. > > This HDMI controller is found on a number of old Allwinner SoCs (A10, A10s, > A20, A31). > > This driver only supports for now the A10s because it was an easy target, > being very close to the A13 that is already supported by our DRM driver. > > There's nothing out of the extraordinary there, except maybe the clock > setup. All the internal clocks (TMDS, DDC) have been modeled using the > common clock framework, the TMDS clock being the parent of the DDC one. > > While this might sound overkill, other SoC have a different, external > source for the DDC clock, which will be easier to support through the clock > framework. > > The IP also supports audio (through an already supported i2s controller, > and some missing configuration in the HDMI controller) and CEC. Both will > come eventually. Applied all the patches. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 32/37] drm/sun4i: Drop drm_vblank_cleanup
On Wed, May 24, 2017 at 04:52:07PM +0200, Daniel Vetter wrote: > Again seems just cargo-culted ... It's not ordered against any > irq/vblank/modeset shutdown. > > Cc: Maxime Ripard > Signed-off-by: Daniel Vetter Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Maintaining small drm drivers
On Mon, May 29, 2017 at 8:53 AM, Daniel Vetter wrote: >>> Find another smaller driver in need of some cleanup (we can add more >>> to drm-misc), cross review. Yes it's a bit of work (see above), but at >>> least from the drm subsystem pov the end result will be worth it, >>> since more code sharing and more collaboration gives us a much >>> stronger community. >> >> I'm currently at a conference so I figured I'd ask around. So far, >> people are reluctant to get their hands dirty in a driver they've >> never looked at before and don't have hardware to test. From a >> community perspective, would you agree to require review by AMD for >> all Intel patches and vice versa (a slight exaggeration, I know)? I'd >> say that would cripple development of both drivers. There is as you >> say the a-b tag but I honestly doubt it's useful. > > Small driver = only 1 regular contributor. AMD and intel are anything > but small. And yes if I'd maintain a small driver I'd welcome to have > a regular exchange with other maintainers to make sure my driver is up > to date with drm best practices. Again gma500 is a bit special since > it's not moving anymore. To make it clearer what I meant to say: It's of course better if your reviewer has domain knowledge about your code, but if there's only 1 regular contributor a bit of review is imo still good. As soon as there's a few regular contributors then a review sub-group in drm-misc forms (e.g. like what's happened with bridge drivers, and we documented that in MAINTAINERS). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] amdgpu/cs: split out fence dependency checking
From: Dave Airlie
This just splits out the fence depenency checking into it's
own function to make it easier to add semaphore dependencies.
Reviewed-by: Christian König
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 85 +++---
1 file changed, 47 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 4e6b950..30225d7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -995,56 +995,65 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device *adev,
return 0;
}
-static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
- struct amdgpu_cs_parser *p)
+static int amdgpu_cs_process_fence_dep(struct amdgpu_cs_parser *p,
+ struct amdgpu_cs_chunk *chunk)
{
struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
- int i, j, r;
-
- for (i = 0; i < p->nchunks; ++i) {
- struct drm_amdgpu_cs_chunk_dep *deps;
- struct amdgpu_cs_chunk *chunk;
- unsigned num_deps;
+ unsigned num_deps;
+ int i, r;
+ struct drm_amdgpu_cs_chunk_dep *deps;
- chunk = &p->chunks[i];
+ deps = (struct drm_amdgpu_cs_chunk_dep *)chunk->kdata;
+ num_deps = chunk->length_dw * 4 /
+ sizeof(struct drm_amdgpu_cs_chunk_dep);
- if (chunk->chunk_id != AMDGPU_CHUNK_ID_DEPENDENCIES)
- continue;
+ for (i = 0; i < num_deps; ++i) {
+ struct amdgpu_ring *ring;
+ struct amdgpu_ctx *ctx;
+ struct dma_fence *fence;
- deps = (struct drm_amdgpu_cs_chunk_dep *)chunk->kdata;
- num_deps = chunk->length_dw * 4 /
- sizeof(struct drm_amdgpu_cs_chunk_dep);
+ r = amdgpu_cs_get_ring(p->adev, deps[i].ip_type,
+ deps[i].ip_instance,
+ deps[i].ring, &ring);
+ if (r)
+ return r;
- for (j = 0; j < num_deps; ++j) {
- struct amdgpu_ring *ring;
- struct amdgpu_ctx *ctx;
- struct dma_fence *fence;
+ ctx = amdgpu_ctx_get(fpriv, deps[i].ctx_id);
+ if (ctx == NULL)
+ return -EINVAL;
- r = amdgpu_cs_get_ring(adev, deps[j].ip_type,
- deps[j].ip_instance,
- deps[j].ring, &ring);
+ fence = amdgpu_ctx_get_fence(ctx, ring,
+deps[i].handle);
+ if (IS_ERR(fence)) {
+ r = PTR_ERR(fence);
+ amdgpu_ctx_put(ctx);
+ return r;
+ } else if (fence) {
+ r = amdgpu_sync_fence(p->adev, &p->job->sync,
+ fence);
+ dma_fence_put(fence);
+ amdgpu_ctx_put(ctx);
if (r)
return r;
+ }
+ }
+ return 0;
+}
- ctx = amdgpu_ctx_get(fpriv, deps[j].ctx_id);
- if (ctx == NULL)
- return -EINVAL;
+static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
+ struct amdgpu_cs_parser *p)
+{
+ int i, r;
- fence = amdgpu_ctx_get_fence(ctx, ring,
-deps[j].handle);
- if (IS_ERR(fence)) {
- r = PTR_ERR(fence);
- amdgpu_ctx_put(ctx);
- return r;
+ for (i = 0; i < p->nchunks; ++i) {
+ struct amdgpu_cs_chunk *chunk;
- } else if (fence) {
- r = amdgpu_sync_fence(adev, &p->job->sync,
- fence);
- dma_fence_put(fence);
- amdgpu_ctx_put(ctx);
- if (r)
- return r;
- }
+ chunk = &p->chunks[i];
+
+ if (chunk->chunk_id == AMDGPU_CHUNK_ID_DEPENDENCIES) {
+ r = amdgpu_cs_process_fence_dep(p, chunk);
+ if (r)
+ return r;
}
}
--
2.9.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] amdgpu: use drm sync objects for shared semaphores (v5)
From: Dave Airlie
This creates a new command submission chunk for amdgpu
to add in and out sync objects around the submission.
Sync objects are managed via the drm syncobj ioctls.
The command submission interface is enhanced with two new
chunks, one for syncobj pre submission dependencies,
and one for post submission sync obj signalling,
and just takes a list of handles for each.
This is based on work originally done by David Zhou at AMD,
with input from Christian Konig on what things should look like.
In theory VkFences could be backed with sync objects and
just get passed into the cs as syncobj handles as well.
NOTE: this interface addition needs a version bump to expose
it to userspace.
TODO: update to dep_sync when rebasing onto amdgpu master.
(with this - r-b from Christian)
v1.1: keep file reference on import.
v2: move to using syncobjs
v2.1: change some APIs to just use p pointer.
v3: make more robust against CS failures, we now add the
wait sems but only remove them once the CS job has been
submitted.
v4: rewrite names of API and base on new syncobj code.
v5: move post deps earlier, rename some apis
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 87 -
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
include/uapi/drm/amdgpu_drm.h | 6 +++
3 files changed, 93 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 30225d7..3cbd547 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "amdgpu.h"
#include "amdgpu_trace.h"
@@ -226,6 +227,8 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void
*data)
break;
case AMDGPU_CHUNK_ID_DEPENDENCIES:
+ case AMDGPU_CHUNK_ID_SYNCOBJ_IN:
+ case AMDGPU_CHUNK_ID_SYNCOBJ_OUT:
break;
default:
@@ -1040,6 +1043,40 @@ static int amdgpu_cs_process_fence_dep(struct
amdgpu_cs_parser *p,
return 0;
}
+static int amdgpu_syncobj_lookup_and_add_to_sync(struct amdgpu_cs_parser *p,
+uint32_t handle)
+{
+ int r;
+ struct dma_fence *fence;
+ r = drm_syncobj_fence_get(p->filp, handle, &fence);
+ if (r)
+ return r;
+
+ r = amdgpu_sync_fence(p->adev, &p->job->sync, fence);
+ dma_fence_put(fence);
+
+ return r;
+}
+
+static int amdgpu_cs_process_syncobj_in_dep(struct amdgpu_cs_parser *p,
+ struct amdgpu_cs_chunk *chunk)
+{
+ unsigned num_deps;
+ int i, r;
+ struct drm_amdgpu_cs_chunk_sem *deps;
+
+ deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+ num_deps = chunk->length_dw * 4 /
+ sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+ for (i = 0; i < num_deps; ++i) {
+ r = amdgpu_syncobj_lookup_and_add_to_sync(p, deps[i].handle);
+ if (r)
+ return r;
+ }
+ return 0;
+}
+
static int amdgpu_cs_dependencies(struct amdgpu_device *adev,
struct amdgpu_cs_parser *p)
{
@@ -1054,12 +1091,54 @@ static int amdgpu_cs_dependencies(struct amdgpu_device
*adev,
r = amdgpu_cs_process_fence_dep(p, chunk);
if (r)
return r;
+ } else if (chunk->chunk_id == AMDGPU_CHUNK_ID_SYNCOBJ_IN) {
+ r = amdgpu_cs_process_syncobj_in_dep(p, chunk);
+ if (r)
+ return r;
}
}
return 0;
}
+static int amdgpu_cs_process_syncobj_out_dep(struct amdgpu_cs_parser *p,
+struct amdgpu_cs_chunk *chunk)
+{
+ unsigned num_deps;
+ int i, r;
+ struct drm_amdgpu_cs_chunk_sem *deps;
+
+ deps = (struct drm_amdgpu_cs_chunk_sem *)chunk->kdata;
+ num_deps = chunk->length_dw * 4 /
+ sizeof(struct drm_amdgpu_cs_chunk_sem);
+
+ for (i = 0; i < num_deps; ++i) {
+ r = drm_syncobj_replace_fence(p->filp, deps[i].handle,
+ p->fence);
+ if (r)
+ return r;
+ }
+ return 0;
+}
+
+static int amdgpu_cs_post_dependencies(struct amdgpu_cs_parser *p)
+{
+ int i, r;
+
+ for (i = 0; i < p->nchunks; ++i) {
+ struct amdgpu_cs_chunk *chunk;
+
+ chunk = &p->chunks[i];
+
+ if (chunk->chunk_id == AMDGPU_CHUNK_ID_SYNCOBJ_OUT) {
+ r = amdgpu_cs_process_syncobj_out_dep(p, chunk);
+ if (r)
+ return r;
+ }
+ }
+ return 0;
+}
+
static int am
[PATCH 2/5] drm/syncobj: add sync obj wait interface. (v4)
From: Dave Airlie
This interface will allow sync object to be used to back
Vulkan fences. This API is pretty much the vulkan fence waiting
API, and I've ported the code from amdgpu.
v2: accept relative timeout, pass remaining time back
to userspace.
v3: return to absolute timeouts.
v4: absolute zero = poll,
rewrite any/all code to have same operation for arrays
return -EINVAL for 0 fences.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 129 +
include/uapi/drm/drm.h | 14 +
4 files changed, 147 insertions(+)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 3fdef2c..53e3f6b 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -156,3 +156,5 @@ int drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev,
void *data,
struct drm_file *file_private);
int drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_private);
+int drm_syncobj_wait_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_private);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index f1e5681..385ce74 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -657,6 +657,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE,
drm_syncobj_fd_to_handle_ioctl,
DRM_UNLOCKED|DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_WAIT, drm_syncobj_wait_ioctl,
+ DRM_UNLOCKED|DRM_RENDER_ALLOW),
};
#define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index b611480..5177b36 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -1,5 +1,7 @@
/*
* Copyright 2017 Red Hat
+ * Parts ported from amdgpu (fence wait code).
+ * Copyright 2016 Advanced Micro Devices, Inc.
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -31,6 +33,9 @@
* that contain an optional fence. The fence can be updated with a new
* fence, or be NULL.
*
+ * syncobj's can be waited upon, where it will wait for the underlying
+ * fence.
+ *
* syncobj's can be export to fd's and back, these fd's are opaque and
* have no other use case, except passing the syncobj between processes.
*
@@ -375,3 +380,127 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev,
void *data,
return drm_syncobj_fd_to_handle(file_private, args->fd,
&args->handle);
}
+
+
+/**
+ * drm_timeout_abs_to_jiffies - calculate jiffies timeout from absolute value
+ *
+ * @timeout_ns: timeout in ns, 0 for poll
+ *
+ * Calculate the timeout in jiffies from an absolute timeout in ns.
+ */
+static unsigned long drm_timeout_abs_to_jiffies(uint64_t timeout_ns)
+{
+ unsigned long timeout_jiffies;
+ ktime_t timeout;
+
+ /* make 0 timeout means poll - absolute 0 doesn't seem valid */
+ if (timeout_ns == 0)
+ return 0;
+
+ /* clamp timeout if it's to large */
+ if (((int64_t)timeout_ns) < 0)
+ return MAX_SCHEDULE_TIMEOUT;
+
+ timeout = ktime_sub(ns_to_ktime(timeout_ns), ktime_get());
+ if (ktime_to_ns(timeout) < 0)
+ return 0;
+
+ timeout_jiffies = nsecs_to_jiffies(ktime_to_ns(timeout));
+ /* clamp timeout to avoid infinite timeout */
+ if (timeout_jiffies >= MAX_SCHEDULE_TIMEOUT)
+ return MAX_SCHEDULE_TIMEOUT - 1;
+
+ return timeout_jiffies + 1;
+}
+
+static int drm_syncobj_wait_fences(struct drm_device *dev,
+ struct drm_file *file_private,
+ struct drm_syncobj_wait *wait,
+ struct dma_fence **fences)
+{
+ unsigned long timeout = drm_timeout_abs_to_jiffies(wait->timeout_ns);
+ int ret = 0;
+ uint32_t first = ~0;
+
+ if (wait->flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL) {
+ int i;
+ for (i = 0; i < wait->count_handles; i++) {
+ ret = dma_fence_wait_timeout(fences[i], true, timeout);
+
+ if (ret < 0)
+ return ret;
+ if (ret == 0)
+ break;
+ timeout = ret;
+ }
+ first = 0;
+ } else
+ ret = dma_fence_wait_any_timeout(fences,
+wait->count_handles,
+
[PATCH 1/5] drm: introduce sync objects (v3)
From: Dave Airlie
Sync objects are new toplevel drm object, that contain a
pointer to a fence. This fence can be updated via command
submission ioctls via drivers.
There is also a generic wait obj API modelled on the vulkan
wait API (with code modelled on some amdgpu code).
These objects can be converted to an opaque fd that can be
passes between processes.
v2: rename reference/unreference to put/get (Chris)
fix leaked reference (David Zhou)
drop mutex in favour of cmpxchg (Chris)
v3: cleanups from danvet, rebase on drm_fops rename
check fd_flags is 0 in ioctls.
Reviewed-by: Sean Paul
Signed-off-by: Dave Airlie
---
Documentation/gpu/drm-internals.rst | 3 +
Documentation/gpu/drm-mm.rst| 12 ++
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_file.c | 8 +
drivers/gpu/drm/drm_internal.h | 13 ++
drivers/gpu/drm/drm_ioctl.c | 12 ++
drivers/gpu/drm/drm_syncobj.c | 377
include/drm/drmP.h | 1 -
include/drm/drm_drv.h | 1 +
include/drm/drm_file.h | 5 +
include/drm/drm_syncobj.h | 87 +
include/uapi/drm/drm.h | 24 +++
12 files changed, 543 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/drm_syncobj.c
create mode 100644 include/drm/drm_syncobj.h
diff --git a/Documentation/gpu/drm-internals.rst
b/Documentation/gpu/drm-internals.rst
index babfb61..2b23d78 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -98,6 +98,9 @@ DRIVER_ATOMIC
implement appropriate obj->atomic_get_property() vfuncs for any
modeset objects with driver specific properties.
+DRIVER_SYNCOBJ
+Driver support drm sync objects.
+
Major, Minor and Patchlevel
~~~
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index 96b9c34..9412798 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -484,3 +484,15 @@ DRM Cache Handling
.. kernel-doc:: drivers/gpu/drm/drm_cache.c
:export:
+
+DRM Sync Objects
+===
+
+.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
+ :doc: Overview
+
+.. kernel-doc:: include/drm/drm_syncobj.h
+ :export:
+
+.. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
+ :export:
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 59f0f9b..6f42188 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -16,7 +16,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
- drm_dumb_buffers.o drm_mode_config.o
+ drm_dumb_buffers.o drm_mode_config.o drm_syncobj.o
drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 3783b65..a20d6a9 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -229,6 +229,9 @@ static int drm_open_helper(struct file *filp, struct
drm_minor *minor)
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_open(dev, priv);
+ if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ drm_syncobj_open(priv);
+
if (drm_core_check_feature(dev, DRIVER_PRIME))
drm_prime_init_file_private(&priv->prime);
@@ -276,6 +279,8 @@ static int drm_open_helper(struct file *filp, struct
drm_minor *minor)
out_prime_destroy:
if (drm_core_check_feature(dev, DRIVER_PRIME))
drm_prime_destroy_file_private(&priv->prime);
+ if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ drm_syncobj_release(priv);
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_release(dev, priv);
put_pid(priv->pid);
@@ -398,6 +403,9 @@ int drm_release(struct inode *inode, struct file *filp)
drm_property_destroy_user_blobs(dev, file_priv);
}
+ if (drm_core_check_feature(dev, DRIVER_SYNCOBJ))
+ drm_syncobj_release(file_priv);
+
if (drm_core_check_feature(dev, DRIVER_GEM))
drm_gem_release(dev, file_priv);
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 3d8e8f8..3fdef2c 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -142,4 +142,17 @@ static inline int drm_debugfs_crtc_crc_add(struct drm_crtc
*crtc)
{
return 0;
}
+
#endif
+
+/* drm_syncobj.c */
+void drm_syncobj_open(struct drm_file *file_private);
+void drm_syncobj_release(struct drm_file *file_private);
+int drm_syncobj_create_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_private);
+int drm_syncobj_destroy_ioctl(struct drm_device *dev, void *data
[PATCH 3/5] drm/syncobj: add sync_file interaction. (v1.1)
From: Dave Airlie
This interface allows importing the fence from a sync_file into
an existing drm sync object, or exporting the fence attached to
an existing drm sync object into a new sync file object.
This should only be used to interact with sync files where necessary.
v1.1: fence put fixes (Chris), drop fence from ioctl names (Chris)
Reviewed-by: Sean Paul
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_syncobj.c | 67 +--
include/uapi/drm/drm.h| 2 ++
2 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 5177b36..4694021 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -50,6 +50,7 @@
#include
#include
#include
+#include
#include "drm_internal.h"
#include
@@ -276,6 +277,51 @@ static int drm_syncobj_fd_to_handle(struct drm_file
*file_private,
return 0;
}
+int drm_syncobj_import_sync_file_fence(struct drm_file *file_private,
+ int fd, int handle)
+{
+ struct dma_fence *fence = sync_file_get_fence(fd);
+ int ret;
+ if (!fence)
+ return -EINVAL;
+
+ ret = drm_syncobj_replace_fence(file_private, handle, fence);
+ dma_fence_put(fence);
+ return ret;
+}
+
+int drm_syncobj_export_sync_file(struct drm_file *file_private,
+int handle, int *p_fd)
+{
+ int ret;
+ struct dma_fence *fence;
+ struct sync_file *sync_file;
+ int fd = get_unused_fd_flags(O_CLOEXEC);
+
+ if (fd < 0)
+ return fd;
+
+ ret = drm_syncobj_fence_get(file_private, handle, &fence);
+ if (ret)
+ goto err_put_fd;
+
+ sync_file = sync_file_create(fence);
+
+ dma_fence_put(fence);
+
+ if (!sync_file) {
+ ret = -EINVAL;
+ goto err_put_fd;
+ }
+
+ fd_install(fd, sync_file->file);
+
+ *p_fd = fd;
+ return 0;
+err_put_fd:
+ put_unused_fd(fd);
+ return ret;
+}
/**
* drm_syncobj_open - initalizes syncobj file-private structures at devnode
open time
* @dev: drm_device which is being opened by userspace
@@ -358,9 +404,17 @@ drm_syncobj_handle_to_fd_ioctl(struct drm_device *dev,
void *data,
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
return -ENODEV;
- if (args->pad || args->flags)
+ if (args->pad)
+ return -EINVAL;
+
+ if (args->flags != 0 &&
+ args->flags != DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_SYNC_FILE)
return -EINVAL;
+ if (args->flags & DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_SYNC_FILE)
+ return drm_syncobj_export_sync_file(file_private, args->handle,
+ &args->fd);
+
return drm_syncobj_handle_to_fd(file_private, args->handle,
&args->fd);
}
@@ -374,9 +428,18 @@ drm_syncobj_fd_to_handle_ioctl(struct drm_device *dev,
void *data,
if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ))
return -ENODEV;
- if (args->pad || args->flags)
+ if (args->pad)
+ return -EINVAL;
+
+ if (args->flags != 0 &&
+ args->flags != DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE)
return -EINVAL;
+ if (args->flags & DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE)
+ return drm_syncobj_import_sync_file_fence(file_private,
+ args->fd,
+ args->handle);
+
return drm_syncobj_fd_to_handle(file_private, args->fd,
&args->handle);
}
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index d6e2f62..49c4e69 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -708,6 +708,8 @@ struct drm_syncobj_destroy {
__u32 pad;
};
+#define DRM_SYNCOBJ_FD_TO_HANDLE_FLAGS_IMPORT_SYNC_FILE (1 << 0)
+#define DRM_SYNCOBJ_HANDLE_TO_FD_FLAGS_EXPORT_SYNC_FILE (1 << 0)
struct drm_syncobj_handle {
__u32 handle;
__u32 flags;
--
2.9.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-syncobj - mostly wait changes
The wait patch seemed to get the most discussion last time, so I've overhauled it. The others are mostly unchanged. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99851] [drm:.r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=99851 --- Comment #42 from Michel Dänzer --- That's quite a lot of candidates still. To narrow it down further, you can find out which commit fixed the boot failure, and then manually apply that for testing the skipped commits. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
