Re: [PATCH] drm: change connector disconnected debug message to an error
On Thu, 02 Feb 2017, Shuah Khan wrote:
> Change drm_helper_probe_single_connector_modes() to print an error to
> report connector disconnected status instead of a debug message.
>
> When this condition occurs, application doesn't know the real error and
> reports it as driver lacking support for mode setting. Change it to an
> error to make it easier to debug.
Please explain what makes this condition an error. Connectors get
connected and disconnected, business as usual, why should this be an
error?
BR,
Jani.
>
> Signed-off-by: Shuah Khan
> ---
> drivers/gpu/drm/drm_probe_helper.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index ac953f0..6472b7f 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -282,8 +282,8 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
> dev->mode_config.poll_running = drm_kms_helper_poll;
>
> if (connector->status == connector_status_disconnected) {
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
> - connector->base.id, connector->name);
> + DRM_ERROR("[CONNECTOR:%d:%s] disconnected\n",
> + connector->base.id, connector->name);
> drm_mode_connector_update_edid_property(connector, NULL);
> verbose_prune = false;
> goto prune;
--
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: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote: > Jani Nikula writes: > > > On Tue, 31 Jan 2017, Eric Anholt wrote: > >> Martin Peres writes: > >> > >>> Despite all the careful planing of the kernel, a link may become > >>> insufficient to handle the currently-set mode. At this point, the > >>> kernel should mark this particular configuration as being broken > >>> and potentially prune the mode before setting the offending connector's > >>> link-status to BAD and send the userspace a hotplug event. This may > >>> happen right after a modeset or later on. > >>> > >>> When available, we should use the link-status information to reset > >>> the wanted mode. > >>> > >>> Signed-off-by: Martin Peres > >> > >> If I understand this right, there are two failure modes being handled: > >> > >> 1) A mode that won't actually work because the link isn't good enough. > >> > >> 2) A mode that should work, but link parameters were too optimistic and > >> if we just ask the kernel to set the mode again it'll use more > >> conservative parameters that work. > >> > >> This patch seems good for 2). For 1), the drmmode_set_mode_major is > >> going to set our old mode back. Won't the modeset then fail to link > >> train again, and bring us back into this loop? The only escape that I > >> see would be some other userspace responding to the advertised mode list > >> changing, and then asking X to modeset to something new. > >> > >> To avoid that failure busy loop, should we re-fetching modes at this > >> point, and only re-setting if our mode still exists? > > > > Disclaimer: I don't know anything about the internals of the modesetting > > driver. > > > > Perhaps we can identify the two cases now, but I'd put this more > > generally: if the link status has gone bad, it's an indicator to > > userspace that the circumstances may have changed, and userspace should > > query the kernel for the list of available modes again. It should no > > longer trust information obtained prior to getting the bad link status, > > including the current mode. > > > > But specifically, I think you're right, and AFAICT asking for the list > > of modes again is the only way for the userspace to distinguish between > > the two cases. I don't think there's a shortcut for deciding the current > > mode is still valid. > > To avoid the busy-loop problem, I think I'd like this patch to re-query > the kernel to ask about the current mode list, and only try to re-set > the mode if our mode is still there. Yeah, I guess that sounds like a reasonable heuristics. More integrated compositors (aka the wayland ones) might be able to make more useful decisions, but for -modesetting that's probably the best we can do. > If the mode isn't there, then it's up to the DE to take action in > response to the notification of new modes. If you don't have a DE to > take appropriate action, you're kind of out of luck. > > As far as the ABI goes, this seems fine to me. The only concern I had > about ABI was having to walk all the connectors on every uevent to see > if any had gone bad -- couldn't we have a flag of some sort about what > the uevent indicates? But uevents should be super rare, so I'd say the > kernel could go ahead with the current plan. We've discussed finer-grained uevent singalling a few times, and I'd like that to be an orthogonal abi extension. Right now we just don't have the required tracking even within the kernel to know which connector changed (and the tracking we do have missed a few things, too). My idea is to push the tracking into the leaves of the callchains with a function that increases some per-connector epoch counter. Then we'd just have to expose that somehow cheaply to userspace (could probably just send it along in the uevent). Plus expose it as a read-only property so that userspace can re-synchronize. But again, that should be an orthogonal thing imo. -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
[Bug 99637] VLC video has corrupted colors when using VDPAU output on Radeon SI
https://bugs.freedesktop.org/show_bug.cgi?id=99637 Matt Whitlock changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Matt Whitlock --- (In reply to Nayan Deshmukh from comment #1) > Can you test with this patch? Applying the patch to 17.0.0 RC2 solves the problem. Thanks. -- 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 99637] VLC video has corrupted colors when using VDPAU output on Radeon SI
https://bugs.freedesktop.org/show_bug.cgi?id=99637 Michel Dänzer changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #3 from Michel Dänzer --- This report should remain open until the fix lands on the 17.0 branch. -- 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 99549] pp: Failed to translate a shader
https://bugs.freedesktop.org/show_bug.cgi?id=99549 --- Comment #1 from Marek Olšák --- Try to disable post processing in drirc. -- 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 2/2] drm: Rely on mode_config data for fb_helper initialization
On Wed, Feb 01, 2017 at 12:50:48PM -0800, Eric Anholt wrote: > Gabriel Krisman Bertazi writes: > > > Instead of receiving the num_crts as a parameter, we can read it > > directly from the mode_config structure. I audited the drivers that > > invoke this helper and I believe all of them (but one, see below) > > initialize the mode_config struct accordingly, prior to calling the > > fb_helper. > > This is a nice cleanup! It always felt silly to be passing in my > mode_config's members to the fbdev setup. Could we do the same for > num_connector? > > I've verified that all the drivers either init their CRTCs or have > already looked at mode_config.num_crtcs before the fbdev init call, so > this is: > > Reviewed-by: Eric Anholt Yeah, nice patch but doesn't apply now that Dave has pulled in a bunch of driver pull requests :( Can you pls regen the cocci, but pls keep Eric's r-b so I don't have to go hunting for it. Thanks, 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
[Bug 99637] VLC video has corrupted colors when using VDPAU output on Radeon SI
https://bugs.freedesktop.org/show_bug.cgi?id=99637 --- Comment #4 from Nayan Deshmukh --- (In reply to Michel Dänzer from comment #3) > This report should remain open until the fix lands on the 17.0 branch. I will nominate the patch for the 17.0 branch. -- 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 99136] Blood Effects Total War: Warhammer
https://bugs.freedesktop.org/show_bug.cgi?id=99136 --- Comment #10 from Samuel Pitoiset --- Which version of Total War: Warhammer? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amdgpu: shut up #warning for compile testing
Am 02.02.2017 um 07:09 schrieb Michel Dänzer: [SNIP] OTOH the people running the kernel aren't always the same people building it, so the downside is that this would potentially delay getting X86_PAT enabled. And exactly for this reason I would rather like to keep the warning. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6] drm: Provide a driver hook for drm_dev_release()
Some state is coupled into the device lifetime outside of the
load/unload timeframe and requires teardown during final unreference
from drm_dev_release(). For example, dmabufs hold both a device and
module reference and may live longer than expected (i.e. the current
pattern of the driver tearing down its state and then releasing a
reference to the drm device) and yet touch driver private state when
destroyed.
v2: Export drm_dev_fini() and move the responsibility for finalizing the
drm_device and freeing it to the release callback. (If no callback is
provided, the core will call drm_dev_fini() and kfree(dev) as before.)
v3: Remember to add drm_dev_fini() to drm_drv.h
v4: Tidy language for kerneldoc
v5: Cross reference from drm_dev_init() to note that driver->release()
allows for arbitrary embedding.
v6: Refer to driver data rather than driver state, as state is now
becoming associated with the struct drm_atomic_state and friends.
Signed-off-by: Chris Wilson
Cc: Laurent Pinchart
Cc: Daniel Vetter
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/drm_drv.c | 65 ---
include/drm/drm_drv.h | 13 ++
2 files changed, 58 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index a8ce3179c07c..e122e4d022f8 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -465,7 +465,10 @@ static void drm_fs_inode_free(struct inode *inode)
* that do embed &struct drm_device it must be placed first in the overall
* structure, and the overall structure must be allocated using kmalloc(): The
* drm core's release function unconditionally calls kfree() on the @dev
pointer
- * when the final reference is released.
+ * when the final reference is released. To override this behaviour, and so
+ * allow embedding of the drm_device inside the driver's device struct at an
+ * arbitrary offset, you must supply a driver->release() callback and control
+ * the finalization explicitly.
*
* RETURNS:
* 0 on success, or error code on failure.
@@ -553,6 +556,41 @@ int drm_dev_init(struct drm_device *dev,
EXPORT_SYMBOL(drm_dev_init);
/**
+ * drm_dev_fini - Finalize a dead DRM device
+ * @dev: DRM device
+ *
+ * Finalize a dead DRM device. This is the converse to drm_dev_init() and
+ * frees up all data allocated by it. All driver private data should be
+ * finalized first. Note that this function does not free the @dev, that is
+ * left to the caller.
+ *
+ * The ref-count of @dev must be zero, and drm_dev_fini() should only be called
+ * from a drm_driver->release() callback.
+ */
+void drm_dev_fini(struct drm_device *dev)
+{
+ drm_vblank_cleanup(dev);
+
+ if (drm_core_check_feature(dev, DRIVER_GEM))
+ drm_gem_destroy(dev);
+
+ drm_legacy_ctxbitmap_cleanup(dev);
+ drm_ht_remove(&dev->map_hash);
+ drm_fs_inode_free(dev->anon_inode);
+
+ drm_minor_free(dev, DRM_MINOR_PRIMARY);
+ drm_minor_free(dev, DRM_MINOR_RENDER);
+ drm_minor_free(dev, DRM_MINOR_CONTROL);
+
+ mutex_destroy(&dev->master_mutex);
+ mutex_destroy(&dev->ctxlist_mutex);
+ mutex_destroy(&dev->filelist_mutex);
+ mutex_destroy(&dev->struct_mutex);
+ kfree(dev->unique);
+}
+EXPORT_SYMBOL(drm_dev_fini);
+
+/**
* drm_dev_alloc - Allocate new DRM device
* @driver: DRM driver to allocate device for
* @parent: Parent device object
@@ -598,25 +636,12 @@ static void drm_dev_release(struct kref *ref)
{
struct drm_device *dev = container_of(ref, struct drm_device, ref);
- drm_vblank_cleanup(dev);
-
- if (drm_core_check_feature(dev, DRIVER_GEM))
- drm_gem_destroy(dev);
-
- drm_legacy_ctxbitmap_cleanup(dev);
- drm_ht_remove(&dev->map_hash);
- drm_fs_inode_free(dev->anon_inode);
-
- drm_minor_free(dev, DRM_MINOR_PRIMARY);
- drm_minor_free(dev, DRM_MINOR_RENDER);
- drm_minor_free(dev, DRM_MINOR_CONTROL);
-
- mutex_destroy(&dev->master_mutex);
- mutex_destroy(&dev->ctxlist_mutex);
- mutex_destroy(&dev->filelist_mutex);
- mutex_destroy(&dev->struct_mutex);
- kfree(dev->unique);
- kfree(dev);
+ if (dev->driver->release) {
+ dev->driver->release(dev);
+ } else {
+ drm_dev_fini(dev);
+ kfree(dev);
+ }
}
/**
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 732e85652d1e..5699f42195fe 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -102,6 +102,17 @@ struct drm_driver {
*
*/
void (*unload) (struct drm_device *);
+
+ /**
+* @release:
+*
+* Optional callback for destroying device data after the final
+* reference is released, i.e. the device is being destroyed. Drivers
+* using this callback are responsible for calling drm_dev_fini()
+* to finalize the device and then freeing the struct them
[Bug 99444] [radeonsi] The Witcher 3 (GOG/1.31) [Wine] starting menu is distorted
https://bugs.freedesktop.org/show_bug.cgi?id=99444 --- Comment #15 from Samuel Pitoiset --- (In reply to Józef Kucia from comment #13) > (In reply to Samuel Pitoiset from comment #12) > > Well yeah, it's definitely unrelated to Mesa/RadeonSI. The app should check > > if NV_register_combiners is supported before using it. I'm going to close > > the ticket. > > Are you sure that NV_register_combiners are used? I haven't checked the > trace myself but I doubt this is a case. > > (In reply to Shmerl from comment #11) > > I just replayed my trace (recorder on radeonsi / RX480), and I see this in > > the log: > > > > 120612: message: major api error 2: GL_INVALID_ENUM in > > glActiveTexture(texture=GL_COMBINER0_NV) > > 120612 @1 glActiveTexture(texture = GL_COMBINER0_NV) > > 120619: message: major api error 2: GL_INVALID_ENUM in > > glActiveTexture(texture=GL_COMBINER1_NV) > > 120619 @1 glActiveTexture(texture = GL_COMBINER1_NV) > > 120626: message: major api error 2: GL_INVALID_ENUM in > > glActiveTexture(texture=GL_COMBINER2_NV) > > 120626 @1 glActiveTexture(texture = GL_COMBINER2_NV) > > 120633: message: major api error 2: GL_INVALID_ENUM in > > glActiveTexture(texture=GL_COMBINER3_NV) > > 120633 @1 glActiveTexture(texture = GL_COMBINER3_NV) > > 120640: message: major api error 2: GL_INVALID_ENUM in > > glActiveTexture(texture=GL_COMBINER4_NV) > > 120640 @1 glActiveTexture(texture = GL_COMBINER4_NV) > > 120647: message: major api error 2: GL_INVALID_ENUM in > > glActiveTexture(texture=GL_COMBINER5_NV) > > 120647 @1 glActiveTexture(texture = GL_COMBINER5_NV) > > 120654: message: major api error 2: GL_INVALID_ENUM in > > glActiveTexture(texture=GL_COMBINER6_NV) > > 120654 @1 glActiveTexture(texture = GL_COMBINER6_NV) > > 120661: message: major api error 2: GL_INVALID_ENUM in > > glActiveTexture(texture=GL_COMBINER7_NV) > > 120661 @1 glActiveTexture(texture = GL_COMBINER7_NV) > > This has nothing to do with NV_register_combiners. It just displayed like > this in apitrace, because GL_COMBINERi_NV = GL_TEXTURE0 + x. You are right. The game wants 192 texture units but RadeonSI only exposes 144 (24 per stages), that explains at least, the glActiveTexture() errors in the trace. But according to the GL spec, the minimum number of texture units is 80. -- 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 v6] drm: Provide a driver hook for drm_dev_release()
On Thu, Feb 02, 2017 at 09:36:32AM +, Chris Wilson wrote:
> Some state is coupled into the device lifetime outside of the
> load/unload timeframe and requires teardown during final unreference
> from drm_dev_release(). For example, dmabufs hold both a device and
> module reference and may live longer than expected (i.e. the current
> pattern of the driver tearing down its state and then releasing a
> reference to the drm device) and yet touch driver private state when
> destroyed.
>
> v2: Export drm_dev_fini() and move the responsibility for finalizing the
> drm_device and freeing it to the release callback. (If no callback is
> provided, the core will call drm_dev_fini() and kfree(dev) as before.)
> v3: Remember to add drm_dev_fini() to drm_drv.h
> v4: Tidy language for kerneldoc
> v5: Cross reference from drm_dev_init() to note that driver->release()
> allows for arbitrary embedding.
> v6: Refer to driver data rather than driver state, as state is now
> becoming associated with the struct drm_atomic_state and friends.
>
> Signed-off-by: Chris Wilson
> Cc: Laurent Pinchart
> Cc: Daniel Vetter
> Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/drm_drv.c | 65
> ---
> include/drm/drm_drv.h | 13 ++
> 2 files changed, 58 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index a8ce3179c07c..e122e4d022f8 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -465,7 +465,10 @@ static void drm_fs_inode_free(struct inode *inode)
> * that do embed &struct drm_device it must be placed first in the overall
> * structure, and the overall structure must be allocated using kmalloc():
> The
> * drm core's release function unconditionally calls kfree() on the @dev
> pointer
> - * when the final reference is released.
> + * when the final reference is released. To override this behaviour, and so
> + * allow embedding of the drm_device inside the driver's device struct at an
> + * arbitrary offset, you must supply a driver->release() callback and control
The new official way to reference a struct member is &foo.bar. I've
applied this polish to both places and applied your patch, thanks a lot.
-Daniel
> + * the finalization explicitly.
> *
> * RETURNS:
> * 0 on success, or error code on failure.
> @@ -553,6 +556,41 @@ int drm_dev_init(struct drm_device *dev,
> EXPORT_SYMBOL(drm_dev_init);
>
> /**
> + * drm_dev_fini - Finalize a dead DRM device
> + * @dev: DRM device
> + *
> + * Finalize a dead DRM device. This is the converse to drm_dev_init() and
> + * frees up all data allocated by it. All driver private data should be
> + * finalized first. Note that this function does not free the @dev, that is
> + * left to the caller.
> + *
> + * The ref-count of @dev must be zero, and drm_dev_fini() should only be
> called
> + * from a drm_driver->release() callback.
> + */
> +void drm_dev_fini(struct drm_device *dev)
> +{
> + drm_vblank_cleanup(dev);
> +
> + if (drm_core_check_feature(dev, DRIVER_GEM))
> + drm_gem_destroy(dev);
> +
> + drm_legacy_ctxbitmap_cleanup(dev);
> + drm_ht_remove(&dev->map_hash);
> + drm_fs_inode_free(dev->anon_inode);
> +
> + drm_minor_free(dev, DRM_MINOR_PRIMARY);
> + drm_minor_free(dev, DRM_MINOR_RENDER);
> + drm_minor_free(dev, DRM_MINOR_CONTROL);
> +
> + mutex_destroy(&dev->master_mutex);
> + mutex_destroy(&dev->ctxlist_mutex);
> + mutex_destroy(&dev->filelist_mutex);
> + mutex_destroy(&dev->struct_mutex);
> + kfree(dev->unique);
> +}
> +EXPORT_SYMBOL(drm_dev_fini);
> +
> +/**
> * drm_dev_alloc - Allocate new DRM device
> * @driver: DRM driver to allocate device for
> * @parent: Parent device object
> @@ -598,25 +636,12 @@ static void drm_dev_release(struct kref *ref)
> {
> struct drm_device *dev = container_of(ref, struct drm_device, ref);
>
> - drm_vblank_cleanup(dev);
> -
> - if (drm_core_check_feature(dev, DRIVER_GEM))
> - drm_gem_destroy(dev);
> -
> - drm_legacy_ctxbitmap_cleanup(dev);
> - drm_ht_remove(&dev->map_hash);
> - drm_fs_inode_free(dev->anon_inode);
> -
> - drm_minor_free(dev, DRM_MINOR_PRIMARY);
> - drm_minor_free(dev, DRM_MINOR_RENDER);
> - drm_minor_free(dev, DRM_MINOR_CONTROL);
> -
> - mutex_destroy(&dev->master_mutex);
> - mutex_destroy(&dev->ctxlist_mutex);
> - mutex_destroy(&dev->filelist_mutex);
> - mutex_destroy(&dev->struct_mutex);
> - kfree(dev->unique);
> - kfree(dev);
> + if (dev->driver->release) {
> + dev->driver->release(dev);
> + } else {
> + drm_dev_fini(dev);
> + kfree(dev);
> + }
> }
>
> /**
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 732e85652d1e..5699f42195fe 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -102,6 +102,17 @@ struct drm_driver {
>
[PATCH 2/2] drm: meson: rename driver name to meson-drm
The platform driver name is currently "meson" which can lead to some
confusion, this patch renames it to "meson-drm" and removes the owner
attribute.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index ff1f601..380bde7 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -329,8 +329,7 @@ static int meson_drv_remove(struct platform_device *pdev)
.probe = meson_drv_probe,
.remove = meson_drv_remove,
.driver = {
- .owner = THIS_MODULE,
- .name = DRIVER_NAME,
+ .name = "meson-drm",
.of_match_table = dt_match,
},
};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm: meson: Fixup driver and module name
This patchset is a simple fixup to rename the confusion possible module and driver name "meson" to a more explicit "meson-drm" name. Neil Armstrong (2): drm: meson: rename module name to meson-drm drm: meson: rename driver name to meson-drm drivers/gpu/drm/meson/Makefile| 6 +++--- drivers/gpu/drm/meson/meson_drv.c | 3 +-- 2 files changed, 4 insertions(+), 5 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: meson: rename module name to meson-drm
The module is currently names "meson.ko" which can lead to some confusion, this patches renames it "meson-drm.ko" Signed-off-by: Neil Armstrong --- drivers/gpu/drm/meson/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile index 2591978..92cf845 100644 --- a/drivers/gpu/drm/meson/Makefile +++ b/drivers/gpu/drm/meson/Makefile @@ -1,4 +1,4 @@ -meson-y := meson_drv.o meson_plane.o meson_crtc.o meson_venc_cvbs.o -meson-y += meson_viu.o meson_vpp.o meson_venc.o meson_vclk.o meson_canvas.o +meson-drm-y := meson_drv.o meson_plane.o meson_crtc.o meson_venc_cvbs.o +meson-drm-y += meson_viu.o meson_vpp.o meson_venc.o meson_vclk.o meson_canvas.o -obj-$(CONFIG_DRM_MESON) += meson.o +obj-$(CONFIG_DRM_MESON) += meson-drm.o -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm: scrambling support in drm layer
On Thu, Feb 02, 2017 at 11:18:51AM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 2/1/2017 10:02 PM, Ville Syrjälä wrote: > > On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote: > >> HDMI 2.0 spec mandates scrambling for modes with pixel clock higher > >> than 340Mhz. This patch adds few new functions in drm layer for > >> core drivers to enable/disable scrambling. > >> > >> This patch adds: > >> - A function to detect scrambling support parsing HF-VSDB > >> - A function to check scrambling status runtime using SCDC read. > >> - Two functions to enable/disable scrambling using SCDC read/write. > >> - Few new bools to reflect scrambling support and status. > >> > >> Signed-off-by: Shashank Sharma > >> --- > >> drivers/gpu/drm/drm_edid.c | 131 > >> +++- > >> include/drm/drm_connector.h | 24 > >> include/drm/drm_edid.h | 6 +- > >> 3 files changed, 159 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > >> index 37902e5..f0d940a 100644 > >> --- a/drivers/gpu/drm/drm_edid.c > >> +++ b/drivers/gpu/drm/drm_edid.c > >> @@ -37,6 +37,7 @@ > >> #include > >> #include > >> #include > >> +#include > >> > >> #define version_greater(edid, maj, min) \ > >>(((edid)->version > (maj)) || \ > >> @@ -3814,6 +3815,132 @@ static void drm_detect_hdmi_scdc(struct > >> drm_connector *connector, > >>} > >> } > >> > >> +static void drm_detect_hdmi_scrambling(struct drm_connector *connector, > >> + const u8 *hf_vsdb) > > That names seems off. Should probably be drm_parse_hdmi_forum_vsdb() or > > something. > Actually, unlike the last patch set, we are not parsing the whole > hf_vsdb, but parsing it only for > scrambling status byte (hf_vsdb[5]). But may be I can make it > drm_detect_scrambling_from_hfvsdb > ot something similar. We will have more hf_vsdb parsing for 3d flags, > yuv420_deep_color etc. Well, so far I'm not seeing much point in splitting it up. So I'd stuff it all into one place, for now at least. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL] etnaviv-next for 4.11
Hi Dave, this is the Etnaviv feature pull request for 4.11. It includes code cleanups from Bhumika and Liviu, a significant shader performance fix and additions to the cmdstream validator from Wladimir and the addition of a cmdbuf suballocator by myself. The suballocator improves performance on all chips by reducing the CPU overhead of the kernel driver and side steps the GC3000 FE MMU flush erratum, now making the workarounds in IOVA allocation we had before unnecessary, which results in a nice cleanup of the code in that area. Regards, Lucas The following changes since commit 3546fb0cdac25a79c89d87020566fab52b92867d: drm/etnaviv: trick drm_mm into giving out a low IOVA (2017-01-11 10:38:45 +0100) are available in the git repository at: https://git.pengutronix.de/git/lst/linux drm-etnaviv-next for you to fetch changes up to 82260364fd0c7822c782771374cb4a4deb00d3f6: drm/etnaviv: Remove duplicate header file include (2017-02-02 10:30:51 +0100) Bhumika Goyal (1): drm/etnaviv: constify etnaviv_iommu_ops structures Liviu Dudau (1): drm/etnaviv: Remove duplicate header file include Lucas Stach (6): drm/etnaviv: always flush MMU TLBs on map/unmap drm/etnaviv: move cmdbuf de-/allocation into own file drm/etnaviv: wire up iova handling in new cmdbuf abstraction drm/etnaviv: get cmdbuf physical address through the cmdbuf abstraction drm/etnaviv: add cmdbuf suballocator Revert "drm/etnaviv: trick drm_mm into giving out a low IOVA" Wladimir J. van der Laan (2): drm/etnaviv: add new GC3000 sensitive states drm/etnaviv: set up initial PULSE_EATER register drivers/gpu/drm/etnaviv/Makefile | 1 + drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 14 +-- drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c | 6 ++ drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 153 +++ drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h | 58 drivers/gpu/drm/etnaviv/etnaviv_drv.c| 5 +- drivers/gpu/drm/etnaviv/etnaviv_dump.c | 6 +- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 8 +- drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 95 ++- drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 28 +- drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 2 +- drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 6 +- drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 60 +--- drivers/gpu/drm/etnaviv/etnaviv_mmu.h| 10 +- 14 files changed, 329 insertions(+), 123 deletions(-) create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c create mode 100644 drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm/i915: enable scrambling
On Thu, Feb 02, 2017 at 11:23:19AM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/1/2017 10:06 PM, Ville Syrjälä wrote:
> > On Wed, Feb 01, 2017 at 06:14:40PM +0530, Shashank Sharma wrote:
> >> Geminilake platform has a native HDMI 2.0 controller, and is
> >> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> >> mendates scrambling for these higher clocks, for reduced RF footprint.
> >>
> >> This patch checks if the monitor supports scrambling, and if required,
> >> enables it during the modeset.
> >>
> >> Signed-off-by: Shashank Sharma
> >> ---
> >> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> >> drivers/gpu/drm/i915/intel_ddi.c | 5 +
> >> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> >> drivers/gpu/drm/i915/intel_hdmi.c | 42
> >> +++
> >> 4 files changed, 51 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> b/drivers/gpu/drm/i915/i915_reg.h
> >> index 495b789..cc85892 100644
> >> --- a/drivers/gpu/drm/i915/i915_reg.h
> >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> @@ -7807,6 +7807,8 @@ enum {
> >> #define TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
> >> #define TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
> >> #define TRANS_DDI_BFI_ENABLE(1<<4)
> >> +#define TRANS_DDI_HIGH_TMDS_CHAR_RATE(1<<4)
> >> +#define TRANS_DDI_HDMI_SCRAMBLING(1<<0)
> >>
> >> /* DisplayPort Transport Control */
> >> #define _DP_TP_CTL_A 0x64040
> >> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> >> b/drivers/gpu/drm/i915/intel_ddi.c
> >> index 9a9a670..aea81ce 100644
> >> --- a/drivers/gpu/drm/i915/intel_ddi.c
> >> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> >> @@ -1278,6 +1278,11 @@ void intel_ddi_enable_transcoder_func(struct
> >> drm_crtc *crtc)
> >>temp |= TRANS_DDI_MODE_SELECT_HDMI;
> >>else
> >>temp |= TRANS_DDI_MODE_SELECT_DVI;
> >> +
> >> + if (IS_GEMINILAKE(dev_priv)) {
> >> + temp |= intel_hdmi_check_scrambling(intel_encoder,
> >> + &intel_crtc->config->base.adjusted_mode);
> >> + }
> >>} else if (type == INTEL_OUTPUT_ANALOG) {
> >>temp |= TRANS_DDI_MODE_SELECT_FDI;
> >>temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
> >> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> >> b/drivers/gpu/drm/i915/intel_drv.h
> >> index 393f243..aafce7f 100644
> >> --- a/drivers/gpu/drm/i915/intel_drv.h
> >> +++ b/drivers/gpu/drm/i915/intel_drv.h
> >> @@ -1588,6 +1588,8 @@ void intel_hdmi_init_connector(struct
> >> intel_digital_port *intel_dig_port,
> >> bool intel_hdmi_compute_config(struct intel_encoder *encoder,
> >> struct intel_crtc_state *pipe_config,
> >> struct drm_connector_state *conn_state);
> >> +uint32_t intel_hdmi_check_scrambling(struct intel_encoder *intel_encoder,
> >> + struct drm_display_mode *mode);
> >> void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool
> >> enable);
> >>
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> >> b/drivers/gpu/drm/i915/intel_hdmi.c
> >> index ebae2bd..92dd9bc 100644
> >> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> >> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> >> @@ -1795,6 +1795,48 @@ static void intel_hdmi_destroy(struct drm_connector
> >> *connector)
> >>intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> >> }
> >>
> >> +static void
> >> +intel_hdmi_enable_scrambling(struct drm_connector *connector)
> >> +{
> >> + struct drm_i915_private *dev_priv = connector->dev->dev_private;
> >> + struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> >> + struct i2c_adapter *adapter =
> >> + intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
> >> +
> >> + if (!drm_enable_scrambling(connector, adapter, true))
> >> + DRM_ERROR("Request to enable scrambling failed\n");
> >> +}
> > I don't like hiding this somewhere deep like this. It should be
> > somewhere much higher up.
> Why ? All we need to do here is enable two bits in transcoder control
> register, which is already being
> programmed in a calling function, so I dont see the use case, but I
> might be missing some bigger picture.
> Can you please elaborate on this ?
We're talking to the display here, which is rather surprising to happen
from a function thing that on the first glance doesn't even seem to
touch the hardware.
> >
> > And I'm thinkign we might want to track the scrambler state
> > in the crtc state.
> Yes, that's a pretty good way to track dynamic status of scrambler, do
> you think we should add this in
> drm_crtc_state itself ?
I'd just start with intel specific state and later we can see what
everyone else wants to do and potentially unify a bit.
>
> - Shashank
> >> +
> >> +uint32_t intel_hdmi_check_scrambling(struct intel_encoder *intel_encoder,
> >> +
Re: [PATCH 4/6] drm: scrambling support in drm layer
Regards Shashank On 2/2/2017 3:21 PM, Ville Syrjälä wrote: On Thu, Feb 02, 2017 at 11:18:51AM +0530, Sharma, Shashank wrote: Regards Shashank On 2/1/2017 10:02 PM, Ville Syrjälä wrote: On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote: HDMI 2.0 spec mandates scrambling for modes with pixel clock higher than 340Mhz. This patch adds few new functions in drm layer for core drivers to enable/disable scrambling. This patch adds: - A function to detect scrambling support parsing HF-VSDB - A function to check scrambling status runtime using SCDC read. - Two functions to enable/disable scrambling using SCDC read/write. - Few new bools to reflect scrambling support and status. Signed-off-by: Shashank Sharma --- drivers/gpu/drm/drm_edid.c | 131 +++- include/drm/drm_connector.h | 24 include/drm/drm_edid.h | 6 +- 3 files changed, 159 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 37902e5..f0d940a 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -37,6 +37,7 @@ #include #include #include +#include #define version_greater(edid, maj, min) \ (((edid)->version > (maj)) || \ @@ -3814,6 +3815,132 @@ static void drm_detect_hdmi_scdc(struct drm_connector *connector, } } +static void drm_detect_hdmi_scrambling(struct drm_connector *connector, +const u8 *hf_vsdb) That names seems off. Should probably be drm_parse_hdmi_forum_vsdb() or something. Actually, unlike the last patch set, we are not parsing the whole hf_vsdb, but parsing it only for scrambling status byte (hf_vsdb[5]). But may be I can make it drm_detect_scrambling_from_hfvsdb ot something similar. We will have more hf_vsdb parsing for 3d flags, yuv420_deep_color etc. Well, so far I'm not seeing much point in splitting it up. So I'd stuff it all into one place, for now at least. I had published a patch just doing as you suggested which was parsing complete hf-vsdb in one shot, and adding info in hdmi_info structure, to accommodate it. (Patch https://patchwork.freedesktop.org/patch/128963/ and https://patchwork.freedesktop.org/patch/128962/) But you gave a review comment not to add anything which is not being used in the patch series: https://patchwork.freedesktop.org/patch/128962/ That was the only reason I have split hf-vsdb parsing patch into 3 parts - parse SCDC and scrambling info (here) - with YUV420 deep color ( upcoming ) - with 3d handling (upcoming) So I am confused, split or no split :-) ? - Shashank ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 00/25] drm/bridge/sii8620: add Ultra HD modes support
On 02/01/2017 01:17 PM, Andrzej Hajda wrote: Hi Archit, Sorry for spamming, forgot to add the list. This quite big patchset adds support for 4K Ultra HD modes in SiI8620 MHL bridge. To support it full MHL3 protocol and its sub-protocols should be implemented. Patchset contains also various fixes for bugs discovered during development. v3: - upper-cased enums - add missing include to patch 6 (thanks to kbuild test robot) queued to drm-misc-next after resolving some trivial checkpatch issues. Archit Regards Andrzej Andrzej Hajda (25): drm/bridge/sii8620: simplify MHL3 mode setting drm/bridge/sii8620: add MHL3 mode check helper drm/bridge/sii8620: add reading device capability registers drm/bridge/sii8620: add continuations to messages drm/bridge/sii8620: initial support for eCBUS-S mode drm/bridge/mhl: add write burst related definitions drm/bridge/sii8620: add support for burst eMSC transmissions drm/bridge/sii8620: respond to feature requests drm/bridge/sii8620: fix peer device capabilities read code drm/bridge/sii8620: remove spare CBUS bring-up sequence drm/bridge/sii8620: fix MSC message removal drm/bridge/sii8620: fix initialization sequence for MHL2 receivers drm/bridge/sii8620: abstract out sink detection code drm/bridge/sii8620: set gen2 write burst before sending MSC command drm/bridge/sii8620: do not stop MHL output when TMDS input is stopped drm/bridge/sii8620: add delay during cbus reset drm/bridge/sii8620: split EDID read and write code drm/bridge/sii8620: fix disconnect sequence drm/bridge/mhl: add MHL3 infoframe related definitions drm/bridge/sii8620: rewrite hdmi start sequence drm/bridge/sii8620: send EMSC features on request drm/bridge/sii8620: improve gen2 write burst IRQ routine drm/bridge/sii8620: add HSIC initialization code drm/bridge/sii8620: enable MHL3 mode if possible drm/bridge/sii8620: enable interlace modes drivers/gpu/drm/bridge/sil-sii8620.c | 948 ++- drivers/gpu/drm/bridge/sil-sii8620.h | 50 +- include/drm/bridge/mhl.h | 85 3 files changed, 933 insertions(+), 150 deletions(-) -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 193651] Amdgpu error messages at boot with Amd RX460
https://bugzilla.kernel.org/show_bug.cgi?id=193651 --- Comment #8 from fin4...@hotmail.com --- Alex, thanks for the new firmware. Still Bios recognition errors at boot, but otherwise ok. [3.461112] [drm] BIOS signature incorrect 20 7 [3.461117] amdgpu :01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x Steven, you are using Tonga gpu and radeon kernel driver that fails at boot and the system using VESA driver. The amdgpu driver has support for Tonga, but you need to make a custom 4.11-wip kernel. Stock distribution kernels do not have stable amdgpu code. Creating a custom kernel in Debian: Use the command: git clone -b drm-next-4.11-wip git://people.freedesktop.org/~agd5f/linux The kernel configuration file of Debian Official kernel are available in /boot, named after the kernel release. Copy the .config file to the linux directory. Connect all your devices and run the command: make localmodconfig. You can use the command make defconfig too for creating initial .config file. Use the command: make xconfig and check that you have enabled: Reroute Broken IRQ, Virtualization KVM and 300Hz CPU timer, I also disabled Swap, Kernel Debug, CPU Freq scaling , Cpu handling in Acpi, Used Bios to control CPU and devices. In the drivers->graphics->amdgpu enable cik support for a gcn 1.1 gpu and si support for a gcn 1.0 gpu. Create debian kernel package: export CONCURRENCY_LEVEL=4 fakeroot make-kpkg --initrd kernel_image Install the kernel package with Gdebi. To make a custom kernel to boot, add a line to /etc/initramfs-tools/modules: unix And run: sudo update-initramfs Reboot. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm: scrambling support in drm layer
On Thu, Feb 02, 2017 at 03:46:55PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 2/2/2017 3:21 PM, Ville Syrjälä wrote: > > On Thu, Feb 02, 2017 at 11:18:51AM +0530, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >> > >> On 2/1/2017 10:02 PM, Ville Syrjälä wrote: > >>> On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote: > HDMI 2.0 spec mandates scrambling for modes with pixel clock higher > than 340Mhz. This patch adds few new functions in drm layer for > core drivers to enable/disable scrambling. > > This patch adds: > - A function to detect scrambling support parsing HF-VSDB > - A function to check scrambling status runtime using SCDC read. > - Two functions to enable/disable scrambling using SCDC read/write. > - Few new bools to reflect scrambling support and status. > > Signed-off-by: Shashank Sharma > --- > drivers/gpu/drm/drm_edid.c | 131 > +++- > include/drm/drm_connector.h | 24 > include/drm/drm_edid.h | 6 +- > 3 files changed, 159 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 37902e5..f0d940a 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -37,6 +37,7 @@ > #include > #include > #include > +#include > > #define version_greater(edid, maj, min) \ > (((edid)->version > (maj)) || \ > @@ -3814,6 +3815,132 @@ static void drm_detect_hdmi_scdc(struct > drm_connector *connector, > } > } > > +static void drm_detect_hdmi_scrambling(struct drm_connector *connector, > + const u8 *hf_vsdb) > >>> That names seems off. Should probably be drm_parse_hdmi_forum_vsdb() or > >>> something. > >> Actually, unlike the last patch set, we are not parsing the whole > >> hf_vsdb, but parsing it only for > >> scrambling status byte (hf_vsdb[5]). But may be I can make it > >> drm_detect_scrambling_from_hfvsdb > >> ot something similar. We will have more hf_vsdb parsing for 3d flags, > >> yuv420_deep_color etc. > > Well, so far I'm not seeing much point in splitting it up. So I'd stuff > > it all into one place, for now at least. > I had published a patch just doing as you suggested which was parsing > complete hf-vsdb in one shot, and adding info in > hdmi_info structure, to accommodate it. > (Patch https://patchwork.freedesktop.org/patch/128963/ and > https://patchwork.freedesktop.org/patch/128962/) > > But you gave a review comment not to add anything which is not being > used in the patch series: > https://patchwork.freedesktop.org/patch/128962/ That's doesn't require the things that are left to be split into separate functions. > > That was the only reason I have split hf-vsdb parsing patch into 3 parts > - parse SCDC and scrambling info (here) > - with YUV420 deep color ( upcoming ) > - with 3d handling (upcoming) > > So I am confused, split or no split :-) ? > > - Shashank -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC
From: Stefan Christ
Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
framebuffer emulation driver. Legacy framebuffer users like non kms/drm
based OpenGL(ES)/EGL implementations may require the ioctl to
synchronize drawing or buffer flip for double buffering. It is tested on
the i.MX6.
Code is based on
https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196
Signed-off-by: Stefan Christ
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 55 ++-
include/drm/drm_fb_helper.h | 5 ++-
2 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index e934b541feea..39a3532e311c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct
fb_info *info)
EXPORT_SYMBOL(drm_fb_helper_setcmap);
/**
+ * drm_fb_helper_ioctl - legacy ioctl implementation
+ * @info: fbdev registered by the helper
+ * @cmd: ioctl command
+ * @arg: ioctl argument
+ *
+ * A helper to implement the standard fbdev ioctl. Only
+ * FBIO_WAITFORVSYNC is implemented for now.
+ */
+int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long
arg)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+ struct drm_device *dev = fb_helper->dev;
+ unsigned int i;
+ int ret = 0;
+
+ drm_modeset_lock_all(dev);
+ if (!drm_fb_helper_is_bound(fb_helper)) {
+ drm_modeset_unlock_all(dev);
+ return -EBUSY;
+ }
+
+ switch (cmd) {
+ case FBIO_WAITFORVSYNC:
+ for (i = 0; i < fb_helper->crtc_count; i++) {
+ struct drm_mode_set *mode_set;
+ struct drm_crtc *crtc;
+
+ mode_set = &fb_helper->crtc_info[i].mode_set;
+ crtc = mode_set->crtc;
+
+ /*
+* Only call drm_crtc_wait_one_vblank for crtcs that
+* are currently enabled.
+*/
+ if (!crtc->enabled)
+ continue;
+
+ ret = drm_crtc_vblank_get(crtc);
+ if (!ret) {
+ drm_crtc_wait_one_vblank(crtc);
+ drm_crtc_vblank_put(crtc);
+ }
+ }
+ goto unlock;
+ default:
+ ret = -ENOTTY;
+ }
+
+unlock:
+ drm_modeset_unlock_all(dev);
+ return ret;
+}
+EXPORT_SYMBOL(drm_fb_helper_ioctl);
+
+/**
* drm_fb_helper_check_var - implementation for ->fb_check_var
* @var: screeninfo to check
* @info: fbdev registered by the helper
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 975deedd593e..460be9d9fa98 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -230,7 +230,8 @@ struct drm_fb_helper {
.fb_blank = drm_fb_helper_blank, \
.fb_pan_display = drm_fb_helper_pan_display, \
.fb_debug_enter = drm_fb_helper_debug_enter, \
- .fb_debug_leave = drm_fb_helper_debug_leave
+ .fb_debug_leave = drm_fb_helper_debug_leave, \
+ .fb_ioctl = drm_fb_helper_ioctl
#ifdef CONFIG_DRM_FBDEV_EMULATION
void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
*helper,
@@ -286,6 +287,8 @@ void drm_fb_helper_set_suspend_unlocked(struct
drm_fb_helper *fb_helper,
int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
+int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long
arg);
+
int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper);
int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel);
int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper);
--
git-series 0.8.11
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev
From: Xinliang Liu This patch add a config to support to create multi buffer for cma fbdev. Such as double buffer and triple buffer. Cma fbdev is convient to add a legency fbdev. And still many Android devices use fbdev now and at least double buffer is needed for these Android devices, so that a buffer flip can be operated. It will need some time for Android device vendors to abondon legency fbdev. So multi buffer for fbdev is needed. Signed-off-by: Xinliang Liu [s.chr...@phytec.de: Picking patch from https://lkml.org/lkml/2015/9/14/188] Signed-off-by: Stefan Christ Signed-off-by: Maxime Ripard --- drivers/gpu/drm/Kconfig | 8 drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index ebfe8404c25f..2ca9bb26a4e4 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -121,6 +121,14 @@ config DRM_KMS_CMA_HELPER help Choose this if you need the KMS CMA helper functions +config DRM_CMA_FBDEV_BUFFER_NUM + int "Cma Fbdev Buffer Number" + depends on DRM_KMS_CMA_HELPER + default 1 + help + Defines the buffer number of cma fbdev. Default is one buffer. + For double buffer please set to 2 and 3 for triple buffer. + source "drivers/gpu/drm/i2c/Kconfig" source "drivers/gpu/drm/arm/Kconfig" diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c index 81b3558302b5..e3f8b9e720a0 100644 --- a/drivers/gpu/drm/drm_fb_cma_helper.c +++ b/drivers/gpu/drm/drm_fb_cma_helper.c @@ -411,6 +411,12 @@ static void drm_fbdev_cma_defio_fini(struct fb_info *fbi) kfree(fbi->fbops); } +static int fbdev_num_buffers = CONFIG_DRM_CMA_FBDEV_BUFFER_NUM; +module_param(fbdev_num_buffers, int, 0444); +MODULE_PARM_DESC(fbdev_num_buffers, +"Number of frame buffers to allocate [default=" +__MODULE_STRING(CONFIG_DRM_CMA_FBDEV_BUFFER_NUM) "]"); + /* * For use in a (struct drm_fb_helper_funcs *)->fb_probe callback function that * needs custom struct drm_framebuffer_funcs, like dirty() for deferred_io use. @@ -437,7 +443,7 @@ int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper *helper, bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8); mode_cmd.width = sizes->surface_width; - mode_cmd.height = sizes->surface_height; + mode_cmd.height = sizes->surface_height * fbdev_num_buffers; mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel; mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp, sizes->surface_depth); -- git-series 0.8.11 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] drm: Support framebuffer panning
Hi, This is a respin of the previous serie called "Support fast framebuffer panning for i.MX6" made by Stefan 6 monthes ago. The imx6 bits have been removed, and the comments that were made at that time fixed (hopefully). Let me know what you think, Maxime Changes from v1: - Added drm_fb_helper_ioctl to DRM_FB_HELPER_DEFAULT_OPS - Expanded a bit the kerneldoc for drm_fb_helper_ioctl - Added some locking to drm_fb_helper_ioctl - Checked that the framebuffer is indeed attached before allowing ioctl - Added a module parameter to specify the number of framebuffers to allocate Initial cover letter: Support fast framebuffer panning for i.MX6 im currently working on supporting double/tripple buffering for the framebuffer emulation on the i.MX6. While working on it I noticed that the mainline kernel does not support some features in the generic drm framebuffer emulation for framebuffer panning and vsync synchronisation. They are needed for simple framebuffer applications and some OpenGL libraries using double buffering with FBIOPUT_VSCREENINFO, FBIO_WAITFORVSYNC and FBIOPAN_DISPLAY. Stefan Christ (1): drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC Xinliang Liu (1): drm/cma-helper: Add multi buffer support for cma fbdev drivers/gpu/drm/Kconfig | 8 - drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++- drivers/gpu/drm/drm_fb_helper.c | 55 ++- include/drm/drm_fb_helper.h | 5 ++- 4 files changed, 74 insertions(+), 2 deletions(-) base-commit: 8b394ae674998d4ade6cb48aec3fca5445908dfe -- git-series 0.8.11 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 193651] Amdgpu error messages at boot with Amd RX460
https://bugzilla.kernel.org/show_bug.cgi?id=193651 --- Comment #9 from fin4...@hotmail.com --- After updating the firmware I still have powerplay erros: [3.574222] amdgpu: [powerplay] [AVFS] Something is broken. See log! [3.577052] amdgpu: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm: scrambling support in drm layer
Regards Shashank On 2/2/2017 3:58 PM, Ville Syrjälä wrote: On Thu, Feb 02, 2017 at 03:46:55PM +0530, Sharma, Shashank wrote: Regards Shashank On 2/2/2017 3:21 PM, Ville Syrjälä wrote: On Thu, Feb 02, 2017 at 11:18:51AM +0530, Sharma, Shashank wrote: Regards Shashank On 2/1/2017 10:02 PM, Ville Syrjälä wrote: On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote: HDMI 2.0 spec mandates scrambling for modes with pixel clock higher than 340Mhz. This patch adds few new functions in drm layer for core drivers to enable/disable scrambling. This patch adds: - A function to detect scrambling support parsing HF-VSDB - A function to check scrambling status runtime using SCDC read. - Two functions to enable/disable scrambling using SCDC read/write. - Few new bools to reflect scrambling support and status. Signed-off-by: Shashank Sharma --- drivers/gpu/drm/drm_edid.c | 131 +++- include/drm/drm_connector.h | 24 include/drm/drm_edid.h | 6 +- 3 files changed, 159 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 37902e5..f0d940a 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -37,6 +37,7 @@ #include #include #include +#include #define version_greater(edid, maj, min) \ (((edid)->version > (maj)) || \ @@ -3814,6 +3815,132 @@ static void drm_detect_hdmi_scdc(struct drm_connector *connector, } } +static void drm_detect_hdmi_scrambling(struct drm_connector *connector, +const u8 *hf_vsdb) That names seems off. Should probably be drm_parse_hdmi_forum_vsdb() or something. Actually, unlike the last patch set, we are not parsing the whole hf_vsdb, but parsing it only for scrambling status byte (hf_vsdb[5]). But may be I can make it drm_detect_scrambling_from_hfvsdb ot something similar. We will have more hf_vsdb parsing for 3d flags, yuv420_deep_color etc. Well, so far I'm not seeing much point in splitting it up. So I'd stuff it all into one place, for now at least. I had published a patch just doing as you suggested which was parsing complete hf-vsdb in one shot, and adding info in hdmi_info structure, to accommodate it. (Patch https://patchwork.freedesktop.org/patch/128963/ and https://patchwork.freedesktop.org/patch/128962/) But you gave a review comment not to add anything which is not being used in the patch series: https://patchwork.freedesktop.org/patch/128962/ That's doesn't require the things that are left to be split into separate functions. So please let me know if my understanding is correct. - Name the function as *_parse_hfvsdb only - Call it while parsing the EDID extension blocks (the same place) - Keep on adding parsing of the HF-VSDB blocks, in the same function, in an incremental way, as we add patches for them. In this way the function won't be split into multiple small functions, but all the parsing will be done in one function. - Shashank That was the only reason I have split hf-vsdb parsing patch into 3 parts - parse SCDC and scrambling info (here) - with YUV420 deep color ( upcoming ) - with 3d handling (upcoming) So I am confused, split or no split :-) ? - Shashank ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: meson: rename driver name to meson-drm
On Thu, Feb 02, 2017 at 10:47:44AM +0100, Neil Armstrong wrote:
> The platform driver name is currently "meson" which can lead to some
> confusion, this patch renames it to "meson-drm" and removes the owner
> attribute.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_drv.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index ff1f601..380bde7 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -329,8 +329,7 @@ static int meson_drv_remove(struct platform_device *pdev)
> .probe = meson_drv_probe,
> .remove = meson_drv_remove,
> .driver = {
> - .owner = THIS_MODULE,
I don't get why you remove this, generally that will lead to trouble of
being able to unload code that's still in use ...
Otherwise ack.
Now, do you want to get this landed as part of the small drivers in
drm-mis experiment?
-Daniel
> - .name = DRIVER_NAME,
> + .name = "meson-drm",
> .of_match_table = dt_match,
> },
> };
> --
> 1.9.1
>
--
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 5/6] drm/i915: enable scrambling
Regards
Shashank
On 2/2/2017 3:32 PM, Ville Syrjälä wrote:
On Thu, Feb 02, 2017 at 11:23:19AM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 2/1/2017 10:06 PM, Ville Syrjälä wrote:
On Wed, Feb 01, 2017 at 06:14:40PM +0530, Shashank Sharma wrote:
Geminilake platform has a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_ddi.c | 5 +
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 42
+++
4 files changed, 51 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 495b789..cc85892 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7807,6 +7807,8 @@ enum {
#define TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
#define TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8)
#define TRANS_DDI_BFI_ENABLE(1<<4)
+#define TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
+#define TRANS_DDI_HDMI_SCRAMBLING (1<<0)
/* DisplayPort Transport Control */
#define _DP_TP_CTL_A 0x64040
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 9a9a670..aea81ce 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1278,6 +1278,11 @@ void intel_ddi_enable_transcoder_func(struct drm_crtc
*crtc)
temp |= TRANS_DDI_MODE_SELECT_HDMI;
else
temp |= TRANS_DDI_MODE_SELECT_DVI;
+
+ if (IS_GEMINILAKE(dev_priv)) {
+ temp |= intel_hdmi_check_scrambling(intel_encoder,
+ &intel_crtc->config->base.adjusted_mode);
+ }
} else if (type == INTEL_OUTPUT_ANALOG) {
temp |= TRANS_DDI_MODE_SELECT_FDI;
temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 393f243..aafce7f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1588,6 +1588,8 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
bool intel_hdmi_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state);
+uint32_t intel_hdmi_check_scrambling(struct intel_encoder *intel_encoder,
+ struct drm_display_mode *mode);
void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool
enable);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c
index ebae2bd..92dd9bc 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1795,6 +1795,48 @@ static void intel_hdmi_destroy(struct drm_connector
*connector)
intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
}
+static void
+intel_hdmi_enable_scrambling(struct drm_connector *connector)
+{
+ struct drm_i915_private *dev_priv = connector->dev->dev_private;
+ struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
+ struct i2c_adapter *adapter =
+ intel_gmbus_get_adapter(dev_priv, intel_hdmi->ddc_bus);
+
+ if (!drm_enable_scrambling(connector, adapter, true))
+ DRM_ERROR("Request to enable scrambling failed\n");
+}
I don't like hiding this somewhere deep like this. It should be
somewhere much higher up.
Why ? All we need to do here is enable two bits in transcoder control
register, which is already being
programmed in a calling function, so I dont see the use case, but I
might be missing some bigger picture.
Can you please elaborate on this ?
We're talking to the display here, which is rather surprising to happen
from a function thing that on the first glance doesn't even seem to
touch the hardware.
I kind of agree with this, and I am also tempted now to shift this call
upwards, but I want to
keep this close to port enabling as well, as the HDMI 2.0 spec says:
"Max time period between a source enables scrambling on monitor, and
starts sending scrambled
video should be 100ms" else the sink might choose to disable scrambling.
Considering this, where do you think would be right place to enabled
scrambling on monitor ?
- Shashank
And I'm thinkign we might want to track the scrambler state
in the crtc state.
Yes, that's a pretty good way to track dynamic status of scrambler, do
you think we should add this in
drm_crtc_state itself ?
I'd just start with intel specific state and later we can see what
everyone else wants to
Re: [Intel-gfx] [PATCH] drm/i915: fix i915 running as dom0 under Xen
On Thu, Feb 02, 2017 at 10:47:11AM +0100, Juergen Gross wrote:
> Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
> disposable private objects") introduced a regression for the kernel
> running as Xen dom0: when switching to graphics mode a GPU HANG
> occurred.
>
> Reason seems to be a missing adaption similar to that done in
> commit 7453c549f5f648 ("swiotlb: Export swiotlb_max_segment to users")
> to i915_gem_object_get_pages_internal().
>
> So limit the maximum page order to be used according to the maximum
> swiotlb segment size instead to the complete swiotlb size.
>
> Signed-off-by: Juergen Gross
Fixes: 920cf4194954 ("drm/i915: Introduce an internal allocator for disposable
private objects")
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-...@lists.freedesktop.org
Cc: # v4.10-rc1+
We have a nice script for these :-)
-Daniel
> ---
> Please consider for 4.10 as otherwise 4.10 will be unusable as Xen dom0
> with i915 graphics.
> ---
> drivers/gpu/drm/i915/i915_gem_internal.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c
> b/drivers/gpu/drm/i915/i915_gem_internal.c
> index 4b3ff3e..d09c749 100644
> --- a/drivers/gpu/drm/i915/i915_gem_internal.c
> +++ b/drivers/gpu/drm/i915/i915_gem_internal.c
> @@ -66,8 +66,16 @@ i915_gem_object_get_pages_internal(struct
> drm_i915_gem_object *obj)
>
> max_order = MAX_ORDER;
> #ifdef CONFIG_SWIOTLB
> - if (swiotlb_nr_tbl()) /* minimum max swiotlb size is IO_TLB_SEGSIZE */
> - max_order = min(max_order, ilog2(IO_TLB_SEGPAGES));
> + if (swiotlb_nr_tbl()) {
> + unsigned int max_segment;
> +
> + max_segment = swiotlb_max_segment();
> + if (max_segment) {
> + max_segment = max_t(unsigned int, max_segment,
> + PAGE_SIZE) >> PAGE_SHIFT;
> + max_order = min(max_order, ilog2(max_segment));
> + }
> + }
> #endif
>
> gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
> --
> 2.10.2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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 2/2] drm: meson: rename driver name to meson-drm
On 02/02/2017 11:45 AM, Daniel Vetter wrote:
> On Thu, Feb 02, 2017 at 10:47:44AM +0100, Neil Armstrong wrote:
>> The platform driver name is currently "meson" which can lead to some
>> confusion, this patch renames it to "meson-drm" and removes the owner
>> attribute.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_drv.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_drv.c
>> b/drivers/gpu/drm/meson/meson_drv.c
>> index ff1f601..380bde7 100644
>> --- a/drivers/gpu/drm/meson/meson_drv.c
>> +++ b/drivers/gpu/drm/meson/meson_drv.c
>> @@ -329,8 +329,7 @@ static int meson_drv_remove(struct platform_device *pdev)
>> .probe = meson_drv_probe,
>> .remove = meson_drv_remove,
>> .driver = {
>> -.owner = THIS_MODULE,
Hi Daniel,
> I don't get why you remove this, generally that will lead to trouble of
> being able to unload code that's still in use ...
Indeed, but since a (long ?) time, the owner field is now populated by the
platform_driver_register() core code.
>
> Otherwise ack.
>
> Now, do you want to get this landed as part of the small drivers in
> drm-mis experiment?
I have a PR ready, but it can go through this experiment, yes.
> -Daniel
>
>> -.name = DRIVER_NAME,
>> +.name = "meson-drm",
>> .of_match_table = dt_match,
>> },
>> };
>> --
Thanks,
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: fix i915 running as dom0 under Xen
On Thu, Feb 02, 2017 at 11:48:21AM +0100, Daniel Vetter wrote:
> On Thu, Feb 02, 2017 at 10:47:11AM +0100, Juergen Gross wrote:
> > Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
> > disposable private objects") introduced a regression for the kernel
> > running as Xen dom0: when switching to graphics mode a GPU HANG
> > occurred.
> >
> > Reason seems to be a missing adaption similar to that done in
> > commit 7453c549f5f648 ("swiotlb: Export swiotlb_max_segment to users")
> > to i915_gem_object_get_pages_internal().
> >
> > So limit the maximum page order to be used according to the maximum
> > swiotlb segment size instead to the complete swiotlb size.
> >
> > Signed-off-by: Juergen Gross
> Fixes: 920cf4194954 ("drm/i915: Introduce an internal allocator for
> disposable private objects")
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: intel-...@lists.freedesktop.org
> Cc: # v4.10-rc1+
>
> We have a nice script for these :-)
Pffifle. 7453c549f5f648 allowed Xen to change it and silently conflicted
with those that already used the previous limits, which didn't land in
our tree until v4.10-rc3.
-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: [Intel-gfx] [PATCH 1/6] drm: Add SCDC helpers
On Wed, 01 Feb 2017, Shashank Sharma wrote:
> From: Thierry Reding
>
> SCDC is a mechanism defined in the HDMI 2.0 specification that allows
> the source and sink devices to communicate.
>
> This commit introduces helpers to access the SCDC and provides the
> symbolic names for the various registers defined in the specification.
>
> Signed-off-by: Thierry Reding
One process note, you need to add your own Signed-off-by under the
original author's sign-off, even when you're posting them unchanged.
Signed-off-by means https://developercertificate.org/
BR,
Jani.
> ---
> Documentation/gpu/drm-kms-helpers.rst | 12
> drivers/gpu/drm/Makefile | 3 +-
> drivers/gpu/drm/drm_scdc_helper.c | 111
> include/drm/drm_scdc_helper.h | 132
> ++
> 4 files changed, 257 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/drm_scdc_helper.c
> create mode 100644 include/drm/drm_scdc_helper.h
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst
> b/Documentation/gpu/drm-kms-helpers.rst
> index 03040aa..7592756 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -217,6 +217,18 @@ EDID Helper Functions Reference
> .. kernel-doc:: drivers/gpu/drm/drm_edid.c
> :export:
>
> +SCDC Helper Functions Reference
> +===
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
> + :doc: scdc helpers
> +
> +.. kernel-doc:: include/drm/drm_scdc_helper.h
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c
> + :export:
> +
> Rectangle Utilities Reference
> =
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 92de399..ad91cd9 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -31,7 +31,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
> drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
> - drm_simple_kms_helper.o drm_modeset_helper.o
> + drm_simple_kms_helper.o drm_modeset_helper.o \
> + drm_scdc_helper.o
>
> drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
> drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
> diff --git a/drivers/gpu/drm/drm_scdc_helper.c
> b/drivers/gpu/drm/drm_scdc_helper.c
> new file mode 100644
> index 000..fe0e121
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_scdc_helper.c
> @@ -0,0 +1,111 @@
> +/*
> + * Copyright (c) 2015 NVIDIA Corporation. All rights reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sub license,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> + * next paragraph) shall be included in all copies or substantial portions
> + * of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> + * DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include
> +
> +#include
> +
> +/**
> + * DOC: scdc helpers
> + *
> + * Status and Control Data Channel (SCDC) is a mechanism introduced by the
> + * HDMI 2.0 specification. It is a point-to-point protocol that allows the
> + * HDMI source and HDMI sink to exchange data. The same I2C interface that
> + * is used to access EDID serves as the transport mechanism for SCDC.
> + */
> +
> +#define SCDC_I2C_SLAVE_ADDRESS 0x54
> +
> +/**
> + * drm_scdc_read - read a block of data from SCDC
> + * @adapter: I2C controller
> + * @offset: start offset of block to read
> + * @buffer: return location for the block to read
> + * @size: size of the block to read
> + *
> + * Reads a block of data from SCDC, starting at a given offset.
> + *
> + * Returns:
> + * The number of bytes read from SCDC or a negative error code on failure.
> + */
> +ssize_t drm_scdc_read(struct i2c_adapter *adapter, u8 offset, void *buffer,
> + size_t size)
> +{
> + struct i2c_msg msgs[2] = {
> + {
> + .addr = SCDC_I2C_SL
[PATCH v4 2/2] drm: kselftest for drm_mm and bottom-up allocation
Check that if we request bottom-up allocation from drm_mm_insert_node()
we receive the next available hole from the bottom.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/selftests/drm_mm_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_mm.c | 100 +++
2 files changed, 101 insertions(+)
diff --git a/drivers/gpu/drm/selftests/drm_mm_selftests.h
b/drivers/gpu/drm/selftests/drm_mm_selftests.h
index 6a4575fdc1c0..37bbdac52896 100644
--- a/drivers/gpu/drm/selftests/drm_mm_selftests.h
+++ b/drivers/gpu/drm/selftests/drm_mm_selftests.h
@@ -17,6 +17,7 @@ selftest(align32, igt_align32)
selftest(align64, igt_align64)
selftest(evict, igt_evict)
selftest(evict_range, igt_evict_range)
+selftest(bottomup, igt_bottomup)
selftest(topdown, igt_topdown)
selftest(color, igt_color)
selftest(color_evict, igt_color_evict)
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
b/drivers/gpu/drm/selftests/test-drm_mm.c
index bb5b7480e0b4..1e71bc182ca9 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -1697,6 +1697,106 @@ static int igt_topdown(void *ignored)
return ret;
}
+static int igt_bottomup(void *ignored)
+{
+ const struct insert_mode *bottomup = &insert_modes[BOTTOMUP];
+ DRM_RND_STATE(prng, random_seed);
+ const unsigned int count = 8192;
+ unsigned int size;
+ unsigned long *bitmap;
+ struct drm_mm mm;
+ struct drm_mm_node *nodes, *node, *next;
+ unsigned int *order, n, m, o = 0;
+ int ret;
+
+ /* Like igt_topdown, but instead of searching for the last hole,
+* we search for the first.
+*/
+
+ ret = -ENOMEM;
+ nodes = vzalloc(count * sizeof(*nodes));
+ if (!nodes)
+ goto err;
+
+ bitmap = kzalloc(count / BITS_PER_LONG * sizeof(unsigned long),
+GFP_TEMPORARY);
+ if (!bitmap)
+ goto err_nodes;
+
+ order = drm_random_order(count, &prng);
+ if (!order)
+ goto err_bitmap;
+
+ ret = -EINVAL;
+ for (size = 1; size <= 64; size <<= 1) {
+ drm_mm_init(&mm, 0, size*count);
+ for (n = 0; n < count; n++) {
+ if (!expect_insert(&mm, &nodes[n],
+ size, 0, n,
+ bottomup)) {
+ pr_err("bottomup insert failed, size %u step
%d\n", size, n);
+ goto out;
+ }
+
+ if (!assert_one_hole(&mm, size*(n + 1), size*count))
+ goto out;
+ }
+
+ if (!assert_continuous(&mm, size))
+ goto out;
+
+ drm_random_reorder(order, count, &prng);
+ for_each_prime_number_from(n, 1, min(count, max_prime)) {
+ for (m = 0; m < n; m++) {
+ node = &nodes[order[(o + m) % count]];
+ drm_mm_remove_node(node);
+ __set_bit(node_index(node), bitmap);
+ }
+
+ for (m = 0; m < n; m++) {
+ unsigned int first;
+
+ node = &nodes[order[(o + m) % count]];
+ if (!expect_insert(&mm, node,
+ size, 0, 0,
+ bottomup)) {
+ pr_err("insert failed, step %d/%d\n",
m, n);
+ goto out;
+ }
+
+ first = find_first_bit(bitmap, count);
+ if (node_index(node) != first) {
+ pr_err("node %d/%d not inserted into
bottom hole, expected %d, found %d\n",
+ m, n, first, node_index(node));
+ goto out;
+ }
+ __clear_bit(first, bitmap);
+ }
+
+ DRM_MM_BUG_ON(find_first_bit(bitmap, count) != count);
+
+ o += n;
+ }
+
+ drm_mm_for_each_node_safe(node, next, &mm)
+ drm_mm_remove_node(node);
+ DRM_MM_BUG_ON(!drm_mm_clean(&mm));
+ }
+
+ ret = 0;
+out:
+ drm_mm_for_each_node_safe(node, next, &mm)
+ drm_mm_remove_node(node);
+ drm_mm_takedown(&mm);
+ kfree(order);
+err_bitmap:
+ kfree(bitmap);
+err_nodes:
+ vfree(nodes);
+err:
+ return ret;
+}
+
static void separate_adjacent_colors(const struct drm_mm_node *node,
unsigned long color,
[PATCH v4 1/2] drm: Improve drm_mm search (and fix topdown allocation) with rbtrees
The drm_mm range manager claimed to support top-down insertion, but it
was neither searching for the top-most hole that could fit the
allocation request nor fitting the request to the hole correctly.
In order to search the range efficiently, we create a secondary index
for the holes using either their size or their address. This index
allows us to find the smallest hole or the hole at the bottom or top of
the range efficiently, whilst keeping the hole stack to rapidly service
evictions.
v2: Search for holes both high and low. Rename flags to mode.
v3: Discover rb_entry_safe() and use it!
v4: Kerneldoc for enum drm_mm_insert_mode.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Russell King
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Rob Clark
Cc: Thierry Reding
Cc: Stephen Warren
Cc: Alexandre Courbot
Cc: Eric Anholt
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 16 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 20 +-
drivers/gpu/drm/armada/armada_gem.c | 4 +-
drivers/gpu/drm/drm_mm.c | 488 +++
drivers/gpu/drm/drm_vma_manager.c| 3 +-
drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 16 +-
drivers/gpu/drm/i915/i915_gem.c | 10 +-
drivers/gpu/drm/i915/i915_gem_evict.c| 9 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 39 +--
drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +-
drivers/gpu/drm/msm/msm_gem.c| 3 +-
drivers/gpu/drm/msm/msm_gem_vma.c| 3 +-
drivers/gpu/drm/selftests/test-drm_mm.c | 58 ++--
drivers/gpu/drm/sis/sis_mm.c | 6 +-
drivers/gpu/drm/tegra/gem.c | 4 +-
drivers/gpu/drm/ttm/ttm_bo_manager.c | 18 +-
drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
drivers/gpu/drm/vc4/vc4_hvs.c| 3 +-
drivers/gpu/drm/vc4/vc4_plane.c | 6 +-
drivers/gpu/drm/via/via_mm.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 10 +-
include/drm/drm_mm.h | 184 +-
23 files changed, 470 insertions(+), 447 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index e4eb6dd3798a..0335c2f331e9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -97,8 +97,7 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
{
struct amdgpu_gtt_mgr *mgr = man->priv;
struct drm_mm_node *node = mem->mm_node;
- enum drm_mm_search_flags sflags = DRM_MM_SEARCH_BEST;
- enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
+ enum drm_mm_insert_mode mode;
unsigned long fpfn, lpfn;
int r;
@@ -115,15 +114,14 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
else
lpfn = man->size;
- if (place && place->flags & TTM_PL_FLAG_TOPDOWN) {
- sflags = DRM_MM_SEARCH_BELOW;
- aflags = DRM_MM_CREATE_TOP;
- }
+ mode = DRM_MM_INSERT_BEST;
+ if (place && place->flags & TTM_PL_FLAG_TOPDOWN)
+ mode = DRM_MM_INSERT_HIGH;
spin_lock(&mgr->lock);
- r = drm_mm_insert_node_in_range_generic(&mgr->mm, node, mem->num_pages,
- mem->page_alignment, 0,
- fpfn, lpfn, sflags, aflags);
+ r = drm_mm_insert_node_in_range(&mgr->mm, node,
+ mem->num_pages, mem->page_alignment, 0,
+ fpfn, lpfn, mode);
spin_unlock(&mgr->lock);
if (!r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index ac9007986c11..9e577e3d3147 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -97,8 +97,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
*man,
struct amdgpu_vram_mgr *mgr = man->priv;
struct drm_mm *mm = &mgr->mm;
struct drm_mm_node *nodes;
- enum drm_mm_search_flags sflags = DRM_MM_SEARCH_DEFAULT;
- enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
+ enum drm_mm_insert_mode mode;
unsigned long lpfn, num_nodes, pages_per_node, pages_left;
unsigned i;
int r;
@@ -121,10 +120,9 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
*man,
if (!nodes)
return -ENOMEM;
- if (place->flags & TTM_PL_FLAG_TOPDOWN) {
- sflags = DRM_MM_SEARCH_BELOW;
- aflags = DRM_MM_CREATE_TOP;
- }
+ mode = DRM_MM_INSERT_BEST;
+
RE: [Intel-gfx] [PATCH 1/6] drm: Add SCDC helpers
Sure, Thanks for the information, will add that in V2. Regards Shashank -Original Message- From: Jani Nikula [mailto:jani.nik...@linux.intel.com] Sent: Thursday, February 2, 2017 4:55 PM To: Sharma, Shashank ; dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org; ville.syrj...@linux.intel.com Cc: jose.ab...@synopsys.com; =daniel.vet...@intel.com; Thierry Reding ; thierry.red...@gmail.com Subject: Re: [Intel-gfx] [PATCH 1/6] drm: Add SCDC helpers On Wed, 01 Feb 2017, Shashank Sharma wrote: > From: Thierry Reding > > SCDC is a mechanism defined in the HDMI 2.0 specification that allows > the source and sink devices to communicate. > > This commit introduces helpers to access the SCDC and provides the > symbolic names for the various registers defined in the specification. > > Signed-off-by: Thierry Reding One process note, you need to add your own Signed-off-by under the original author's sign-off, even when you're posting them unchanged. Signed-off-by means https://developercertificate.org/ BR, Jani. > --- > Documentation/gpu/drm-kms-helpers.rst | 12 > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/drm_scdc_helper.c | 111 > include/drm/drm_scdc_helper.h | 132 > ++ > 4 files changed, 257 insertions(+), 1 deletion(-) create mode 100644 > drivers/gpu/drm/drm_scdc_helper.c create mode 100644 > include/drm/drm_scdc_helper.h > > diff --git a/Documentation/gpu/drm-kms-helpers.rst > b/Documentation/gpu/drm-kms-helpers.rst > index 03040aa..7592756 100644 > --- a/Documentation/gpu/drm-kms-helpers.rst > +++ b/Documentation/gpu/drm-kms-helpers.rst > @@ -217,6 +217,18 @@ EDID Helper Functions Reference .. kernel-doc:: > drivers/gpu/drm/drm_edid.c > :export: > > +SCDC Helper Functions Reference > +=== > + > +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c > + :doc: scdc helpers > + > +.. kernel-doc:: include/drm/drm_scdc_helper.h > + :internal: > + > +.. kernel-doc:: drivers/gpu/drm/drm_scdc_helper.c > + :export: > + > Rectangle Utilities Reference > = > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index > 92de399..ad91cd9 100644 > --- a/drivers/gpu/drm/Makefile > +++ b/drivers/gpu/drm/Makefile > @@ -31,7 +31,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o > drm_debugfs_crc.o drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o > drm_probe_helper.o \ > drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \ > drm_kms_helper_common.o drm_dp_dual_mode_helper.o \ > - drm_simple_kms_helper.o drm_modeset_helper.o > + drm_simple_kms_helper.o drm_modeset_helper.o \ > + drm_scdc_helper.o > > drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o > drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o diff > --git a/drivers/gpu/drm/drm_scdc_helper.c > b/drivers/gpu/drm/drm_scdc_helper.c > new file mode 100644 > index 000..fe0e121 > --- /dev/null > +++ b/drivers/gpu/drm/drm_scdc_helper.c > @@ -0,0 +1,111 @@ > +/* > + * Copyright (c) 2015 NVIDIA Corporation. All rights reserved. > + * > + * Permission is hereby granted, free of charge, to any person > +obtaining a > + * copy of this software and associated documentation files (the > +"Software"), > + * to deal in the Software without restriction, including without > +limitation > + * the rights to use, copy, modify, merge, publish, distribute, sub > +license, > + * and/or sell copies of the Software, and to permit persons to whom > +the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice (including > +the > + * next paragraph) shall be included in all copies or substantial > +portions > + * of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > +EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > +MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT > +SHALL > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES > +OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, > +ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > +OTHER > + * DEALINGS IN THE SOFTWARE. > + */ > + > +#include > + > +#include > + > +/** > + * DOC: scdc helpers > + * > + * Status and Control Data Channel (SCDC) is a mechanism introduced > +by the > + * HDMI 2.0 specification. It is a point-to-point protocol that > +allows the > + * HDMI source and HDMI sink to exchange data. The same I2C interface > +that > + * is used to access EDID serves as the transport mechanism for SCDC. > + */ > + > +#define SCDC_I2C_SLAVE_ADDRESS 0x54 > + > +/** > + * drm_scdc_read - read a block of data from SCDC > + * @
Re: [PATCH 2/2] drm: meson: rename driver name to meson-drm
On Thu, Feb 02, 2017 at 11:50:59AM +0100, Neil Armstrong wrote:
> On 02/02/2017 11:45 AM, Daniel Vetter wrote:
> > On Thu, Feb 02, 2017 at 10:47:44AM +0100, Neil Armstrong wrote:
> >> The platform driver name is currently "meson" which can lead to some
> >> confusion, this patch renames it to "meson-drm" and removes the owner
> >> attribute.
> >>
> >> Signed-off-by: Neil Armstrong
> >> ---
> >> drivers/gpu/drm/meson/meson_drv.c | 3 +--
> >> 1 file changed, 1 insertion(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> >> b/drivers/gpu/drm/meson/meson_drv.c
> >> index ff1f601..380bde7 100644
> >> --- a/drivers/gpu/drm/meson/meson_drv.c
> >> +++ b/drivers/gpu/drm/meson/meson_drv.c
> >> @@ -329,8 +329,7 @@ static int meson_drv_remove(struct platform_device
> >> *pdev)
> >>.probe = meson_drv_probe,
> >>.remove = meson_drv_remove,
> >>.driver = {
> >> - .owner = THIS_MODULE,
>
> Hi Daniel,
>
> > I don't get why you remove this, generally that will lead to trouble of
> > being able to unload code that's still in use ...
>
> Indeed, but since a (long ?) time, the owner field is now populated by the
> platform_driver_register() core code.
>
> >
> > Otherwise ack.
> >
> > Now, do you want to get this landed as part of the small drivers in
> > drm-mis experiment?
>
> I have a PR ready, but it can go through this experiment, yes.
If you want to give it a spin, you need:
- fdo account https://www.freedesktop.org/wiki/AccountRequests/
- drm-misc group access
- dim set up for drm-misc, see
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html and
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html
For questions it's best to pipe up #dri-devel.
Cheers, 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: [Intel-gfx] [PATCH] drm/i915: fix i915 running as dom0 under Xen
On 02/02/2017 09:47, Juergen Gross wrote:
Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
disposable private objects") introduced a regression for the kernel
running as Xen dom0: when switching to graphics mode a GPU HANG
occurred.
Reason seems to be a missing adaption similar to that done in
commit 7453c549f5f648 ("swiotlb: Export swiotlb_max_segment to users")
to i915_gem_object_get_pages_internal().
So limit the maximum page order to be used according to the maximum
swiotlb segment size instead to the complete swiotlb size.
Signed-off-by: Juergen Gross
---
Please consider for 4.10 as otherwise 4.10 will be unusable as Xen dom0
with i915 graphics.
---
drivers/gpu/drm/i915/i915_gem_internal.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c
b/drivers/gpu/drm/i915/i915_gem_internal.c
index 4b3ff3e..d09c749 100644
--- a/drivers/gpu/drm/i915/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/i915_gem_internal.c
@@ -66,8 +66,16 @@ i915_gem_object_get_pages_internal(struct
drm_i915_gem_object *obj)
max_order = MAX_ORDER;
#ifdef CONFIG_SWIOTLB
- if (swiotlb_nr_tbl()) /* minimum max swiotlb size is IO_TLB_SEGSIZE */
- max_order = min(max_order, ilog2(IO_TLB_SEGPAGES));
+ if (swiotlb_nr_tbl()) {
+ unsigned int max_segment;
+
+ max_segment = swiotlb_max_segment();
+ if (max_segment) {
+ max_segment = max_t(unsigned int, max_segment,
+ PAGE_SIZE) >> PAGE_SHIFT;
+ max_order = min(max_order, ilog2(max_segment));
+ }
+ }
#endif
gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
Looks OK to me. We could bikeshed it to only use swiotlb_max_segment()
which I think was the intention when that API was added but can leave
that for the future.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: fix i915 running as dom0 under Xen
On Thu, Feb 02, 2017 at 12:11:29PM +, Tvrtko Ursulin wrote:
>
> On 02/02/2017 09:47, Juergen Gross wrote:
> >Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
> >disposable private objects") introduced a regression for the kernel
> >running as Xen dom0: when switching to graphics mode a GPU HANG
> >occurred.
> >
> >Reason seems to be a missing adaption similar to that done in
> >commit 7453c549f5f648 ("swiotlb: Export swiotlb_max_segment to users")
> >to i915_gem_object_get_pages_internal().
> >
> >So limit the maximum page order to be used according to the maximum
> >swiotlb segment size instead to the complete swiotlb size.
> >
> >Signed-off-by: Juergen Gross
> >---
> >Please consider for 4.10 as otherwise 4.10 will be unusable as Xen dom0
> >with i915 graphics.
> >---
> > drivers/gpu/drm/i915/i915_gem_internal.c | 12 ++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c
> >b/drivers/gpu/drm/i915/i915_gem_internal.c
> >index 4b3ff3e..d09c749 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_internal.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_internal.c
> >@@ -66,8 +66,16 @@ i915_gem_object_get_pages_internal(struct
> >drm_i915_gem_object *obj)
> >
> > max_order = MAX_ORDER;
> > #ifdef CONFIG_SWIOTLB
> >-if (swiotlb_nr_tbl()) /* minimum max swiotlb size is IO_TLB_SEGSIZE */
> >-max_order = min(max_order, ilog2(IO_TLB_SEGPAGES));
> >+if (swiotlb_nr_tbl()) {
> >+unsigned int max_segment;
> >+
> >+max_segment = swiotlb_max_segment();
> >+if (max_segment) {
> >+max_segment = max_t(unsigned int, max_segment,
> >+PAGE_SIZE) >> PAGE_SHIFT;
> >+max_order = min(max_order, ilog2(max_segment));
> >+}
> >+}
> > #endif
> >
> > gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
> >
>
> Looks OK to me. We could bikeshed it to only use
> swiotlb_max_segment() which I think was the intention when that API
> was added but can leave that for the future.
>
> Reviewed-by: Tvrtko Ursulin
Pushed, I imagine this has been added to the list of sg cleanups you
have :)
-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 5/6] drm/i915: enable scrambling
On Thu, Feb 02, 2017 at 04:15:21PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/2/2017 3:32 PM, Ville Syrjälä wrote:
> > On Thu, Feb 02, 2017 at 11:23:19AM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 2/1/2017 10:06 PM, Ville Syrjälä wrote:
> >>> On Wed, Feb 01, 2017 at 06:14:40PM +0530, Shashank Sharma wrote:
> Geminilake platform has a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
>
> This patch checks if the monitor supports scrambling, and if required,
> enables it during the modeset.
>
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> drivers/gpu/drm/i915/intel_ddi.c | 5 +
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> drivers/gpu/drm/i915/intel_hdmi.c | 42
> +++
> 4 files changed, 51 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 495b789..cc85892 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7807,6 +7807,8 @@ enum {
> #define TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12)
> #define TRANS_DDI_DP_VC_PAYLOAD_ALLOC(1<<8)
> #define TRANS_DDI_BFI_ENABLE (1<<4)
> +#define TRANS_DDI_HIGH_TMDS_CHAR_RATE (1<<4)
> +#define TRANS_DDI_HDMI_SCRAMBLING (1<<0)
>
> /* DisplayPort Transport Control */
> #define _DP_TP_CTL_A 0x64040
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 9a9a670..aea81ce 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1278,6 +1278,11 @@ void intel_ddi_enable_transcoder_func(struct
> drm_crtc *crtc)
> temp |= TRANS_DDI_MODE_SELECT_HDMI;
> else
> temp |= TRANS_DDI_MODE_SELECT_DVI;
> +
> +if (IS_GEMINILAKE(dev_priv)) {
> +temp |=
> intel_hdmi_check_scrambling(intel_encoder,
> +
> &intel_crtc->config->base.adjusted_mode);
> +}
> } else if (type == INTEL_OUTPUT_ANALOG) {
> temp |= TRANS_DDI_MODE_SELECT_FDI;
> temp |= (intel_crtc->config->fdi_lanes - 1) << 1;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 393f243..aafce7f 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1588,6 +1588,8 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> bool intel_hdmi_compute_config(struct intel_encoder *encoder,
> struct intel_crtc_state *pipe_config,
> struct drm_connector_state *conn_state);
> +uint32_t intel_hdmi_check_scrambling(struct intel_encoder
> *intel_encoder,
> +struct drm_display_mode *mode);
> void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool
> enable);
>
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index ebae2bd..92dd9bc 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1795,6 +1795,48 @@ static void intel_hdmi_destroy(struct
> drm_connector *connector)
> intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> }
>
> +static void
> +intel_hdmi_enable_scrambling(struct drm_connector *connector)
> +{
> +struct drm_i915_private *dev_priv = connector->dev->dev_private;
> +struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> +struct i2c_adapter *adapter =
> +intel_gmbus_get_adapter(dev_priv,
> intel_hdmi->ddc_bus);
> +
> +if (!drm_enable_scrambling(connector, adapter, true))
> +DRM_ERROR("Request to enable scrambling failed\n");
> +}
> >>> I don't like hiding this somewhere deep like this. It should be
> >>> somewhere much higher up.
> >> Why ? All we need to do here is enable two bits in transcoder control
> >> register, which is already being
> >> programmed in a calling function, so I dont see the use case, but I
> >> might be missing some bigger picture.
> >> Can you please elaborate on this ?
> > We're talking to the display here, which is rather surprising to happen
> > from a function thing that on the fir
Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
Dear Thierry, 2017년 02월 01일 23:44에 Thierry Reding 이(가) 쓴 글: > On Wed, Feb 01, 2017 at 08:48:30AM +0900, Inki Dae wrote: >> >> >> 2017년 02월 01일 06:31에 Thierry Reding 이(가) 쓴 글: >>> On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote: Thierry Reding writes: > [ Unknown signature status ] > On Tue, Jan 31, 2017 at 09:38:53AM -0500, Sean Paul wrote: >> On Tue, Jan 31, 2017 at 09:54:49AM +0100, Thierry Reding wrote: >>> On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote: 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글: > Dear Thierry, > > Could you please review this patch? Thierry, I think this patch has been reviewed enough but no comment from you. Seems you are busy. I will pick up this. >>> >>> Sorry, but that's not how it works. This patch has gone through 8 >>> revisions within 4 weeks, and I tend to ignore patches like that until >>> the dust settles. >>> >> >> Seems like the dust was pretty settled. It was posted on 1/11, pinged on >> 1/24, >> and picked up on 1/31. I don't think it's unreasonable to take it through >> another tree after that. >> >> I wonder if drm_panel would benefit from the -misc group maintainership >> model >> as drm_bridge does. By spreading out the workload, the high-maintenance >> patches would hopefully find someone to shepherd them through. > > Except that nobody except me really cares. If we let people take patches > through separate trees or group-maintained trees they'll likely go in > without too much thought. DRM panel is somewhat different from core DRM > in this regard because its infrastructure is minimal and there's little > outside the panel-simple driver. So we're still at a stage where we need > to fine-tune what drivers should look like and how we can improve. I would love to care and participate in review, but with the structure of your tree you're the only one whose review counts, so I don't participate. >>> >>> Really? What exactly do you think is special about the structure of my >>> tree? I require patches to be on dri-devel (I pick them up from the >>> patchwork instance at freedesktop.org), the tree is publicly available >>> and reviewed-by tags get picked up automatically by patchwork. >>> >>> The panel tree works exactly like any other maintainer tree. And my >>> review is *not* the only one that counts. I appreciate every Reviewed-by >>> tag I see on panel patches because it means that I don't have to look as >>> closely as I have to otherwise. >> >> I don't think the panel tree works exactly like other maintainer tree. >> >> I'd like to recommend you to read below Greg's blog. This blog says >> about *Role of a Linux Kernel Maintainer*. >> http://www.kroah.com/log/linux/maintainer_pledge.html > > Okay, now you're being unfair. You can't compare people to Greg. He > is beyond human. > >> Especially, I'd like to emphasize below things, >> - I will review your patch within 1-2 weeks. >> - I will offer semi-constructive criticism of your patches. >> - I will let you know the status of your patch if it is rejected, or >> if it is accepted, what tree it has gone into, where you can find it, >> and when you can expect to see it merged into Linus's tree. > > First, this is a pledge by Greg, and you can hardly hold me to this if > it isn't coming from me. I agree that the above is ideal, but I'm also > much less efficient as a maintainer as Greg. So are many others. There > simply isn't enough bandwidth to be able to do the above in every case > in addition to the day job and real life. > > That said, when I do get around to review patches I think I'm pretty > good at the second and third points, though. Agree. You did well really. > > Secondly, it's very convenient how you focus on the maintainers' duties > and completely leave out what maintainers expect from contributors. If > you go and read some of the references linked to by Greg's post, maybe > you'll understand my position a little better as well. > >> Why do you ignore contributor's patch? Even though the patch is ugly, >> I think you need to point it out and give your feedback to >> contributers as a maintainer. >> There was some cases I often missed to review with busy work but I >> don't ignore contributor's patch. > > I will admit that ignoring the patch in this instance may not have been > the best course of action. But this particular instance was making it > exceptionally difficult for me, which is why I was going to shunt this > until the next cycle so that I could focus on getting the less tiresome > patches in. > > And interestingly nobody seems to care about this current discussion > either. So yesterday somebody requested another change to the DT binding > after this discussion had started, and after I had NAK'ed the patch, but > then I see that today there's y
[Bug 97861] [amdgpu SI] purple line is visible on left side of the screen connected by HDMI
https://bugs.freedesktop.org/show_bug.cgi?id=97861 --- Comment #4 from Elia Argentieri --- Same problem on R7 370 except that my monitor shows a black screen and reports "frequency not supported". -- 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: [Intel-gfx] [PATCH 2/9] drm/i915: Plumb drm_framebuffer into more places
On Wed, Jan 04, 2017 at 08:42:25PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Now that framebuffers can be used even before calling
> drm_framebuffer_init() we can start to plumb them into more places,
> instead of passing individual pieces for fb metadata.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_display.c | 127
> +++
> drivers/gpu/drm/i915/intel_drv.h | 11 +--
> drivers/gpu/drm/i915/intel_fbdev.c | 4 +-
> 3 files changed, 57 insertions(+), 85 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e2150a64860c..f0cb80aba89a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2050,10 +2050,13 @@ static unsigned int intel_tile_size(const struct
> drm_i915_private *dev_priv)
> return IS_GEN2(dev_priv) ? 2048 : 4096;
> }
>
> -static unsigned int intel_tile_width_bytes(const struct drm_i915_private
> *dev_priv,
> -uint64_t fb_modifier, unsigned int
> cpp)
> +static unsigned int
> +intel_tile_width_bytes(const struct drm_framebuffer *fb, int plane)
> {
> - switch (fb_modifier) {
> + struct drm_i915_private *dev_priv = to_i915(fb->dev);
> + unsigned int cpp = fb->format->cpp[plane];
> +
> + switch (fb->modifier) {
> case DRM_FORMAT_MOD_NONE:
> return cpp;
> case I915_FORMAT_MOD_X_TILED:
> @@ -2082,41 +2085,38 @@ static unsigned int intel_tile_width_bytes(const
> struct drm_i915_private *dev_pr
> }
> break;
> default:
> - MISSING_CASE(fb_modifier);
> + MISSING_CASE(fb->modifier);
> return cpp;
> }
> }
>
> -unsigned int intel_tile_height(const struct drm_i915_private *dev_priv,
> -uint64_t fb_modifier, unsigned int cpp)
> +static unsigned int
> +intel_tile_height(const struct drm_framebuffer *fb, int plane)
> {
> - if (fb_modifier == DRM_FORMAT_MOD_NONE)
> + if (fb->modifier == DRM_FORMAT_MOD_NONE)
> return 1;
> else
> - return intel_tile_size(dev_priv) /
> - intel_tile_width_bytes(dev_priv, fb_modifier, cpp);
> + return intel_tile_size(to_i915(fb->dev)) /
> + intel_tile_width_bytes(fb, plane);
> }
>
> /* Return the tile dimensions in pixel units */
> -static void intel_tile_dims(const struct drm_i915_private *dev_priv,
> +static void intel_tile_dims(const struct drm_framebuffer *fb, int plane,
> unsigned int *tile_width,
> - unsigned int *tile_height,
> - uint64_t fb_modifier,
> - unsigned int cpp)
> + unsigned int *tile_height)
> {
> - unsigned int tile_width_bytes =
> - intel_tile_width_bytes(dev_priv, fb_modifier, cpp);
> + unsigned int tile_width_bytes = intel_tile_width_bytes(fb, plane);
> + unsigned int cpp = fb->format->cpp[plane];
>
> *tile_width = tile_width_bytes / cpp;
> - *tile_height = intel_tile_size(dev_priv) / tile_width_bytes;
> + *tile_height = intel_tile_size(to_i915(fb->dev)) / tile_width_bytes;
> }
>
> unsigned int
> -intel_fb_align_height(struct drm_device *dev, unsigned int height,
> - uint32_t pixel_format, uint64_t fb_modifier)
> +intel_fb_align_height(const struct drm_framebuffer *fb,
> + int plane, unsigned int height)
> {
> - unsigned int cpp = drm_format_plane_cpp(pixel_format, 0);
> - unsigned int tile_height = intel_tile_height(to_i915(dev), fb_modifier,
> cpp);
> + unsigned int tile_height = intel_tile_height(fb, plane);
>
> return ALIGN(height, tile_height);
> }
> @@ -2158,21 +2158,23 @@ static unsigned int intel_linear_alignment(const
> struct drm_i915_private *dev_pr
> return 0;
> }
>
> -static unsigned int intel_surf_alignment(const struct drm_i915_private
> *dev_priv,
> - uint64_t fb_modifier)
> +static unsigned int intel_surf_alignment(const struct drm_framebuffer *fb,
> + int plane)
> {
> - switch (fb_modifier) {
> + struct drm_i915_private *dev_priv = to_i915(fb->dev);
> +
> + switch (fb->modifier) {
> case DRM_FORMAT_MOD_NONE:
> return intel_linear_alignment(dev_priv);
> case I915_FORMAT_MOD_X_TILED:
> - if (INTEL_INFO(dev_priv)->gen >= 9)
> + if (INTEL_GEN(dev_priv) >= 9)
> return 256 * 1024;
> return 0;
> case I915_FORMAT_MOD_Y_TILED:
> case I915_FORMAT_MOD_Yf_TILED:
> return 1 * 1024 * 1024;
> default:
> - MISSING_CASE(fb_modifier);
> + MISSING_CASE(fb->modifier);
>
Re: [PATCH v4 1/2] drm: Improve drm_mm search (and fix topdown allocation) with rbtrees
Am Donnerstag, den 02.02.2017, 11:44 + schrieb Chris Wilson:
> The drm_mm range manager claimed to support top-down insertion, but it
> was neither searching for the top-most hole that could fit the
> allocation request nor fitting the request to the hole correctly.
>
> In order to search the range efficiently, we create a secondary index
> for the holes using either their size or their address. This index
> allows us to find the smallest hole or the hole at the bottom or top of
> the range efficiently, whilst keeping the hole stack to rapidly service
> evictions.
>
> v2: Search for holes both high and low. Rename flags to mode.
> v3: Discover rb_entry_safe() and use it!
> v4: Kerneldoc for enum drm_mm_insert_mode.
>
> Signed-off-by: Chris Wilson
> Reviewed-by: Joonas Lahtinen
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: David Airlie
> Cc: Russell King
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: Lucas Stach
> Cc: Christian Gmeiner
> Cc: Rob Clark
> Cc: Thierry Reding
> Cc: Stephen Warren
> Cc: Alexandre Courbot
> Cc: Eric Anholt
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 16 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 20 +-
> drivers/gpu/drm/armada/armada_gem.c | 4 +-
> drivers/gpu/drm/drm_mm.c | 488
> +++
> drivers/gpu/drm/drm_vma_manager.c| 3 +-
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 16 +-
> drivers/gpu/drm/i915/i915_gem.c | 10 +-
> drivers/gpu/drm/i915/i915_gem_evict.c| 9 +-
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +-
> drivers/gpu/drm/i915/i915_gem_gtt.c | 39 +--
> drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +-
> drivers/gpu/drm/msm/msm_gem.c| 3 +-
> drivers/gpu/drm/msm/msm_gem_vma.c| 3 +-
> drivers/gpu/drm/selftests/test-drm_mm.c | 58 ++--
> drivers/gpu/drm/sis/sis_mm.c | 6 +-
> drivers/gpu/drm/tegra/gem.c | 4 +-
> drivers/gpu/drm/ttm/ttm_bo_manager.c | 18 +-
> drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hvs.c| 3 +-
> drivers/gpu/drm/vc4/vc4_plane.c | 6 +-
> drivers/gpu/drm/via/via_mm.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 10 +-
> include/drm/drm_mm.h | 184 +-
> 23 files changed, 470 insertions(+), 447 deletions(-)
[...]
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> index f503af462dad..004456534e48 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
> @@ -107,6 +107,7 @@ static int etnaviv_iommu_find_iova(struct etnaviv_iommu
> *mmu,
> struct drm_mm_node *node, size_t size)
> {
> struct etnaviv_vram_mapping *free = NULL;
> + enum drm_mm_insert_mode mode = DRM_MM_INSERT_LOW;
> int ret;
>
> lockdep_assert_held(&mmu->lock);
> @@ -117,15 +118,10 @@ static int etnaviv_iommu_find_iova(struct etnaviv_iommu
> *mmu,
> struct list_head list;
> bool found;
>
> - /*
> - * XXX: The DRM_MM_SEARCH_BELOW is really a hack to trick
> - * drm_mm into giving out a low IOVA after address space
> - * rollover. This needs a proper fix.
> - */
> ret = drm_mm_insert_node_in_range(&mmu->mm, node,
> - size, 0, mmu->last_iova, ~0UL,
> - mmu->last_iova ? DRM_MM_SEARCH_DEFAULT :
> DRM_MM_SEARCH_BELOW);
> -
> + size, 0, 0,
> + mmu->last_iova, U64_MAX,
> + mode);
> if (ret != -ENOSPC)
> break;
>
> @@ -140,7 +136,7 @@ static int etnaviv_iommu_find_iova(struct etnaviv_iommu
> *mmu,
> }
>
> /* Try to retire some entries */
> - drm_mm_scan_init(&scan, &mmu->mm, size, 0, 0, 0);
> + drm_mm_scan_init(&scan, &mmu->mm, size, 0, 0, mode);
>
> found = 0;
> INIT_LIST_HEAD(&list);
> @@ -192,6 +188,8 @@ static int etnaviv_iommu_find_iova(struct etnaviv_iommu
> *mmu,
> list_del_init(&m->scan_node);
> }
>
> + mode = DRM_MM_INSERT_EVICT;
> +
> /*
>* We removed enough mappings so that the new allocation will
>* succeed. Ensure that the MMU will be flushed before the
This needs a rebase on the etnaviv for 4.11 pull, that removes the hack
mentioned in the comment above. Otherwise the code change looks fine.
Regards,
Lucas
___
dri-devel mailing list
dri-devel@lists.free
Re: [PATCH 3/9] drm/i915: Move nv12 chroma plane handling into intel_surf_alignment()
On Wed, Jan 04, 2017 at 08:42:26PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Let's try to keep the alignment requirements in one place, and so
> towards that end let's move the AUX_DIST alignment handling into
> intel_surf_alignment() alongside the main surface alignment stuff.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_display.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index f0cb80aba89a..4d514ca1da88 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2163,6 +2163,10 @@ static unsigned int intel_surf_alignment(const struct
> drm_framebuffer *fb,
> {
> struct drm_i915_private *dev_priv = to_i915(fb->dev);
>
> + /* AUX_DIST needs only 4K alignment */
> + if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
> + return 4096;
> +
> switch (fb->modifier) {
> case DRM_FORMAT_MOD_NONE:
> return intel_linear_alignment(dev_priv);
> @@ -2452,13 +2456,7 @@ u32 intel_compute_tile_offset(int *x, int *y,
> const struct drm_framebuffer *fb = state->base.fb;
> unsigned int rotation = state->base.rotation;
> int pitch = intel_fb_pitch(fb, plane, rotation);
> - u32 alignment;
> -
> - /* AUX_DIST needs only 4K alignment */
> - if (fb->format->format == DRM_FORMAT_NV12 && plane == 1)
> - alignment = 4096;
> - else
> - alignment = intel_surf_alignment(fb, plane);
> + u32 alignment = intel_surf_alignment(fb, plane);
>
> return _intel_compute_tile_offset(dev_priv, x, y, fb, plane, pitch,
> rotation, alignment);
> --
> 2.10.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/9] drm/i915: Avoid div-by-zero when computing aux_stride w/o an aux plane
On Wed, Jan 04, 2017 at 08:42:27PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> To make life easier let's allow skl_plane_stride() to be called for the
> AUX surface even when there is no AUX surface. Avoids special cases in
> the callers.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_display.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 4d514ca1da88..bc398743e941 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3261,7 +3261,12 @@ static void skl_detach_scalers(struct intel_crtc
> *intel_crtc)
> u32 skl_plane_stride(const struct drm_framebuffer *fb, int plane,
>unsigned int rotation)
> {
> - u32 stride = intel_fb_pitch(fb, plane, rotation);
> + u32 stride;
> +
> + if (plane >= fb->format->num_planes)
> + return 0;
> +
> + stride = intel_fb_pitch(fb, plane, rotation);
>
> /*
>* The stride is either expressed as a multiple of 64 bytes chunks for
> --
> 2.10.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93341] Semi-random GPU lockups on radeonsi with a RadeonHD 7770 (when playing videos, running OpenGL games, WebGL apps, or after extended periods of time)
https://bugs.freedesktop.org/show_bug.cgi?id=93341 --- Comment #19 from Jean-François Fortin Tam --- What would be the equivalent in the systemd/journalctl world? Apparently Fedora 25 doesn't generate Xorg.log files anymore, the last modification timestamp on that one file is october 10th 2016... -- 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 v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
On Tue, Jan 31, 2017 at 10:51:06PM +0100, Thierry Reding wrote: > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote: > [...] > > As is, I'm stuck out here with my panel driver I submitted on December > > 14th completely ignored, and no other developer will look at it because > > their review doesn't count and only yours does. > > For the record, until earlier today when Daniel started to review your > patches, no doubt in response to this discussion, there was exactly one > response to one of your clock driver patches in the series. > > So can we please stop singling out panel drivers? This is a general > problem that we've had across the kernel, or at least the ARM and > related parts of it, for as long as I can remember. I only looked at that as part of the drm-misc small drivers experiment, to help kickstart a review market. I didn't look at the panel stuff. And the reason I looked at that right now is because right now we started this experiment. That has nothing at all to do with what's going on with drm-panel. If you look at drm-misc, the dsi patches for vc4 have now landed, but the panel driver for the rpi 7" touchscreen hasn't. And Eric had the dsi patches queued in his vc4 tree since a while, just waiting to be sent out in a pull request. We've only gone through the fast review+merging to drm-misc to try out the new process. So not related at all I think. -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 v4 1/2] drm: Improve drm_mm search (and fix topdown allocation) with rbtrees
On Thu, Feb 2, 2017 at 6:44 AM, Chris Wilson wrote:
> The drm_mm range manager claimed to support top-down insertion, but it
> was neither searching for the top-most hole that could fit the
> allocation request nor fitting the request to the hole correctly.
>
> In order to search the range efficiently, we create a secondary index
> for the holes using either their size or their address. This index
> allows us to find the smallest hole or the hole at the bottom or top of
> the range efficiently, whilst keeping the hole stack to rapidly service
> evictions.
>
> v2: Search for holes both high and low. Rename flags to mode.
> v3: Discover rb_entry_safe() and use it!
> v4: Kerneldoc for enum drm_mm_insert_mode.
>
I haven't had drm_mm.c paged into my head in a while, but the patch
appears to do the right thing. The series is:
Reviewed-by: Alex Deucher
> Signed-off-by: Chris Wilson
> Reviewed-by: Joonas Lahtinen
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: David Airlie
> Cc: Russell King
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: Lucas Stach
> Cc: Christian Gmeiner
> Cc: Rob Clark
> Cc: Thierry Reding
> Cc: Stephen Warren
> Cc: Alexandre Courbot
> Cc: Eric Anholt
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 16 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 20 +-
> drivers/gpu/drm/armada/armada_gem.c | 4 +-
> drivers/gpu/drm/drm_mm.c | 488
> +++
> drivers/gpu/drm/drm_vma_manager.c| 3 +-
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 16 +-
> drivers/gpu/drm/i915/i915_gem.c | 10 +-
> drivers/gpu/drm/i915/i915_gem_evict.c| 9 +-
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +-
> drivers/gpu/drm/i915/i915_gem_gtt.c | 39 +--
> drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +-
> drivers/gpu/drm/msm/msm_gem.c| 3 +-
> drivers/gpu/drm/msm/msm_gem_vma.c| 3 +-
> drivers/gpu/drm/selftests/test-drm_mm.c | 58 ++--
> drivers/gpu/drm/sis/sis_mm.c | 6 +-
> drivers/gpu/drm/tegra/gem.c | 4 +-
> drivers/gpu/drm/ttm/ttm_bo_manager.c | 18 +-
> drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hvs.c| 3 +-
> drivers/gpu/drm/vc4/vc4_plane.c | 6 +-
> drivers/gpu/drm/via/via_mm.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 10 +-
> include/drm/drm_mm.h | 184 +-
> 23 files changed, 470 insertions(+), 447 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> index e4eb6dd3798a..0335c2f331e9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> @@ -97,8 +97,7 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
> {
> struct amdgpu_gtt_mgr *mgr = man->priv;
> struct drm_mm_node *node = mem->mm_node;
> - enum drm_mm_search_flags sflags = DRM_MM_SEARCH_BEST;
> - enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
> + enum drm_mm_insert_mode mode;
> unsigned long fpfn, lpfn;
> int r;
>
> @@ -115,15 +114,14 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager
> *man,
> else
> lpfn = man->size;
>
> - if (place && place->flags & TTM_PL_FLAG_TOPDOWN) {
> - sflags = DRM_MM_SEARCH_BELOW;
> - aflags = DRM_MM_CREATE_TOP;
> - }
> + mode = DRM_MM_INSERT_BEST;
> + if (place && place->flags & TTM_PL_FLAG_TOPDOWN)
> + mode = DRM_MM_INSERT_HIGH;
>
> spin_lock(&mgr->lock);
> - r = drm_mm_insert_node_in_range_generic(&mgr->mm, node,
> mem->num_pages,
> - mem->page_alignment, 0,
> - fpfn, lpfn, sflags, aflags);
> + r = drm_mm_insert_node_in_range(&mgr->mm, node,
> + mem->num_pages, mem->page_alignment,
> 0,
> + fpfn, lpfn, mode);
> spin_unlock(&mgr->lock);
>
> if (!r) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> index ac9007986c11..9e577e3d3147 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> @@ -97,8 +97,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
> *man,
> struct amdgpu_vram_mgr *mgr = man->priv;
> struct drm_mm *mm = &mgr->mm;
> struct drm_mm_node *nodes;
> - enum drm_mm_search_flags sflags = DRM_MM_SEARCH_DEFAULT;
> - enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
> + enum drm_mm_insert_mode mode;
> unsigned long
[Bug 193651] Amdgpu error messages at boot with Amd RX460
https://bugzilla.kernel.org/show_bug.cgi?id=193651 --- Comment #10 from Steven A. Falco --- Thanks for the information on building a new kernel. I'll give that a try. I'm running Fedora 25, but I think I can follow your Debian instructions. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 5/9] drm/i915: Fix Yf tile width
On Wed, Jan 04, 2017 at 08:42:28PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Based on empirical evidence the display engine (at least) always
> treats Yf tiles as 128Bx32. Currently we're assuming the tile dimensions
> change based on the pixel format. Let's adjust our code to match the
> hardware.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
BSpec "Address Tiling Function Introduction/Linear vs Tiled Storage":
"""
Note that the dimensions of tiles are irrespective of the data contained
within – e.g., a tile can hold twice as many 16-bit pixels (256
pixels/row x 8 rows = 2K pixels) than 32-bit pixels (128 pixels/row x 8
rows = 1K pixels).
"""
"Tile-Yf Format":
"""
The 64 Byte block is always 4-high. Width (in pixels) is defined by bpp.
"""
Then it continues to specify the different tile aspect ratios for
different bpps which contradict the above. This aspect ratio definition
is what matches the current code. Filing a BSpec issue for this would be
good.
> ---
> drivers/gpu/drm/i915/intel_display.c | 20 ++--
> 1 file changed, 6 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index bc398743e941..0ca0dbccc005 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2070,20 +2070,12 @@ intel_tile_width_bytes(const struct drm_framebuffer
> *fb, int plane)
> else
> return 512;
> case I915_FORMAT_MOD_Yf_TILED:
> - switch (cpp) {
> - case 1:
> - return 64;
> - case 2:
> - case 4:
> - return 128;
> - case 8:
> - case 16:
> - return 256;
> - default:
> - MISSING_CASE(cpp);
> - return cpp;
> - }
> - break;
> + /*
> + * Bspec seems to suggest that the Yf tile width would
> + * depend on the cpp. In reality it doesn't, at least
> + * as far as the display engine is concerned.
> + */
> + return 128;
> default:
> MISSING_CASE(fb->modifier);
> return cpp;
> --
> 2.10.2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v4 1/2] drm: Improve drm_mm search (and fix topdown allocation) with rbtrees
On Thu, Feb 02, 2017 at 02:33:54PM +0100, Lucas Stach wrote: > Am Donnerstag, den 02.02.2017, 11:44 + schrieb Chris Wilson: > > @@ -192,6 +188,8 @@ static int etnaviv_iommu_find_iova(struct etnaviv_iommu > > *mmu, > > list_del_init(&m->scan_node); > > } > > > > + mode = DRM_MM_INSERT_EVICT; > > + > > /* > > * We removed enough mappings so that the new allocation will > > * succeed. Ensure that the MMU will be flushed before the > > This needs a rebase on the etnaviv for 4.11 pull, that removes the hack > mentioned in the comment above. Otherwise the code change looks fine. Is that pull request already on the list and/or in drm-next? Chris' patch fell a bit through the cracks, but since it's fairly big I'd like to get it into 4.11 still if possible, instead of keeping it in drm-misc for a few weeks to route around the merge window blackout ... Otherwise I guess 4.12 it is, but I'll still push it into drm-misc-next next week if possible (we have drm-misc-next-fixes for bugfixes for the merge window, to be able to keep merging feature work). -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
[Bug 99549] pp: Failed to translate a shader
https://bugs.freedesktop.org/show_bug.cgi?id=99549 --- Comment #2 from LoneVVolf --- After seeing marek reply I experimented a bit with PP_DEBUG and post processing filters. Half of the error messages comes from pp_jimenezmlaa filter , the other half from pp_jimenezmlaa_color . disabling those filters through driconf does make the corresponding error messages disappear. The error messages started recently, want me to try bisecting to find out what caused them ? -- 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 v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
On Tue, 31 Jan 2017, Thierry Reding wrote: > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote: >> I would love for drm-panel to be moved under -misc. > > Like that's going to magically motivate people to spend their time > reviewing other patches. The only thing that group maintainership adds > is redundancy. Adding redundancy is not an insignificant thing. I think it can be quite liberating to not have everything and everybody depend on you. You can defer to others when you're busy, tired, sick, whatever. Things still move on. And I don't think redundancy is the only thing that group maintainership adds. You'll have maintainers that complement each other, with different skill sets and abilities and experience. They don't all look at the same things. As maintainers tend to be more senior folks, I find sharing the load of the more mundane tasks of maintainership free up their time to contribute more of their technical skills to the project, for example review. It's just my personal view on i915, but I think people take more responsibility of their own work, instead of just sending patches and waiting for stuff to happen, when they have commit access. But you have to trust the people. I didn't intend for this to become a kind of sales pitch, but I do think drm-panel would be a good fit for drm-misc. Personally I think it's your call, but I think you should think about it. (And that decision should, obviously, be made calmly, independent of any particular patch series.) BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] topic/vma-fix-for-4.10
Hi Dave, here's Maarten's backport of the vma fixes for v4.10. BR, Jani. The following changes since commit 566cf877a1fcb6d6dc0126b076aad062054c2637: Linux 4.10-rc6 (2017-01-29 14:25:17 -0800) are available in the git repository at: git://anongit.freedesktop.org/git/drm-intel tags/topic/vma-fix-for-4.10-2017-02-02 for you to fetch changes up to e8fe4f4b2b7b93048729538321c681c0cff33b39: drm/i915: Track pinned vma in intel_plane_state (2017-02-01 11:45:21 +0200) Chris Wilson (1): drm/i915: Track pinned vma in intel_plane_state Maarten Lankhorst (1): drm/atomic: Unconditionally call prepare_fb. drivers/gpu/drm/drm_atomic_helper.c | 9 --- drivers/gpu/drm/i915/i915_drv.h | 16 +--- drivers/gpu/drm/i915/intel_atomic_plane.c | 20 + drivers/gpu/drm/i915/intel_display.c | 125 ++ drivers/gpu/drm/i915/intel_drv.h | 9 ++- drivers/gpu/drm/i915/intel_fbc.c | 52 + drivers/gpu/drm/i915/intel_fbdev.c| 4 +- drivers/gpu/drm/i915/intel_sprite.c | 8 +- 8 files changed, 99 insertions(+), 144 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
Re: [PATCH 1/2] drm: sti: Prevent race on fbdev initialization
Gabriel Krisman Bertazi writes:
> Scheduling the output_poll_work before calling bind_all to create the
> crtcs can race the fbdev initialization with the components
> initialization (i.e. crtc initialization). One side effect is that we
> may call drm_fbdev_cma_init with a zeroed num_crtc value, crashing the
> fbdev allocation.
This is no longer true after
8953e9ee0ce5 ("drm/sti: create fbdev at binding") # drm-misc-next.
That commit moved the fbdev initialization out of the output_poll_work,
forcing it to happen after creating crtcs, so this patch is no longer
necessary. I'll resend a v2 of the series without it.
--
Gabriel Krisman Bertazi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 193651] Amdgpu error messages at boot with Amd RX460
https://bugzilla.kernel.org/show_bug.cgi?id=193651 --- Comment #11 from Alex Deucher --- (In reply to fin4478 from comment #8) > Alex, thanks for the new firmware. Still Bios recognition errors at boot, > but otherwise ok. > > [3.461112] [drm] BIOS signature incorrect 20 7 > [3.461117] amdgpu :01:00.0: Invalid PCI ROM header signature: > expecting 0xaa55, got 0x > This is harmless. The driver tries several methods to fetch the vbios image. The driver would not load at all if it failed to fetch the vbios image. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/9] drm/i915: Pass the correct plane index to _intel_compute_tile_offset()
On Wed, Jan 04, 2017 at 08:42:29PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > intel_fill_fb_info() should pass the correct plane index to > _intel_compute_tile_offset() once we start to care about the AUX > surface. > > Signed-off-by: Ville Syrjälä This changes how x/y and offset is calculated already now for planes with a cpp different than that of plane 0, but the end result remains the same: Reviewed-by: Imre Deak > --- > drivers/gpu/drm/i915/intel_display.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 0ca0dbccc005..5fee5a7ac9a4 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -2525,7 +2525,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv, > intel_fb->normal[i].y = y; > > offset = _intel_compute_tile_offset(dev_priv, &x, &y, > - fb, 0, fb->pitches[i], > + fb, i, fb->pitches[i], > DRM_ROTATE_0, tile_size); > offset /= tile_size; > > -- > 2.10.2 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99549] pp: Failed to translate a shader
https://bugs.freedesktop.org/show_bug.cgi?id=99549 --- Comment #3 from Marek Olšák --- That's up to you. I'm not so into fixing the postprocessing, because the options shouldn't be put into drirc, because the filters change what the OpenGL spec specifies. -- 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: [Intel-gfx] [PATCH 7/9] drm/i915: Use DRM_DEBUG_KMS() for framebuffer failure debug messages
On Wed, Jan 04, 2017 at 08:42:30PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> DRM_UT_CORE generates way too much noise usually, so having the
> framebuffer init failures use DRM_UT_CORE is a pain when trying to
> find out the reason why you failed in creating a framebuffer.
> Let's use DRM_UT_KMS for these debug messages instead.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 66
> ++--
> 1 file changed, 33 insertions(+), 33 deletions(-)
> [...]
> @@ -15940,17 +15940,17 @@ static int intel_framebuffer_init(struct drm_device
> *dev,
>*/
> if (INTEL_INFO(dev_priv)->gen < 4 &&
> tiling != intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
> - DRM_DEBUG("tiling_mode must match fb modifier exactly on
> gen2/3\n");
> + DRM_DEBUG_KMS("tiling_mode must match fb modifier exactly on
> gen2/3\n");
> return -EINVAL;
> }
>
> pitch_limit = intel_fb_pitch_limit(dev_priv, mode_cmd->modifier[0],
> mode_cmd->pixel_format);
> if (mode_cmd->pitches[0] > pitch_limit) {
> - DRM_DEBUG("%s pitch (%u) must be at less than %d\n",
> - mode_cmd->modifier[0] != DRM_FORMAT_MOD_NONE ?
> - "tiled" : "linear",
> - mode_cmd->pitches[0], pitch_limit);
> + DRM_DEBUG_KMS("%s pitch (%u) must be at less than %d\n",
While at it: s/at less than/at most/
Reviewed-by: Imre Deak
> + mode_cmd->modifier[0] != DRM_FORMAT_MOD_NONE ?
> + "tiled" : "linear",
> + mode_cmd->pitches[0], pitch_limit);
> return -EINVAL;
> }
>
> @@ -15960,9 +15960,9 @@ static int intel_framebuffer_init(struct drm_device
> *dev,
>*/
> if (tiling != I915_TILING_NONE &&
> mode_cmd->pitches[0] != i915_gem_object_get_stride(obj)) {
> - DRM_DEBUG("pitch (%d) must match tiling stride (%d)\n",
> - mode_cmd->pitches[0],
> - i915_gem_object_get_stride(obj));
> + DRM_DEBUG_KMS("pitch (%d) must match tiling stride (%d)\n",
> + mode_cmd->pitches[0],
> + i915_gem_object_get_stride(obj));
> return -EINVAL;
> }
>
> @@ -15975,16 +15975,16 @@ static int intel_framebuffer_init(struct drm_device
> *dev,
> break;
> case DRM_FORMAT_XRGB1555:
> if (INTEL_GEN(dev_priv) > 3) {
> - DRM_DEBUG("unsupported pixel format: %s\n",
> - drm_get_format_name(mode_cmd->pixel_format,
> &format_name));
> + DRM_DEBUG_KMS("unsupported pixel format: %s\n",
> +
> drm_get_format_name(mode_cmd->pixel_format, &format_name));
> return -EINVAL;
> }
> break;
> case DRM_FORMAT_ABGR:
> if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv) &&
> INTEL_GEN(dev_priv) < 9) {
> - DRM_DEBUG("unsupported pixel format: %s\n",
> - drm_get_format_name(mode_cmd->pixel_format,
> &format_name));
> + DRM_DEBUG_KMS("unsupported pixel format: %s\n",
> +
> drm_get_format_name(mode_cmd->pixel_format, &format_name));
> return -EINVAL;
> }
> break;
> @@ -15992,15 +15992,15 @@ static int intel_framebuffer_init(struct drm_device
> *dev,
> case DRM_FORMAT_XRGB2101010:
> case DRM_FORMAT_XBGR2101010:
> if (INTEL_GEN(dev_priv) < 4) {
> - DRM_DEBUG("unsupported pixel format: %s\n",
> - drm_get_format_name(mode_cmd->pixel_format,
> &format_name));
> + DRM_DEBUG_KMS("unsupported pixel format: %s\n",
> +
> drm_get_format_name(mode_cmd->pixel_format, &format_name));
> return -EINVAL;
> }
> break;
> case DRM_FORMAT_ABGR2101010:
> if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv)) {
> - DRM_DEBUG("unsupported pixel format: %s\n",
> - drm_get_format_name(mode_cmd->pixel_format,
> &format_name));
> + DRM_DEBUG_KMS("unsupported pixel format: %s\n",
> +
> drm_get_format_name(mode_cmd->pixel_format, &format_name));
> return -EINVAL;
> }
> break;
> @@ -16009,14 +16009,14 @@ static int intel_framebuffer_init(struct drm_device
> *dev,
> case DRM_FORMAT_YVYU:
> case DRM_FORMAT_VYUY:
> if (INTEL_GEN(dev_priv) < 5) {
> -
[PATCH v2] drm: Rely on mode_config data for fb_helper initialization
Instead of receiving the num_crts as a parameter, we can read it
directly from the mode_config structure. I audited the drivers that
invoke this helper and I believe all of them initialize the mode_config
struct accordingly, prior to calling the fb_helper.
I used the following coccinelle hack to make this transformation, except
for the function headers and comment updates. The first and second
rules are split because I couldn't find a way to remove the unused
temporary variables at the same time I removed the parameter.
//
@r@
expression A,B,D,E;
identifier C;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)
@@
expression A,B,C,D,E;
@@
(
- drm_fb_helper_init(A,B,C,D)
+ drm_fb_helper_init(A,B,D)
|
- drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
+ drm_fbdev_cma_init_with_funcs(A,B,D,E)
|
- drm_fbdev_cma_init(A,B,C,D)
+ drm_fbdev_cma_init(A,B,D)
)
@@
identifier r.C;
type T;
expression V;
@@
- T C;
<...
when != C
- C = V;
...>
//
Changes since v1:
- Rebased on top of the tip of drm-misc-next.
- Remove mention to sti since a proper fix got merged.
Suggested-by: Daniel Vetter
Signed-off-by: Gabriel Krisman Bertazi
Reviewed-by: Eric Anholt
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 1 -
drivers/gpu/drm/arc/arcpgu_drv.c | 3 +--
drivers/gpu/drm/arm/hdlcd_drv.c | 2 +-
drivers/gpu/drm/arm/malidp_drv.c | 2 +-
drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c | 3 +--
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 -
drivers/gpu/drm/bochs/bochs_fbdev.c | 3 +--
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
drivers/gpu/drm/drm_fb_cma_helper.c | 15 +++
drivers/gpu/drm/drm_fb_helper.c | 10 +-
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 5 +
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +-
drivers/gpu/drm/gma500/framebuffer.c | 2 +-
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 3 +--
drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 3 +--
drivers/gpu/drm/i915/intel_fbdev.c| 3 +--
drivers/gpu/drm/imx/imx-drm-core.c| 3 +--
drivers/gpu/drm/meson/meson_drv.c | 1 -
drivers/gpu/drm/mgag200/mgag200_fb.c | 2 +-
drivers/gpu/drm/msm/msm_fbdev.c | 3 +--
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 3 +--
drivers/gpu/drm/omapdrm/omap_fbdev.c | 3 +--
drivers/gpu/drm/qxl/qxl_fb.c | 1 -
drivers/gpu/drm/radeon/radeon_fb.c| 1 -
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 5 +
drivers/gpu/drm/sti/sti_drv.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 4 +---
drivers/gpu/drm/tegra/fb.c| 2 +-
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +--
drivers/gpu/drm/udl/udl_fb.c | 3 +--
drivers/gpu/drm/vc4/vc4_kms.c | 1 -
drivers/gpu/drm/virtio/virtgpu_fb.c | 1 -
drivers/gpu/drm/zte/zx_drm_drv.c | 2 +-
include/drm/drm_fb_cma_helper.h | 7 +++
include/drm/drm_fb_helper.h | 3 +--
38 files changed, 43 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
index 838943d0962e..36ce3cac81ba 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
@@ -374,7 +374,6 @@ int amdgpu_fbdev_init(struct amdgpu_device *adev)
&amdgpu_fb_helper_funcs);
ret = drm_fb_helper_init(adev->ddev, &rfbdev->helper,
-adev->mode_info.num_crtc,
AMDGPUFB_CONN_LIMIT);
if (ret) {
kfree(rfbdev);
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 0b6eaa49a1db..8d8344ed655e 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -135,8 +135,7 @@ static int arcpgu_load(struct drm_device *drm)
drm_kms_helper_poll_init(drm);
arcpgu->fbdev = drm_fbdev_cma_init(drm, 16,
- drm->mode_config.num_crtc,
- drm->mode_config.num_connector);
+ drm->mode_config.num_connector);
if (IS_ERR(arcpgu->fbdev)) {
ret = PTR_ERR(arcpgu->fbdev);
arcpgu->fbdev = NULL;
diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/g
mmap with PROT_WRITE of dma-buf FD coming from eglExportDMABUFImageMESA
Hi,
I'm currently trying to mmap the memory of an OpenGL texture I've
created by
doing the following:
std::vector image_attribs = {
EGL_WIDTH, static_cast(m_texWidth & 0x7FFF),
EGL_HEIGHT, static_cast(m_texHeight & 0x7FFF),
EGL_DRM_BUFFER_USE_MESA, EGL_DRM_BUFFER_USE_SCANOUT_MESA,
EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_FORMAT_ARGB32_MESA
EGL_NONE
};
glGenTextures( 1, &texID );
glBindTexture( GL_TEXTURE_2D, texID );
eglImage = eglCreateDRMImageMESA( eglGetCurrentDisplay(),
&image_attribs[0] );
glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, eglmage);
eglExportDMABUFImageQueryMESA(eglGetCurrentDisplay(), eglImage, &fourcc,
&nplanes, &modifiers)
eglExportDMABUFImageMESA(eglGetCurrentDisplay(), eglImage, &fd, strides,
offsets)
struct dma_buf_sync sync_args = { .flags = DMA_BUF_SYNC_START };
ioctl( fd, DMA_BUF_IOCTL_SYNC, sync_args);
mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0 );
For some reason mmap returns MAP_FAILED when using the PROT_WRITE flag,
while
using only PROT_READ seems to be fine. I'm currently using kernel 4.9.6
on an Intel CherryTrail (i915).
Is there an obvious reason why I'm not able to mmap the texture FD with
PROT_WRITE flags?
Reading https://01.org/blogs/2016/sharing-cpu-and-gpu-buffers-linux I
would have guessed that
this should be possible. Or is it only true for specific GEM buffers not
textures created using
eglCreateDRMImageMESA?
Regards,
Volker
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93341] Semi-random GPU lockups on radeonsi with a RadeonHD 7770 (when playing videos, running OpenGL games, WebGL apps, or after extended periods of time)
https://bugs.freedesktop.org/show_bug.cgi?id=93341 --- Comment #20 from Alex Deucher --- (In reply to Jean-François Fortin Tam from comment #19) > What would be the equivalent in the systemd/journalctl world? Apparently > Fedora 25 doesn't generate Xorg.log files anymore, the last modification > timestamp on that one file is october 10th 2016... See this page for how to access the xorg log output on various versions of fedora: https://fedoraproject.org/wiki/How_to_debug_Xorg_problems -- 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: mmap with PROT_WRITE of dma-buf FD coming from eglExportDMABUFImageMESA
On Thu, Feb 02, 2017 at 05:19:58PM +0100, Volker Vogelhuber wrote:
> Hi,
>
> I'm currently trying to mmap the memory of an OpenGL texture I've created by
> doing the following:
>
> std::vector image_attribs = {
> EGL_WIDTH, static_cast(m_texWidth & 0x7FFF),
> EGL_HEIGHT, static_cast(m_texHeight & 0x7FFF),
> EGL_DRM_BUFFER_USE_MESA, EGL_DRM_BUFFER_USE_SCANOUT_MESA,
> EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_FORMAT_ARGB32_MESA
> EGL_NONE
> };
> glGenTextures( 1, &texID );
> glBindTexture( GL_TEXTURE_2D, texID );
> eglImage = eglCreateDRMImageMESA( eglGetCurrentDisplay(), &image_attribs[0]
> );
> glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, eglmage);
> eglExportDMABUFImageQueryMESA(eglGetCurrentDisplay(), eglImage, &fourcc,
> &nplanes, &modifiers)
> eglExportDMABUFImageMESA(eglGetCurrentDisplay(), eglImage, &fd, strides,
> offsets)
>
> struct dma_buf_sync sync_args = { .flags = DMA_BUF_SYNC_START };
> ioctl( fd, DMA_BUF_IOCTL_SYNC, sync_args);
> mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0 );
>
> For some reason mmap returns MAP_FAILED when using the PROT_WRITE flag,
> while
> using only PROT_READ seems to be fine. I'm currently using kernel 4.9.6 on
> an Intel CherryTrail (i915).
>
> Is there an obvious reason why I'm not able to mmap the texture FD with
> PROT_WRITE flags?
> Reading https://01.org/blogs/2016/sharing-cpu-and-gpu-buffers-linux I would
> have guessed that
> this should be possible. Or is it only true for specific GEM buffers not
> textures created using
> eglCreateDRMImageMESA?
From a quick look the mesa/libdrm (depending upon driver) handle2fd
implementations don't set the DRM_RDWR flag when asking PRIME for a
dma-buf fd, which means you fd doesn't have write permissions. Which means
mmap with writing allowed will fail.
Not sure how to fix that.
-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 v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
On Thu, Feb 02, 2017 at 05:30:34PM +0200, Jani Nikula wrote: > On Tue, 31 Jan 2017, Thierry Reding wrote: > > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote: > >> I would love for drm-panel to be moved under -misc. > > > > Like that's going to magically motivate people to spend their time > > reviewing other patches. The only thing that group maintainership adds > > is redundancy. > > Adding redundancy is not an insignificant thing. I think it can be quite > liberating to not have everything and everybody depend on you. You can > defer to others when you're busy, tired, sick, whatever. Things still > move on. Oh, I certainly see the advantages in sharing maintainership. However, I think it really only works well if you've got active developers working together on the code already. Then it's very natural to let all of them manage a tree. But for drm-panel, I've rarely seen anyone review patches. Sometimes the easy patches (i.e. panel-simple) get reviewed by parties that have some interest in seeing the patches merged. However, there's usually no review at all for the more complicated patches. Given that, I doubt that group maintainership is going to have the desired effect. Just because the tree is group maintained doesn't mean that all of a sudden people are going to care about the patches. So I suspect that even if panel drivers were managed in drm-misc, I'd still be the only person reviewing the patches. And really, managing a tree is peanuts compared to the amount of work it takes to properly review code. With group maintainership, for this type of tree in particular, I think it's likely for the quality bar to be lowered. There aren't any best practices yet for anything beyond panel-simple, and therefore little to no review is likely going to make people still pick up patches. This is quite different to the DRM/KMS core bits and drivers because there are established best practices and people can usually spot when new code is not living up to expectations. > And I don't think redundancy is the only thing that group maintainership > adds. You'll have maintainers that complement each other, with different > skill sets and abilities and experience. They don't all look at the same > things. As maintainers tend to be more senior folks, I find sharing the > load of the more mundane tasks of maintainership free up their time to > contribute more of their technical skills to the project, for example > review. I don't understand why group maintainership would be necessary for this. Surely people will review code irrespective of who finally applies their patch. If they don't in a single maintainer project, why would they suddenly start reviewing code in group maintained projects? > It's just my personal view on i915, but I think people take more > responsibility of their own work, instead of just sending patches and > waiting for stuff to happen, when they have commit access. But you have > to trust the people. That's not something that we're discussing here. Surely giving the world access to the maintainer trees is not a goal that we're pursuing here. It will still only be a handful of selected people that will have commit access, so how's that going to change things for contributors that don't have commit access? The bottom line still is that we have a requirement to have patches reviewed before they get applied. So even if everybody had commit access we'd still need someone to review a patch before it gets applied. Like I said, reviewing is really the difficult part of a maintainer's job. Applying a patch is trivial, build-testing is equally trivial and so is sending out a pull request. All of the above can be easily automated to a point where it's completely painless. > I didn't intend for this to become a kind of sales pitch, but I do think > drm-panel would be a good fit for drm-misc. Personally I think it's your > call, but I think you should think about it. (And that decision should, > obviously, be made calmly, independent of any particular patch series.) You know what? I completely agree with you that drm-panel would be a good fit for drm-misc. It's effectively part of the DRM/KMS core and used by most drivers. But it's never been treated that way. Maybe it is because it's been maintained in a separate tree from the very beginning, perhaps that was a mistake in the first place. Then again, back when drm-panel was started we didn't have group maintainership, so none of the existing trees would've been a good fit. In the end, I keep getting back to the question that everybody except me seems to know the answer to: why would there be a difference in how contributors behave depending on the number of maintainers? Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 1/3] drm/atomic: Save flip flags in drm_crtct_state
On Wed, Feb 1, 2017 at 12:03 PM, Andrey Grodzovsky
wrote:
> Allows using atomic flip helpers for drivers
> using ASYNC flip.
> Remove ASYNC_FLIP restriction in helpers and
> caches the page flip flags in drm_crtc_state
> to be used in the low level drivers.
>
> v2:
> Resending the patch since the original was broken.
>
> v3:
> Save flag in crtc_state instead of plane_state
>
> v4:
> Reset the flag before using again.
>
> Change-Id: I0219c3ec3ecceb82143ee176d30cb50d9aa76bf0
> Signed-off-by: Andrey Grodzovsky
typo in the patch title:
drm_crtct_state
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 20 ++--
> include/drm/drm_crtc.h | 9 -
> include/drm/drm_plane.h | 1 +
> 3 files changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index a4e5477..f84b5aa 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2737,7 +2737,8 @@ static int page_flip_common(
> struct drm_atomic_state *state,
> struct drm_crtc *crtc,
> struct drm_framebuffer *fb,
> - struct drm_pending_vblank_event *event)
> + struct drm_pending_vblank_event *event,
> + uint32_t flags)
> {
> struct drm_plane *plane = crtc->primary;
> struct drm_plane_state *plane_state;
> @@ -2749,12 +2750,12 @@ static int page_flip_common(
> return PTR_ERR(crtc_state);
>
> crtc_state->event = event;
> + crtc_state->pflip_flags = flags;
>
> plane_state = drm_atomic_get_plane_state(state, plane);
> if (IS_ERR(plane_state))
> return PTR_ERR(plane_state);
>
> -
> ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
> if (ret != 0)
> return ret;
> @@ -2781,10 +2782,6 @@ static int page_flip_common(
> * Provides a default &drm_crtc_funcs.page_flip implementation
> * using the atomic driver interface.
> *
> - * Note that for now so called async page flips (i.e. updates which are not
> - * synchronized to vblank) are not supported, since the atomic interfaces
> have
> - * no provisions for this yet.
> - *
> * Returns:
> * Returns 0 on success, negative errno numbers on failure.
> *
> @@ -2800,9 +2797,6 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> struct drm_atomic_state *state;
> int ret = 0;
>
> - if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> - return -EINVAL;
> -
> state = drm_atomic_state_alloc(plane->dev);
> if (!state)
> return -ENOMEM;
> @@ -2810,7 +2804,7 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
> state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
>
> retry:
> - ret = page_flip_common(state, crtc, fb, event);
> + ret = page_flip_common(state, crtc, fb, event, flags);
> if (ret != 0)
> goto fail;
>
> @@ -2865,9 +2859,6 @@ int drm_atomic_helper_page_flip_target(
> struct drm_crtc_state *crtc_state;
> int ret = 0;
>
> - if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
> - return -EINVAL;
> -
> state = drm_atomic_state_alloc(plane->dev);
> if (!state)
> return -ENOMEM;
> @@ -2875,7 +2866,7 @@ int drm_atomic_helper_page_flip_target(
> state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
>
> retry:
> - ret = page_flip_common(state, crtc, fb, event);
> + ret = page_flip_common(state, crtc, fb, event, flags);
> if (ret != 0)
> goto fail;
>
> @@ -3072,6 +3063,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
> drm_crtc *crtc,
> state->color_mgmt_changed = false;
> state->zpos_changed = false;
> state->event = NULL;
> + state->pflip_flags = 0;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state);
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 5c77c3f..b74dbe1 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -162,10 +162,17 @@ struct drm_crtc_state {
> * Target vertical blank period when a page flip
> * should take effect.
> */
> -
> u32 target_vblank;
>
> /**
> +* @pflip_flags:
> +*
> +* DRM_MODE_PAGE_FLIP_* flags, as passed to the page flip ioctl.
> +* Zero in any other case.
> +*/
> + u32 pflip_flags;
I can go either way on whether we call this pflip or page_flip. I
guess it's better to spell it out.
> +
> + /**
> * @event:
> *
> * Optional pointer to a DRM event to signal upon completion of the
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index db3bbde..57414ae 100644
> --- a/include/dr
Re: [PATCH v4 0/3] Allow ASYNC flip with atomic helpers.
On Wed, Feb 1, 2017 at 12:03 PM, Andrey Grodzovsky wrote: > This series is a folow-up on > https://patchwork.kernel.org/patch/9501787/ > > The first patch makes changes to atomic helpers to allow for drives with > ASYNC flip support to use them. > Patch 2 is to use this in AMDGPU/DC. > Patch 3 is possible cleanup in nouveau/kms who seems to have to duplicate the > helper as we did to support ASYNC flips. > > v2: > Resend drm/atomic: Save flip flags in drm_plane_state since the original > patch was incomplete. > Squash 2 AMD changes into one to not break compilation. > > v3: > Following Daniel's comments, save flip flags in crtc_state instead of > plane_state. > > v4: > Lauren's comment, reset flp flags before using again. > Harry's comment, fix identation in amd/display. > > Andrey Grodzovsky (3): > drm/atomic: Save flip flags in drm_crtct_state > drm/nouveau/kms/nv50: Switch to using atomic helper for flip. > drm/amd/display: Switch to using atomic_helper for flip. A few comments on patch 1. WIth those addressed the series is: Reviewed-by: Alex Deucher > > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 - > .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 113 > + > drivers/gpu/drm/drm_atomic_helper.c| 20 ++-- > drivers/gpu/drm/nouveau/nv50_display.c | 84 ++- > include/drm/drm_crtc.h | 9 +- > include/drm/drm_plane.h| 1 + > 6 files changed, 49 insertions(+), 179 deletions(-) > > -- > 1.9.1 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] radeon and amdgpu drm-fixes-4.10
Hi Dave, Just a couple of small fixes for 4.10 The following changes since commit 52b679f60e2a68af88411f12318675a2424a0e14: Merge tag 'drm-misc-fixes-2017-01-31' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes (2017-02-01 08:45:27 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.10 for you to fetch changes up to 51964e9e12d0a054002a1a0d1dec4f661c7aaf28: drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl (2017-02-02 11:14:09 -0500) Alex Deucher (1): drm/amdgpu/si: fix crash on headless asics Michel Dänzer (1): drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 4 +++- drivers/gpu/drm/radeon/radeon_drv.c | 3 ++- drivers/gpu/drm/radeon/radeon_gem.c | 4 ++-- 3 files changed, 7 insertions(+), 4 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
Daniel Vetter writes: > On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote: >> Jani Nikula writes: >> >> > On Tue, 31 Jan 2017, Eric Anholt wrote: >> >> Martin Peres writes: >> >> >> >>> Despite all the careful planing of the kernel, a link may become >> >>> insufficient to handle the currently-set mode. At this point, the >> >>> kernel should mark this particular configuration as being broken >> >>> and potentially prune the mode before setting the offending connector's >> >>> link-status to BAD and send the userspace a hotplug event. This may >> >>> happen right after a modeset or later on. >> >>> >> >>> When available, we should use the link-status information to reset >> >>> the wanted mode. >> >>> >> >>> Signed-off-by: Martin Peres >> >> >> >> If I understand this right, there are two failure modes being handled: >> >> >> >> 1) A mode that won't actually work because the link isn't good enough. >> >> >> >> 2) A mode that should work, but link parameters were too optimistic and >> >> if we just ask the kernel to set the mode again it'll use more >> >> conservative parameters that work. >> >> >> >> This patch seems good for 2). For 1), the drmmode_set_mode_major is >> >> going to set our old mode back. Won't the modeset then fail to link >> >> train again, and bring us back into this loop? The only escape that I >> >> see would be some other userspace responding to the advertised mode list >> >> changing, and then asking X to modeset to something new. >> >> >> >> To avoid that failure busy loop, should we re-fetching modes at this >> >> point, and only re-setting if our mode still exists? >> > >> > Disclaimer: I don't know anything about the internals of the modesetting >> > driver. >> > >> > Perhaps we can identify the two cases now, but I'd put this more >> > generally: if the link status has gone bad, it's an indicator to >> > userspace that the circumstances may have changed, and userspace should >> > query the kernel for the list of available modes again. It should no >> > longer trust information obtained prior to getting the bad link status, >> > including the current mode. >> > >> > But specifically, I think you're right, and AFAICT asking for the list >> > of modes again is the only way for the userspace to distinguish between >> > the two cases. I don't think there's a shortcut for deciding the current >> > mode is still valid. >> >> To avoid the busy-loop problem, I think I'd like this patch to re-query >> the kernel to ask about the current mode list, and only try to re-set >> the mode if our mode is still there. > > Yeah, I guess that sounds like a reasonable heuristics. More integrated > compositors (aka the wayland ones) might be able to make more useful > decisions, but for -modesetting that's probably the best we can do. > >> If the mode isn't there, then it's up to the DE to take action in >> response to the notification of new modes. If you don't have a DE to >> take appropriate action, you're kind of out of luck. >> >> As far as the ABI goes, this seems fine to me. The only concern I had >> about ABI was having to walk all the connectors on every uevent to see >> if any had gone bad -- couldn't we have a flag of some sort about what >> the uevent indicates? But uevents should be super rare, so I'd say the >> kernel could go ahead with the current plan. > > We've discussed finer-grained uevent singalling a few times, and I'd like > that to be an orthogonal abi extension. Right now we just don't have the > required tracking even within the kernel to know which connector changed > (and the tracking we do have missed a few things, too). My idea is to push > the tracking into the leaves of the callchains with a function that > increases some per-connector epoch counter. Then we'd just have to expose > that somehow cheaply to userspace (could probably just send it along in > the uevent). Plus expose it as a read-only property so that userspace can > re-synchronize. > > But again, that should be an orthogonal thing imo. Yeah, that was roughly my thought process, too. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
On Tue, Jan 31, 2017 at 01:05:20PM +0100, Andrzej Hajda wrote: > On 31.01.2017 09:54, Thierry Reding wrote: > > On Tue, Jan 31, 2017 at 09:01:07AM +0900, Inki Dae wrote: > >> > >> 2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글: > >>> Dear Thierry, > >>> > >>> Could you please review this patch? > >> Thierry, I think this patch has been reviewed enough but no comment > >> from you. Seems you are busy. I will pick up this. > > Sorry, but that's not how it works. This patch has gone through 8 > > revisions within 4 weeks, and I tend to ignore patches like that until > > the dust settles. > > > > Other than that, this continues the same madness that I've repeatedly > > complained about in the past. The whole mechanism of running through a > > series of writes and not caring about errors until the very end is > > something we've discussed at length in the past. > > Yes, we have discussed the pattern, but without any conclusion. The > pattern is correct, used in different places in kernel (see below for > examples) and significantly decreases source code size. Disallowing it > in panels subsystem just because of personal preferences of the > maintainer does not seem to be proper. > > > It also in large parts > > duplicates a bunch of functions from other Samsung panel drivers that I > > already said should eventually be moved to something saner. > > Currently there are two Samsung panel drivers, one is on SPI bus, > another one is on DSI. > I am (co-)author of both drivers, they have some similarities but I did > not see any gain in making additional abstractions over transport layer > just to make one or two small functions common. > Could you be more precise what are you talking about, or could you give > a link to the mail where you said it. Anything I remember was a > discussion about ugly magic initialization sequences due to poor > documentation. > > And below promised examples of the error pattern, it was time consuming > to find them, so please at least read them :) I've done better, below is what I hope a list of good arguments why the pattern is a bad idea, and why in some cases it can be justified. > Almost exactly the same patterns for the same purpose: > > 1. http://lxr.free-electrons.com/source/drivers/net/ieee802154/atusb.c#L63 > Citation from the code: > To reduce the number of error checks in the code, we record the > first error > in atusb->err and reject all subsequent requests until the error is > cleared. That's about the worst example you could've used. Have you even looked at the code that uses this? It's completely crazy. So here we have the atusb_control_msg() function that stores this error, but then also propagates it to its caller. One of these callers is atusb_read_reg(), which also propagates the error or returns the register value if the read was successful. Now the really insane part is how this is then used in something like atusb_write_subreg(): orig = atusb_read_reg(atusb, reg); tmp = orig & ~mask; tmp |= (value << shift) & mask; if (tmp != orig) ret = atusb_write_reg(atusb, reg, tmp); So let's assume that atusb_control_msg() fails in the call to atusb_read_reg(). You'll be returning an error code, mask out some bits, OR in new ones and write the result to the register. So not only does the code not bother to check for errors, but it will also happily go and corrupt registers when an error has occurred while reading. > 2. http://lxr.free-electrons.com/source/drivers/md/dm-thin.c?v=4.4#L917 This is completely different from the panel driver because it's used to store a value from within callbacks that can't return one. > 3. http://lxr.free-electrons.com/source/net/9p/trans_fd.c?v=3.18#L297 Essentially the same thing. > 4. > http://lxr.free-electrons.com/source/drivers/media/v4l2-core/v4l2-ctrls.c#L2234 Looks like this could be replaced by the more idiomatic use of ERR_PTR() encoding error codes. But the most significant difference here is that each use of the handler_set_err() function is followed by a return. So instead of ignoring errors like you do in the panel drivers, this does recognize them and aborts early, rather than trying to go through the remainder of the code, irrespective of how small the chances are of it succeeding. Or ignoring that /even if/ the remainder didn't fail, the one operation that fail might have been essential to the operation of the device. > 5. http://lxr.free-electrons.com/source/drivers/media/i2c/s5k5baf.c#L451 That's a particularly good example of why you shouldn't be doing this kind of thing. Consider what would happen in these cases if for example there was a problem with the I2C interface. There's a bunch of read and write sequences in that driver that go completely without checking for errors. Imagine how that will look to a user when the communication to a chip doesn't work. They'll get a load of error messages all saying that communication timed out, or th
Re: [PATCH 3/6] drm/edid: detect SCDC support in HF-VSDB
On Thu, Feb 02, 2017 at 10:58:43AM +0530, Sharma, Shashank wrote:
> Thanks for the review Thierry. My comments inline.
>
> Regards
> Shashank
> On 2/1/2017 9:40 PM, Thierry Reding wrote:
> > On Wed, Feb 01, 2017 at 06:14:38PM +0530, Shashank Sharma wrote:
> > > This patch does following:
> > > - Adds a new structure (drm_hdmi_info) in drm_display_info.
> > >This structure will be used to save and indicate if sink
> > >supports advance HDMI 2.0 features
> > "advanced"
> got it.
> >
> > > - Checks the HF-VSDB block for presence of SCDC, and marks it
> > >in hdmi_info structure.
> > "drm_hdmi_info structure"?
> yep, sure.
> > > - If SCDC is present, checks if sink is capable of generating
> > >scdc read request, and marks it in hdmi_info structure.
> > "SCDC" to be consistent and because it's an abbreviation.
> Agree.
> > > Signed-off-by: Shashank Sharma
> > > ---
> > > drivers/gpu/drm/drm_edid.c | 14 ++
> > > include/drm/drm_connector.h | 26 ++
> > > 2 files changed, 40 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index 96d3e47..37902e5 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -3802,6 +3802,18 @@ enum hdmi_quantization_range
> > > }
> > > EXPORT_SYMBOL(drm_default_rgb_quant_range);
> > > +static void drm_detect_hdmi_scdc(struct drm_connector *connector,
> > > + const u8 *hf_vsdb)
> > > +{
> > > + struct drm_hdmi_info *hdmi = &connector->display_info.hdmi_info;
> > > +
> > > + if (hf_vsdb[6] & 0x80) {
> > > + hdmi->scdc_supported = true;
> > > + if (hf_vsdb[6] & 0x40)
> > > + hdmi->scdc_rr = true;
> > > + }
> > > +}
> > > +
> > > static void drm_parse_hdmi_deep_color_info(struct drm_connector
> > > *connector,
> > > const u8 *hdmi)
> > > {
> > > @@ -3916,6 +3928,8 @@ static void drm_parse_cea_ext(struct drm_connector
> > > *connector,
> > > if (cea_db_is_hdmi_vsdb(db))
> > > drm_parse_hdmi_vsdb_video(connector, db);
> > > + if (cea_db_is_hdmi_forum_vsdb(db))
> > > + drm_detect_hdmi_scdc(connector, db);
> > > }
> > > }
> > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > index e5e1edd..2435598 100644
> > > --- a/include/drm/drm_connector.h
> > > +++ b/include/drm/drm_connector.h
> > > @@ -87,6 +87,27 @@ enum subpixel_order {
> > > SubPixelVerticalRGB,
> > > SubPixelVerticalBGR,
> > > SubPixelNone,
> > > +
> > > +};
> > > +
> > > +/**
> > > + * struct drm_hdmi_info - runtime data about the connected sink
> > Maybe "connected HDMI sink"?
> Agree.
> > > + *
> > > + * Describes if a given hdmi display supports advance HDMI 2.0 featutes.
> > "HDMI", "advanced", "features"
> Oops, got it :-)
> > > + * This information is available in CEA-861-F extension blocks (like
> > > + * HF-VSDB)
> > This should be terminated by a full-stop.
> Ok
> > > + * For sinks which provide an EDID this can be filled out by calling
> > > + * drm_add_edid_modes().
> > And maybe make this sentence start right after the one above rather than
> > breaking it to the next line.
> Ok
> > I'm not sure how useful this line is. Most
> > driver will be calling drm_add_edid_modes() anyway, but the above makes
> > it sound like drm_add_edid_modes() is something you have to explicitly
> > call to get these fields parsed.
> Mostly a 'yy' and 'p' from the function above, but makes sense, I can remove
> this line.
> > > + */
> > > +struct drm_hdmi_info {
> > > + /**
> > > + * @scdc_supported: status control & data channel present.
> > > + */
> > > + bool scdc_supported;
> > > + /**
> > > + * @scdc_rr: sink is capable of generating scdc read request.
> > > + */
> > > + bool scdc_rr;
> > > };
> > > /**
> > > @@ -188,6 +209,11 @@ struct drm_display_info {
> > >* @cea_rev: CEA revision of the HDMI sink.
> > >*/
> > > u8 cea_rev;
> > > +
> > > + /**
> > > + * @hdmi_info: advance features of a HDMI sink.
> > > + */
> > > + struct drm_hdmi_info hdmi_info;
> > I think we can safely drop the _info suffix on the field name. It's
> > already inside a structure that carries this suffix.
> Sure, should I call it hdmi_sink OR connected_hdmi ?
No, I think just plain "hdmi" would be fine. This is part of
drm_display_info, which kind of implies that it's a sink, and I think
it's also fair to assume that this isn't valid if nothing's connected.
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm: Rely on mode_config data for fb_helper initialization
On Thu, Feb 02, 2017 at 02:26:40PM -0200, Gabriel Krisman Bertazi wrote:
> Instead of receiving the num_crts as a parameter, we can read it
> directly from the mode_config structure. I audited the drivers that
> invoke this helper and I believe all of them initialize the mode_config
> struct accordingly, prior to calling the fb_helper.
>
> I used the following coccinelle hack to make this transformation, except
> for the function headers and comment updates. The first and second
> rules are split because I couldn't find a way to remove the unused
> temporary variables at the same time I removed the parameter.
>
> //
> @r@
> expression A,B,D,E;
> identifier C;
> @@
> (
> - drm_fb_helper_init(A,B,C,D)
> + drm_fb_helper_init(A,B,D)
> |
> - drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
> + drm_fbdev_cma_init_with_funcs(A,B,D,E)
> |
> - drm_fbdev_cma_init(A,B,C,D)
> + drm_fbdev_cma_init(A,B,D)
> )
>
> @@
> expression A,B,C,D,E;
> @@
> (
> - drm_fb_helper_init(A,B,C,D)
> + drm_fb_helper_init(A,B,D)
> |
> - drm_fbdev_cma_init_with_funcs(A,B,C,D,E)
> + drm_fbdev_cma_init_with_funcs(A,B,D,E)
> |
> - drm_fbdev_cma_init(A,B,C,D)
> + drm_fbdev_cma_init(A,B,D)
> )
>
> @@
> identifier r.C;
> type T;
> expression V;
> @@
> - T C;
> <...
> when != C
> - C = V;
> ...>
> //
>
> Changes since v1:
> - Rebased on top of the tip of drm-misc-next.
> - Remove mention to sti since a proper fix got merged.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Gabriel Krisman Bertazi
> Reviewed-by: Eric Anholt
Yup, this applied cleanly, thanks for respinning.
-Daniel
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c| 1 -
> drivers/gpu/drm/arc/arcpgu_drv.c | 3 +--
> drivers/gpu/drm/arm/hdlcd_drv.c | 2 +-
> drivers/gpu/drm/arm/malidp_drv.c | 2 +-
> drivers/gpu/drm/armada/armada_fbdev.c | 2 +-
> drivers/gpu/drm/ast/ast_fb.c | 3 +--
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 1 -
> drivers/gpu/drm/bochs/bochs_fbdev.c | 3 +--
> drivers/gpu/drm/cirrus/cirrus_fbdev.c | 2 +-
> drivers/gpu/drm/drm_fb_cma_helper.c | 15 +++
> drivers/gpu/drm/drm_fb_helper.c | 10 +-
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 5 +
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 2 +-
> drivers/gpu/drm/gma500/framebuffer.c | 2 +-
> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 3 +--
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 3 +--
> drivers/gpu/drm/i915/intel_fbdev.c| 3 +--
> drivers/gpu/drm/imx/imx-drm-core.c| 3 +--
> drivers/gpu/drm/meson/meson_drv.c | 1 -
> drivers/gpu/drm/mgag200/mgag200_fb.c | 2 +-
> drivers/gpu/drm/msm/msm_fbdev.c | 3 +--
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +-
> drivers/gpu/drm/nouveau/nouveau_fbcon.c | 3 +--
> drivers/gpu/drm/omapdrm/omap_fbdev.c | 3 +--
> drivers/gpu/drm/qxl/qxl_fb.c | 1 -
> drivers/gpu/drm/radeon/radeon_fb.c| 1 -
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
> drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 5 +
> drivers/gpu/drm/sti/sti_drv.c | 2 +-
> drivers/gpu/drm/sun4i/sun4i_framebuffer.c | 4 +---
> drivers/gpu/drm/tegra/fb.c| 2 +-
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 3 +--
> drivers/gpu/drm/udl/udl_fb.c | 3 +--
> drivers/gpu/drm/vc4/vc4_kms.c | 1 -
> drivers/gpu/drm/virtio/virtgpu_fb.c | 1 -
> drivers/gpu/drm/zte/zx_drm_drv.c | 2 +-
> include/drm/drm_fb_cma_helper.h | 7 +++
> include/drm/drm_fb_helper.h | 3 +--
> 38 files changed, 43 insertions(+), 73 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> index 838943d0962e..36ce3cac81ba 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
> @@ -374,7 +374,6 @@ int amdgpu_fbdev_init(struct amdgpu_device *adev)
> &amdgpu_fb_helper_funcs);
>
> ret = drm_fb_helper_init(adev->ddev, &rfbdev->helper,
> - adev->mode_info.num_crtc,
>AMDGPUFB_CONN_LIMIT);
> if (ret) {
> kfree(rfbdev);
> diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c
> b/drivers/gpu/drm/arc/arcpgu_drv.c
> index 0b6eaa49a1db..8d8344ed655e 100644
> --- a/drivers/gpu/drm/arc/arcpgu_drv.c
> +++ b/drivers/gpu/drm/arc/arcpgu_drv.c
> @@ -135,8 +135,7 @@ static int arcpgu_load(struct drm_device *drm)
> drm_kms_helper_poll_init(drm);
>
> arcpgu->fbdev = drm_fbdev_cma_init(drm, 16,
> -
Re: drm: panel-simple: Problems to use Seiko 43WVF1G panel and DRM_MXS driver on the i.MX6SX SabreSD.
On Wed, Feb 1, 2017 at 2:04 PM, Breno Matheus Lima wrote: > - The image is displaced even when using the same timing values in > the datasheet. Managed to fix this framebuffer displacement problem. Will submit a patch soon. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm: scrambling support in drm layer
On Thu, Feb 02, 2017 at 11:08:22AM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 2/1/2017 10:02 PM, Thierry Reding wrote:
> > On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote:
> > > HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
> > > than 340Mhz. This patch adds few new functions in drm layer for
> > > core drivers to enable/disable scrambling.
> > >
> > > This patch adds:
> > > - A function to detect scrambling support parsing HF-VSDB
> > > - A function to check scrambling status runtime using SCDC read.
> > > - Two functions to enable/disable scrambling using SCDC read/write.
> > > - Few new bools to reflect scrambling support and status.
> > >
> > > Signed-off-by: Shashank Sharma
> > > ---
> > > drivers/gpu/drm/drm_edid.c | 131
> > > +++-
> > > include/drm/drm_connector.h | 24
> > > include/drm/drm_edid.h | 6 +-
> > > 3 files changed, 159 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > > index 37902e5..f0d940a 100644
> > > --- a/drivers/gpu/drm/drm_edid.c
> > > +++ b/drivers/gpu/drm/drm_edid.c
> > > @@ -37,6 +37,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #define version_greater(edid, maj, min) \
> > > (((edid)->version > (maj)) || \
> > > @@ -3814,6 +3815,132 @@ static void drm_detect_hdmi_scdc(struct
> > > drm_connector *connector,
> > > }
> > > }
> > > +static void drm_detect_hdmi_scrambling(struct drm_connector *connector,
> > > + const u8 *hf_vsdb)
> > > +{
> > > + struct drm_display_info *display = &connector->display_info;
> > > + struct drm_hdmi_info *hdmi = &display->hdmi_info;
> > > +
> > > + /*
> > > + * All HDMI 2.0 monitors must support scrambling at rates > 340M.
> > In comments below you use Mhz as the abbreviations. This should be
> > consistent. Also I think "MHz" is actually the correct spelling.
> Agree.
> > > + * And as per the spec, three factors confirm this:
> > > + * * Availability of a HF-VSDB block in EDID (check)
> > > + * * Non zero Max_TMDS_Char_Rate filed in HF-VSDB
> > > + * * SCDC support available
> > > + * Lets check it out.
> > > + */
> > > +
> > > + if (hf_vsdb[5]) {
> > > + display->max_tmds_clock = hf_vsdb[5] * 5000;
> > > + DRM_DEBUG_KMS("HF-VSDB: max TMDS clock %d kHz\n",
> > > + display->max_tmds_clock);
> > > +
> > > + if (hdmi->scdc_supported) {
> > > + hdmi->scr_info.supported = true;
> > > +
> > > + /* Few sinks support scrambling for cloks < 340M */
> > > + if ((hf_vsdb[6] & 0x8))
> > > + hdmi->scr_info.low_clocks = true;
> > > + }
> > > + }
> > > +}
> > > +
> > > +/**
> > > + * drm_check_scrambling_status - what is status of scrambling?
> > > + * @adapter: i2c adapter for SCDC channel
> > "I2C", same in other parts of this patch.
> Got it.
> > > + *
> > > + * Read the scrambler status over SCDC channel, and check the
> > > + * scrambling status.
> > > + *
> > > + * Return: True if the scrambling is enabled, false otherwise.
> > I think the rest of DRM/KMS kerneldoc tries to use "Returns:\n" as a
> > standard way to document return values.
> Ok.
> > > + */
> > > +
> > > +bool drm_check_scrambling_status(struct i2c_adapter *adapter)
> > Maybe use a drm_scdc_*() prefix for this to make it more consistent with
> > other SCDC API.
> >
> > While at it, would this not be better located in drm_scdc.c along with
> > the other helpers? drm_edid.c is more focussed on the parsing aspects of
> > all things EDID.
> Yeah, the same is mentioned by Ville too, will do that.
> > > +{
> > > + u8 status;
> > > +
> > > + if (drm_scdc_readb(adapter, SCDC_SCRAMBLER_STATUS, &status) < 0) {
> > How about storing the error code...
> >
> > > + DRM_ERROR("Failed to read scrambling status\n");
> > ... and making it part of the error message? Sometimes its useful to
> > know what exact error triggered this because it helps narrowing down
> > where things went wrong.
> Agree, in fact while debugging and testing this patch series, I had to print
> it explicitly.
> >
> > > + return false;
> > > + }
> > > +
> > > + status &= SCDC_SCRAMBLING_STATUS;
> > > + return status != 0;
> > Maybe make this a single line:
> >
> > return (status & SCDC_SCRAMBLING_STATUS) != 0;
> Got it.
> >
> > > +}
> > > +
> > > +/**
> > > + * drm_enable_scrambling - enable scrambling
> > > + * @connector: target drm_connector
> > "target DRM connector"?
> Got it.
> > > + * @adapter: i2c adapter for SCDC channel
> > > + * @force: enable scrambling, even if its already enabled
> > > + *
> > > + * Write the TMDS config over SCDC channel, and enable scrambling
> > > + * Return: True if scrambling is successfully enabled, false otherwise.
> > > + */
> > > +
> > > +bool drm_enable_scrambling(struct
Re: [PATCH v4 1/2] drm: Improve drm_mm search (and fix topdown allocation) with rbtrees
vmwgfx part: Reviewed-by: Sinclair Yeh
On Thu, Feb 02, 2017 at 11:44:33AM +, Chris Wilson wrote:
> The drm_mm range manager claimed to support top-down insertion, but it
> was neither searching for the top-most hole that could fit the
> allocation request nor fitting the request to the hole correctly.
>
> In order to search the range efficiently, we create a secondary index
> for the holes using either their size or their address. This index
> allows us to find the smallest hole or the hole at the bottom or top of
> the range efficiently, whilst keeping the hole stack to rapidly service
> evictions.
>
> v2: Search for holes both high and low. Rename flags to mode.
> v3: Discover rb_entry_safe() and use it!
> v4: Kerneldoc for enum drm_mm_insert_mode.
>
> Signed-off-by: Chris Wilson
> Reviewed-by: Joonas Lahtinen
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: David Airlie
> Cc: Russell King
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: Lucas Stach
> Cc: Christian Gmeiner
> Cc: Rob Clark
> Cc: Thierry Reding
> Cc: Stephen Warren
> Cc: Alexandre Courbot
> Cc: Eric Anholt
> Cc: Sinclair Yeh
> Cc: Thomas Hellstrom
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 16 +-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 20 +-
> drivers/gpu/drm/armada/armada_gem.c | 4 +-
> drivers/gpu/drm/drm_mm.c | 488
> +++
> drivers/gpu/drm/drm_vma_manager.c| 3 +-
> drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 16 +-
> drivers/gpu/drm/i915/i915_gem.c | 10 +-
> drivers/gpu/drm/i915/i915_gem_evict.c| 9 +-
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +-
> drivers/gpu/drm/i915/i915_gem_gtt.c | 39 +--
> drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +-
> drivers/gpu/drm/msm/msm_gem.c| 3 +-
> drivers/gpu/drm/msm/msm_gem_vma.c| 3 +-
> drivers/gpu/drm/selftests/test-drm_mm.c | 58 ++--
> drivers/gpu/drm/sis/sis_mm.c | 6 +-
> drivers/gpu/drm/tegra/gem.c | 4 +-
> drivers/gpu/drm/ttm/ttm_bo_manager.c | 18 +-
> drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hvs.c| 3 +-
> drivers/gpu/drm/vc4/vc4_plane.c | 6 +-
> drivers/gpu/drm/via/via_mm.c | 4 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 10 +-
> include/drm/drm_mm.h | 184 +-
> 23 files changed, 470 insertions(+), 447 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> index e4eb6dd3798a..0335c2f331e9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> @@ -97,8 +97,7 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
> {
> struct amdgpu_gtt_mgr *mgr = man->priv;
> struct drm_mm_node *node = mem->mm_node;
> - enum drm_mm_search_flags sflags = DRM_MM_SEARCH_BEST;
> - enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
> + enum drm_mm_insert_mode mode;
> unsigned long fpfn, lpfn;
> int r;
>
> @@ -115,15 +114,14 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager
> *man,
> else
> lpfn = man->size;
>
> - if (place && place->flags & TTM_PL_FLAG_TOPDOWN) {
> - sflags = DRM_MM_SEARCH_BELOW;
> - aflags = DRM_MM_CREATE_TOP;
> - }
> + mode = DRM_MM_INSERT_BEST;
> + if (place && place->flags & TTM_PL_FLAG_TOPDOWN)
> + mode = DRM_MM_INSERT_HIGH;
>
> spin_lock(&mgr->lock);
> - r = drm_mm_insert_node_in_range_generic(&mgr->mm, node, mem->num_pages,
> - mem->page_alignment, 0,
> - fpfn, lpfn, sflags, aflags);
> + r = drm_mm_insert_node_in_range(&mgr->mm, node,
> + mem->num_pages, mem->page_alignment, 0,
> + fpfn, lpfn, mode);
> spin_unlock(&mgr->lock);
>
> if (!r) {
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> index ac9007986c11..9e577e3d3147 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
> @@ -97,8 +97,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
> *man,
> struct amdgpu_vram_mgr *mgr = man->priv;
> struct drm_mm *mm = &mgr->mm;
> struct drm_mm_node *nodes;
> - enum drm_mm_search_flags sflags = DRM_MM_SEARCH_DEFAULT;
> - enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
> + enum drm_mm_insert_mode mode;
> unsigned long lpfn, num_nodes, pages_per_node, pages_left;
> unsigned i;
> int r;
> @@ -121,10 +120,9 @@ static int amdgpu_vram_mgr_new(struct
> ttm_me
[drm-tip:drm-tip 1066/1073] drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:376:8: error: too few arguments to function 'drm_fb_helper_init'
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 36aab92fa2091dd54ea983752aa40e427e83d113
commit: e4563f6ba71792c77aeccb2092cc23149b44e642 [1066/1073] drm: Rely on
mode_config data for fb_helper initialization
config: i386-randconfig-x007-201705 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout e4563f6ba71792c77aeccb2092cc23149b44e642
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c: In function 'amdgpu_fbdev_init':
>> drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:376:8: error: too few arguments to
>> function 'drm_fb_helper_init'
ret = drm_fb_helper_init(adev->ddev, &rfbdev->helper,
^~
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h:39:0,
from drivers/gpu/drm/amd/amdgpu/amdgpu.h:50,
from drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c:34:
include/drm/drm_fb_helper.h:309:19: note: declared here
static inline int drm_fb_helper_init(struct drm_device *dev,
^~
vim +/drm_fb_helper_init +376 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c
d38ceaf9 Alex Deucher 2015-04-20 370 rfbdev->adev = adev;
d38ceaf9 Alex Deucher 2015-04-20 371 adev->mode_info.rfbdev = rfbdev;
d38ceaf9 Alex Deucher 2015-04-20 372
d38ceaf9 Alex Deucher 2015-04-20 373 drm_fb_helper_prepare(adev->ddev,
&rfbdev->helper,
d38ceaf9 Alex Deucher 2015-04-20 374
&amdgpu_fb_helper_funcs);
d38ceaf9 Alex Deucher 2015-04-20 375
d38ceaf9 Alex Deucher 2015-04-20 @376 ret = drm_fb_helper_init(adev->ddev,
&rfbdev->helper,
d38ceaf9 Alex Deucher 2015-04-20 377
AMDGPUFB_CONN_LIMIT);
d38ceaf9 Alex Deucher 2015-04-20 378 if (ret) {
d38ceaf9 Alex Deucher 2015-04-20 379 kfree(rfbdev);
:: The code at line 376 was first introduced by commit
:: d38ceaf99ed015f2a0b9af3499791bd3a3daae21 drm/amdgpu: add core driver (v4)
:: TO: Alex Deucher
:: CC: Alex Deucher
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fix build when FBDEV_EMULATION is disabled
Commit be7f735cd5ea ("drm: Rely on mode_config data for fb_helper
initialization") broke the build when CONFIG_DRM_FBDEV_EMULATION is
disabled because it didn't update the prototype for drm_fb_helper_init
in that case.
Fixes: be7f735cd5ea ("drm: Rely on mode_config data for fb_helper
initialization")
Signed-off-by: Gabriel Krisman Bertazi
---
include/drm/drm_fb_helper.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 278820ee17ad..6f5acebb266a 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -307,7 +307,7 @@ static inline void drm_fb_helper_prepare(struct drm_device
*dev,
}
static inline int drm_fb_helper_init(struct drm_device *dev,
- struct drm_fb_helper *helper, int crtc_count,
+ struct drm_fb_helper *helper,
int max_conn)
{
return 0;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix build when FBDEV_EMULATION is disabled
On Thu, Feb 02, 2017 at 05:39:00PM -0200, Gabriel Krisman Bertazi wrote:
> Commit be7f735cd5ea ("drm: Rely on mode_config data for fb_helper
> initialization") broke the build when CONFIG_DRM_FBDEV_EMULATION is
> disabled because it didn't update the prototype for drm_fb_helper_init
> in that case.
>
> Fixes: be7f735cd5ea ("drm: Rely on mode_config data for fb_helper
> initialization")
> Signed-off-by: Gabriel Krisman Bertazi
Oops. Applied, thanks for the quick fix.
-Daniel
> ---
> include/drm/drm_fb_helper.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 278820ee17ad..6f5acebb266a 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -307,7 +307,7 @@ static inline void drm_fb_helper_prepare(struct
> drm_device *dev,
> }
>
> static inline int drm_fb_helper_init(struct drm_device *dev,
> -struct drm_fb_helper *helper, int crtc_count,
> +struct drm_fb_helper *helper,
> int max_conn)
> {
> return 0;
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
AW: mmap with PROT_WRITE of dma-buf FD coming from eglExportDMABUFImageMESA
On Thu, Feb 02, 2017 at 05:19:58PM +0100, Volker Vogelhuber wrote:
>> I'm currently trying to mmap the memory of an OpenGL texture I've created by
>> doing the following:
>>
>> std::vector image_attribs = {
>> EGL_WIDTH, static_cast(m_texWidth & 0x7FFF),
>> EGL_HEIGHT, static_cast(m_texHeight & 0x7FFF),
>> EGL_DRM_BUFFER_USE_MESA, EGL_DRM_BUFFER_USE_SCANOUT_MESA,
>> EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_FORMAT_ARGB32_MESA
>> EGL_NONE
>> };
>> glGenTextures( 1, &texID );
>> glBindTexture( GL_TEXTURE_2D, texID );
>> eglImage = eglCreateDRMImageMESA( eglGetCurrentDisplay(), &image_attribs[0]
>> );
>> glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, eglmage);
>> eglExportDMABUFImageQueryMESA(eglGetCurrentDisplay(), eglImage, &fourcc,
>> &nplanes, &modifiers)
>> eglExportDMABUFImageMESA(eglGetCurrentDisplay(), eglImage, &fd, strides,
>> offsets)
>>
>> struct dma_buf_sync sync_args = { .flags = DMA_BUF_SYNC_START };
>> ioctl( fd, DMA_BUF_IOCTL_SYNC, sync_args);
>> mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0 );
>>
>> For some reason mmap returns MAP_FAILED when using the PROT_WRITE flag,
>> while
>> using only PROT_READ seems to be fine. I'm currently using kernel 4.9.6 on
>> an Intel CherryTrail (i915).
>>
>> Is there an obvious reason why I'm not able to mmap the texture FD with
>> PROT_WRITE flags?
>> Reading https://01.org/blogs/2016/sharing-cpu-and-gpu-buffers-linux I would
>> have guessed that
>> this should be possible. Or is it only true for specific GEM buffers not
>> textures created using
>> eglCreateDRMImageMESA?
>
>From a quick look the mesa/libdrm (depending upon driver) handle2fd
>implementations don't set the DRM_RDWR flag when asking PRIME for a
>dma-buf fd, which means you fd doesn't have write permissions. Which means
>mmap with writing allowed will fail.
>
>Not sure how to fix that.
Thanks for the reply. I guess you mean that line of code:
http://code.metager.de/source/xref/freedesktop/mesa/drm/intel/intel_bufmgr_gem.c#2679
Is there a good reason not to patch drm_intel_bo_gem_export_to_prime to call
drmPrimeHandleToFD with DRM_RDWR flag set as well? I just saw a similar
discussion
under https://chromium-review.googlesource.com/c/323990/
Regards,
Volker
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board
I'm going to need to cool down for a bit. Let's resume this on Monday, maybe we can get back to being constructive after the weekend. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93341] Semi-random GPU lockups on radeonsi with a RadeonHD 7770 (when playing videos, running OpenGL games, WebGL apps, or after extended periods of time)
https://bugs.freedesktop.org/show_bug.cgi?id=93341 --- Comment #21 from Jean-François Fortin Tam --- Created attachment 129304 --> https://bugs.freedesktop.org/attachment.cgi?id=129304&action=edit journalctl output at the time of a deadlock on F25 - X GDM session output only Hi Alex and thanks for the pointer, here's the output as per those instructions... but the result seems quite useless compared to the full journalctl output (which I'll be attaching as well). -- 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 93341] Semi-random GPU lockups on radeonsi with a RadeonHD 7770 (when playing videos, running OpenGL games, WebGL apps, or after extended periods of time)
https://bugs.freedesktop.org/show_bug.cgi?id=93341 Jean-François Fortin Tam changed: What|Removed |Added Attachment #128278|0 |1 is obsolete|| --- Comment #22 from Jean-François Fortin Tam --- Created attachment 129305 --> https://bugs.freedesktop.org/attachment.cgi?id=129305&action=edit journalctl output at the time of a deadlock on F25 - take 2 Full journal output at the time of the crash. Exactly the same as before as far as I can tell. If there's any other information I can provide, please tell. -- 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 93341] Semi-random GPU lockups on radeonsi with a RadeonHD 7770 (when playing videos, running OpenGL games, WebGL apps, or after extended periods of time)
https://bugs.freedesktop.org/show_bug.cgi?id=93341 --- Comment #23 from Jean-François Fortin Tam --- Created attachment 129306 --> https://bugs.freedesktop.org/attachment.cgi?id=129306&action=edit Xorg log Xorg.0.log file found in ~/.local/share/xorg as "Xorg.0.log.old" As you can see it says nothing about the crash. It seems only the global journalctl output caught something. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G
On Thu, Feb 02, 2017 at 06:04:00PM -0200, Breno Lima wrote:
> Add support for Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480)
> TFT with Touch-Panel, which can be supported by the simple panel driver.
>
> Data-sheet available at:
> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf
>
> Signed-off-by: Breno Lima
> ---
> .../bindings/display/panel/sii,43wvf1g.txt | 7 ++
> drivers/gpu/drm/panel/panel-simple.c | 28
> ++
> 2 files changed, 35 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/sii,43wvf1g.txt
>
> diff --git a/Documentation/devicetree/bindings/display/panel/sii,43wvf1g.txt
> b/Documentation/devicetree/bindings/display/panel/sii,43wvf1g.txt
> new file mode 100644
> index 000..bbbc49f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/sii,43wvf1g.txt
> @@ -0,0 +1,7 @@
> +Seiko Instruments Inc. 4.3" WVGA (800 x RGB x 480) TFT with Touch-Panel
> +
> +Required properties:
> +- compatible: should be "sii,43wvf1g"
> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 06aaf79..0e08c56 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -863,6 +863,31 @@ static const struct panel_desc hannstar_hsd070pww1 = {
> .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> };
>
> +static const struct display_timing sii_43wvf1g_timing = {
> + .pixelclock = { 3350, 3350, 3350 },
> + .hactive = { 800, 800, 800 },
> + .hfront_porch = { 164, 164, 164 },
> + .hback_porch = { 89, 89, 89 },
> + .hsync_len = { 10, 10, 10 },
> + .vactive = { 480, 480, 480 },
> + .vfront_porch = { 10, 10, 10 },
> + .vback_porch = { 23, 23, 23 },
> + .vsync_len = { 10, 10, 10 },
> + .flags = DISPLAY_FLAGS_DE_LOW,
> +};
I was going to say that you should list minimum and maximum values, and
that the default implementation will give you the typical values, but it
seems like the datasheet doesn't have minimum and maximum values, so
this looks fine.
Shawn, Fabio, anyone want to give this a Tested-by? I take it that this,
in combination with Fabio's patch to fix the displacement would make the
SabreSD display work properly?
Thierry
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:drm-intel-nightly 1076/1086] drivers/gpu/drm/gma500/framebuffer.c:566:8: error: too few arguments to function 'drm_fb_helper_init'
tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly head: 0f01216949002d20b9dc6d300c82df5ffa59e9a7 commit: e4563f6ba71792c77aeccb2092cc23149b44e642 [1076/1086] drm: Rely on mode_config data for fb_helper initialization config: i386-randconfig-x0-02030244 (attached as .config) compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901 reproduce: git checkout e4563f6ba71792c77aeccb2092cc23149b44e642 # save the attached .config to linux build tree make ARCH=i386 Note: the drm-intel/drm-intel-nightly HEAD 0f01216949002d20b9dc6d300c82df5ffa59e9a7 builds fine. It only hurts bisectibility. All errors (new ones prefixed by >>): drivers/gpu/drm/gma500/framebuffer.c: In function 'psb_fbdev_init': >> drivers/gpu/drm/gma500/framebuffer.c:566:8: error: too few arguments to >> function 'drm_fb_helper_init' ret = drm_fb_helper_init(dev, &fbdev->psb_fb_helper, ^~ In file included from drivers/gpu/drm/gma500/framebuffer.c:35:0: include/drm/drm_fb_helper.h:309:19: note: declared here static inline int drm_fb_helper_init(struct drm_device *dev, ^~ -- drivers/gpu/drm/qxl/qxl_fb.c: In function 'qxl_fbdev_init': >> drivers/gpu/drm/qxl/qxl_fb.c:401:8: error: too few arguments to function >> 'drm_fb_helper_init' ret = drm_fb_helper_init(&qdev->ddev, &qfbdev->helper, ^~ In file included from drivers/gpu/drm/qxl/qxl_fb.c:35:0: include/drm/drm_fb_helper.h:309:19: note: declared here static inline int drm_fb_helper_init(struct drm_device *dev, ^~ vim +/drm_fb_helper_init +566 drivers/gpu/drm/gma500/framebuffer.c 4d8d096e9 Alan Cox2011-11-03 560 } 4d8d096e9 Alan Cox2011-11-03 561 4d8d096e9 Alan Cox2011-11-03 562 dev_priv->fbdev = fbdev; 10a231026 Thierry Reding 2014-06-27 563 10a231026 Thierry Reding 2014-06-27 564 drm_fb_helper_prepare(dev, &fbdev->psb_fb_helper, &psb_fb_helper_funcs); 4d8d096e9 Alan Cox2011-11-03 565 01934c2a6 Thierry Reding 2014-12-19 @566 ret = drm_fb_helper_init(dev, &fbdev->psb_fb_helper, e4563f6ba Gabriel Krisman Bertazi 2017-02-02 567 INTELFB_CONN_LIMIT); 01934c2a6 Thierry Reding 2014-12-19 568 if (ret) 01934c2a6 Thierry Reding 2014-12-19 569 goto free; :: The code at line 566 was first introduced by commit :: 01934c2a691882185b3021d437df13bcba07711d drm/fb-helper: Propagate errors from initial config failure :: TO: Thierry Reding :: CC: Daniel Vetter --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: mmap with PROT_WRITE of dma-buf FD coming from eglExportDMABUFImageMESA
On Thu, Feb 2, 2017 at 8:46 PM, Volker Vogelhuber
wrote:
> On Thu, Feb 02, 2017 at 05:19:58PM +0100, Volker Vogelhuber wrote:
>>> I'm currently trying to mmap the memory of an OpenGL texture I've created by
>>> doing the following:
>>>
>>> std::vector image_attribs = {
>>> EGL_WIDTH, static_cast(m_texWidth & 0x7FFF),
>>> EGL_HEIGHT, static_cast(m_texHeight & 0x7FFF),
>>> EGL_DRM_BUFFER_USE_MESA, EGL_DRM_BUFFER_USE_SCANOUT_MESA,
>>> EGL_DRM_BUFFER_FORMAT_MESA, EGL_DRM_BUFFER_FORMAT_ARGB32_MESA
>>> EGL_NONE
>>> };
>>> glGenTextures( 1, &texID );
>>> glBindTexture( GL_TEXTURE_2D, texID );
>>> eglImage = eglCreateDRMImageMESA( eglGetCurrentDisplay(), &image_attribs[0]
>>> );
>>> glEGLImageTargetTexture2DOES(GL_TEXTURE_2D, eglmage);
>>> eglExportDMABUFImageQueryMESA(eglGetCurrentDisplay(), eglImage, &fourcc,
>>> &nplanes, &modifiers)
>>> eglExportDMABUFImageMESA(eglGetCurrentDisplay(), eglImage, &fd, strides,
>>> offsets)
>>>
>>> struct dma_buf_sync sync_args = { .flags = DMA_BUF_SYNC_START };
>>> ioctl( fd, DMA_BUF_IOCTL_SYNC, sync_args);
>>> mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0 );
>>>
>>> For some reason mmap returns MAP_FAILED when using the PROT_WRITE flag,
>>> while
>>> using only PROT_READ seems to be fine. I'm currently using kernel 4.9.6 on
>>> an Intel CherryTrail (i915).
>>>
>>> Is there an obvious reason why I'm not able to mmap the texture FD with
>>> PROT_WRITE flags?
>>> Reading https://01.org/blogs/2016/sharing-cpu-and-gpu-buffers-linux I would
>>> have guessed that
>>> this should be possible. Or is it only true for specific GEM buffers not
>>> textures created using
>>> eglCreateDRMImageMESA?
>>
> >From a quick look the mesa/libdrm (depending upon driver) handle2fd
>>implementations don't set the DRM_RDWR flag when asking PRIME for a
>>dma-buf fd, which means you fd doesn't have write permissions. Which means
>>mmap with writing allowed will fail.
>>
>>Not sure how to fix that.
> Thanks for the reply. I guess you mean that line of code:
> http://code.metager.de/source/xref/freedesktop/mesa/drm/intel/intel_bufmgr_gem.c#2679
> Is there a good reason not to patch drm_intel_bo_gem_export_to_prime to call
> drmPrimeHandleToFD with DRM_RDWR flag set as well? I just saw a similar
> discussion
> under https://chromium-review.googlesource.com/c/323990/
Probably none, just a historical accident because the first prime
support didn't have support for mmap. Feel free to submit patches for
this all.
Thanks, 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
Re: [Freedreno] [RFC] drm/msm/adreno: clean up gpu bindings
On Thu, Jan 26, 2017 at 05:03:54PM -0500, Rob Clark wrote: > On Thu, Jan 26, 2017 at 4:09 PM, Rob Herring wrote: > > On Thu, Jan 26, 2017 at 1:51 PM, Rob Clark wrote: > >> On Thu, Jan 26, 2017 at 2:11 PM, Rob Herring wrote: > >>> On Tue, Jan 24, 2017 at 11:11 AM, Rob Clark wrote: > So, cleaning up the GPU bindings is something that has been on my TODO > list for a while, but always $bigger_fires. Existing bindings are a bit > ugly, but served a purpose when too many of the other drivers the GPU > depends on where still working their way upstream. But now enough of > that is in place for a few devices, that we should start trying to get > the GPU nodes into the upstream dts files. > > This drops the "qcom,chipid" property and parses the GPU revision out of > the compat string. It does mean you need to list both "qcom,adreno" and > the more specific string, for example "qcom,adreno-530.2". I'm not sure > if that is "weird" or anyone has better ideas (hence this RFC). > >>> > >>> Is version and SoC close to a 1-1 mapping? If one version is in lots > >>> of different SoCs, then you should have an SoC specific compatible. > >> > >> I'm not sure how common it is, but I'm pretty sure in the past I've > >> seen same gpu (but maybe not same patchlevel). > >> > >> Also, there tend to be multiple revisions of the SoC which may or may > >> not bump the gpu patchlevel. I think it is quite likely to be > >> insanity to try and figure out gpu revision from SoC.. > > > > I'm not saying you should. My point is gpu revision alone may not be > > enough. Things can get integrated or configured differently. You could > > use an SoC based compatible, read the revision registers for the > > revision, and override wrong revision registers based on SoC > > compatible (assuming that is rare). > > Hmm, I'll probably defer to Jordan on this, since he has seen more > combinations over the years. > > I think any integration differences would just amount to which > clks/gdsc/etc are wired up. At least what I've seen in downstream > kgsl driver, all the things that are conditional are purely keyed to > the revision+patchlevel. I think for all practical purposes there is a 1-1 mapping between a GPU version and a SoC at least over the last few years. The last time I can remember was an unfortunate series of revisions in the 3XX family which I think ended up being the catalyst for the hardware team getting their act together in this regard. > As far as revision registers, IIRC back in the a3xx days they were not > to be trusted. I'm not entirely sure when they became trustworthy. > Last I checked, android kgsl driver was not using them. We got burned to a crisp over these back in the day and I have never forgotten it so thats why the downstream driver is exclusively DT based (which I admit is probably too far in the other direction). These days I think they are mostly agreeable again (sometimes they don't get updated for metal spins but I think they even got that figured out too). I'm open to using revision registers again as long as we don't blindly trust them and give ourselves a way to override the version. Jordan -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5] drm: Improve drm_mm search (and fix topdown allocation) with rbtrees
The drm_mm range manager claimed to support top-down insertion, but it
was neither searching for the top-most hole that could fit the
allocation request nor fitting the request to the hole correctly.
In order to search the range efficiently, we create a secondary index
for the holes using either their size or their address. This index
allows us to find the smallest hole or the hole at the bottom or top of
the range efficiently, whilst keeping the hole stack to rapidly service
evictions.
v2: Search for holes both high and low. Rename flags to mode.
v3: Discover rb_entry_safe() and use it!
v4: Kerneldoc for enum drm_mm_insert_mode.
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Russell King
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: Lucas Stach
Cc: Christian Gmeiner
Cc: Rob Clark
Cc: Thierry Reding
Cc: Stephen Warren
Cc: Alexandre Courbot
Cc: Eric Anholt
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
Reviewed-by: Alex Deucher
Reviewed-by: Sinclair Yeh # vmwgfx
---
v5: Rebase onto etnaviv pull for 4.11 -- no intentional changes from v4.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 16 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 20 +-
drivers/gpu/drm/armada/armada_gem.c | 4 +-
drivers/gpu/drm/drm_mm.c | 488 +++
drivers/gpu/drm/drm_vma_manager.c| 3 +-
drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 11 +-
drivers/gpu/drm/i915/i915_gem.c | 10 +-
drivers/gpu/drm/i915/i915_gem_evict.c| 9 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 5 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 39 +--
drivers/gpu/drm/i915/i915_gem_stolen.c | 6 +-
drivers/gpu/drm/msm/msm_gem.c| 3 +-
drivers/gpu/drm/msm/msm_gem_vma.c| 3 +-
drivers/gpu/drm/selftests/test-drm_mm.c | 58 ++--
drivers/gpu/drm/sis/sis_mm.c | 6 +-
drivers/gpu/drm/tegra/gem.c | 4 +-
drivers/gpu/drm/ttm/ttm_bo_manager.c | 18 +-
drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
drivers/gpu/drm/vc4/vc4_hvs.c| 3 +-
drivers/gpu/drm/vc4/vc4_plane.c | 6 +-
drivers/gpu/drm/via/via_mm.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 10 +-
include/drm/drm_mm.h | 184 +-
23 files changed, 470 insertions(+), 442 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index e4eb6dd3798a..0335c2f331e9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -97,8 +97,7 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
{
struct amdgpu_gtt_mgr *mgr = man->priv;
struct drm_mm_node *node = mem->mm_node;
- enum drm_mm_search_flags sflags = DRM_MM_SEARCH_BEST;
- enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
+ enum drm_mm_insert_mode mode;
unsigned long fpfn, lpfn;
int r;
@@ -115,15 +114,14 @@ int amdgpu_gtt_mgr_alloc(struct ttm_mem_type_manager *man,
else
lpfn = man->size;
- if (place && place->flags & TTM_PL_FLAG_TOPDOWN) {
- sflags = DRM_MM_SEARCH_BELOW;
- aflags = DRM_MM_CREATE_TOP;
- }
+ mode = DRM_MM_INSERT_BEST;
+ if (place && place->flags & TTM_PL_FLAG_TOPDOWN)
+ mode = DRM_MM_INSERT_HIGH;
spin_lock(&mgr->lock);
- r = drm_mm_insert_node_in_range_generic(&mgr->mm, node, mem->num_pages,
- mem->page_alignment, 0,
- fpfn, lpfn, sflags, aflags);
+ r = drm_mm_insert_node_in_range(&mgr->mm, node,
+ mem->num_pages, mem->page_alignment, 0,
+ fpfn, lpfn, mode);
spin_unlock(&mgr->lock);
if (!r) {
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
index ac9007986c11..9e577e3d3147 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
@@ -97,8 +97,7 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
*man,
struct amdgpu_vram_mgr *mgr = man->priv;
struct drm_mm *mm = &mgr->mm;
struct drm_mm_node *nodes;
- enum drm_mm_search_flags sflags = DRM_MM_SEARCH_DEFAULT;
- enum drm_mm_allocator_flags aflags = DRM_MM_CREATE_DEFAULT;
+ enum drm_mm_insert_mode mode;
unsigned long lpfn, num_nodes, pages_per_node, pages_left;
unsigned i;
int r;
@@ -121,10 +120,9 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager
*man,
if (!nodes)
return -ENOMEM;
- if (place->flags & TTM_PL_FLAG_TOPDOWN) {
-
Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G
Hi Thierry, On Thu, Feb 2, 2017 at 6:18 PM, Thierry Reding wrote: > Shawn, Fabio, anyone want to give this a Tested-by? I take it that this, > in combination with Fabio's patch to fix the displacement would make the > SabreSD display work properly? Yes, that is correct. It also needs the other patch I sent yesterday that allows the power-supply regulator to work. I was able to test it on a imx6sx-sdb board, so: Tested-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: mxsfb_crtc: Fix the framebuffer misplacement
From: Fabio Estevam Currently the framebuffer content is displayed with incorrect offsets in both the vertical and horizontal directions. The fbdev version of the driver does not show this problem. Breno Lima dumped the eLCDIF controller registers on both the drm and fbdev drivers and noticed that the VDCTRL3 register is configured incorrectly in the drm driver. The fbdev driver calculates the vertical and horizontal wait counts of the VDCTRL3 register by doing: back porch + sync length. Looking at the horizontal and vertical timing diagram from include/drm/drm_modes.h this value corresponds to: crtc_[hv]total - crtc_[hv]sync_start So fix the VDCTRL3 register setting accordingly so that the eLCDIF controller can properly show the framebuffer content in the correct position. Reported-by: Breno Lima Signed-off-by: Fabio Estevam --- drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c index e10a4ed..b56f86c 100644 --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c @@ -184,8 +184,8 @@ static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb) VDCTRL2_SET_HSYNC_PERIOD(m->crtc_htotal), mxsfb->base + LCDC_VDCTRL2); - writel(SET_HOR_WAIT_CNT(m->crtc_hblank_end - m->crtc_hsync_end) | - SET_VERT_WAIT_CNT(m->crtc_vblank_end - m->crtc_vsync_end), + writel(SET_HOR_WAIT_CNT(m->crtc_htotal - m->crtc_hsync_start) | + SET_VERT_WAIT_CNT(m->crtc_vtotal - m->crtc_vsync_start), mxsfb->base + LCDC_VDCTRL3); writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay), -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/3] drm/atomic: Save flip flags in drm_crtc_state
Allows using atomic flip helpers for drivers
using ASYNC flip.
Remove ASYNC_FLIP restriction in helpers and
caches the page flip flags in drm_crtc_state
to be used in the low level drivers.
v2:
Resending the patch since the original was broken.
v3:
Save flag in crtc_state instead of plane_state
v4:
Reset the flag before using again.
v5:
Fix type in header.
Rename the field to pageflip_flags.
Remove unrelated hunk.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/drm_atomic_helper.c | 20 ++--
include/drm/drm_crtc.h | 9 -
2 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a4e5477..63efa05 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2737,7 +2737,8 @@ static int page_flip_common(
struct drm_atomic_state *state,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
- struct drm_pending_vblank_event *event)
+ struct drm_pending_vblank_event *event,
+ uint32_t flags)
{
struct drm_plane *plane = crtc->primary;
struct drm_plane_state *plane_state;
@@ -2749,12 +2750,12 @@ static int page_flip_common(
return PTR_ERR(crtc_state);
crtc_state->event = event;
+ crtc_state->pageflip_flags = flags;
plane_state = drm_atomic_get_plane_state(state, plane);
if (IS_ERR(plane_state))
return PTR_ERR(plane_state);
-
ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
if (ret != 0)
return ret;
@@ -2781,10 +2782,6 @@ static int page_flip_common(
* Provides a default &drm_crtc_funcs.page_flip implementation
* using the atomic driver interface.
*
- * Note that for now so called async page flips (i.e. updates which are not
- * synchronized to vblank) are not supported, since the atomic interfaces have
- * no provisions for this yet.
- *
* Returns:
* Returns 0 on success, negative errno numbers on failure.
*
@@ -2800,9 +2797,6 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
struct drm_atomic_state *state;
int ret = 0;
- if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
- return -EINVAL;
-
state = drm_atomic_state_alloc(plane->dev);
if (!state)
return -ENOMEM;
@@ -2810,7 +2804,7 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
retry:
- ret = page_flip_common(state, crtc, fb, event);
+ ret = page_flip_common(state, crtc, fb, event, flags);
if (ret != 0)
goto fail;
@@ -2865,9 +2859,6 @@ int drm_atomic_helper_page_flip_target(
struct drm_crtc_state *crtc_state;
int ret = 0;
- if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
- return -EINVAL;
-
state = drm_atomic_state_alloc(plane->dev);
if (!state)
return -ENOMEM;
@@ -2875,7 +2866,7 @@ int drm_atomic_helper_page_flip_target(
state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
retry:
- ret = page_flip_common(state, crtc, fb, event);
+ ret = page_flip_common(state, crtc, fb, event, flags);
if (ret != 0)
goto fail;
@@ -3072,6 +3063,7 @@ void __drm_atomic_helper_crtc_duplicate_state(struct
drm_crtc *crtc,
state->color_mgmt_changed = false;
state->zpos_changed = false;
state->event = NULL;
+ state->pageflip_flags = 0;
}
EXPORT_SYMBOL(__drm_atomic_helper_crtc_duplicate_state);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5c77c3f..76561fb 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -162,10 +162,17 @@ struct drm_crtc_state {
* Target vertical blank period when a page flip
* should take effect.
*/
-
u32 target_vblank;
/**
+* @pageflip_flags:
+*
+* DRM_MODE_PAGE_FLIP_* flags, as passed to the page flip ioctl.
+* Zero in any other case.
+*/
+ u32 pageflip_flags;
+
+ /**
* @event:
*
* Optional pointer to a DRM event to signal upon completion of the
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/3] drm/nouveau/kms/nv50: Switch to using atomic helper for flip.
v2:
Update code after flip_flags moved from plane_state
to crtc_state
v5:
Rename to pageflip_flags.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/nouveau/nv50_display.c | 84 --
1 file changed, 10 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index 2c2c645..c6153d3 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -831,7 +831,8 @@ struct nv50_wndw_func {
static int
nv50_wndw_atomic_check_acquire(struct nv50_wndw *wndw,
struct nv50_wndw_atom *asyw,
- struct nv50_head_atom *asyh)
+ struct nv50_head_atom *asyh,
+ u32 pflip_flags)
{
struct nouveau_framebuffer *fb = nouveau_framebuffer(asyw->state.fb);
struct nouveau_drm *drm = nouveau_drm(wndw->plane.dev);
@@ -846,6 +847,9 @@ struct nv50_wndw_func {
asyw->image.w = fb->base.width;
asyw->image.h = fb->base.height;
asyw->image.kind = (fb->nvbo->tile_flags & 0xff00) >> 8;
+
+ asyw->interval = pflip_flags & DRM_MODE_PAGE_FLIP_ASYNC ? 0 : 1;
+
if (asyw->image.kind) {
asyw->image.layout = 0;
if (drm->device.info.chipset >= 0xc0)
@@ -883,6 +887,7 @@ struct nv50_wndw_func {
struct nv50_head_atom *harm = NULL, *asyh = NULL;
bool varm = false, asyv = false, asym = false;
int ret;
+ u32 pflip_flags = 0;
NV_ATOMIC(drm, "%s atomic_check\n", plane->name);
if (asyw->state.crtc) {
@@ -891,6 +896,7 @@ struct nv50_wndw_func {
return PTR_ERR(asyh);
asym = drm_atomic_crtc_needs_modeset(&asyh->state);
asyv = asyh->state.active;
+ pflip_flags = asyh->state.pageflip_flags;
}
if (armw->state.crtc) {
@@ -907,7 +913,8 @@ struct nv50_wndw_func {
asyw->set.point = true;
if (!varm || asym || armw->state.fb != asyw->state.fb) {
- ret = nv50_wndw_atomic_check_acquire(wndw, asyw, asyh);
+ ret = nv50_wndw_atomic_check_acquire(
+ wndw, asyw, asyh, pflip_flags);
if (ret)
return ret;
}
@@ -2221,77 +2228,6 @@ struct nv50_base {
.atomic_check = nv50_head_atomic_check,
};
-/* This is identical to the version in the atomic helpers, except that
- * it supports non-vblanked ("async") page flips.
- */
-static int
-nv50_head_page_flip(struct drm_crtc *crtc, struct drm_framebuffer *fb,
- struct drm_pending_vblank_event *event, u32 flags)
-{
- struct drm_plane *plane = crtc->primary;
- struct drm_atomic_state *state;
- struct drm_plane_state *plane_state;
- struct drm_crtc_state *crtc_state;
- int ret = 0;
-
- state = drm_atomic_state_alloc(plane->dev);
- if (!state)
- return -ENOMEM;
-
- state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
-retry:
- crtc_state = drm_atomic_get_crtc_state(state, crtc);
- if (IS_ERR(crtc_state)) {
- ret = PTR_ERR(crtc_state);
- goto fail;
- }
- crtc_state->event = event;
-
- plane_state = drm_atomic_get_plane_state(state, plane);
- if (IS_ERR(plane_state)) {
- ret = PTR_ERR(plane_state);
- goto fail;
- }
-
- ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
- if (ret != 0)
- goto fail;
- drm_atomic_set_fb_for_plane(plane_state, fb);
-
- /* Make sure we don't accidentally do a full modeset. */
- state->allow_modeset = false;
- if (!crtc_state->active) {
- DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy flip\n",
-crtc->base.id);
- ret = -EINVAL;
- goto fail;
- }
-
- if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
- nv50_wndw_atom(plane_state)->interval = 0;
-
- ret = drm_atomic_nonblocking_commit(state);
-fail:
- if (ret == -EDEADLK)
- goto backoff;
-
- drm_atomic_state_put(state);
- return ret;
-
-backoff:
- drm_atomic_state_clear(state);
- drm_atomic_legacy_backoff(state);
-
- /*
-* Someone might have exchanged the framebuffer while we dropped locks
-* in the backoff code. We need to fix up the fb refcount tracking the
-* core does for us.
-*/
- plane->old_fb = plane->fb;
-
- goto retry;
-}
-
static int
nv50_head_gamma_set(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
uint32_t size)
@@ -2386,7 +2322,7 @@ struct nv50_base {
.gamma_set = nv50_head_gamma_set,
.destroy = nv50_head_destroy,
[PATCH v5 0/3] Allow ASYNC flip with atomic helpers.
This series is a folow-up on https://patchwork.kernel.org/patch/9501787/ The first patch makes changes to atomic helpers to allow for drives with ASYNC flip support to use them. Patch 2 is to use this in AMDGPU/DC. Patch 3 is possible cleanup in nouveau/kms who seems to have to duplicate the helper as we did to support ASYNC flips. v2: Resend drm/atomic: Save flip flags in drm_plane_state since the original patch was incomplete. Squash 2 AMD changes into one to not break compilation. v3: Following Daniel's comments, save flip flags in crtc_state instead of plane_state. v4: Lauren's comment, reset flp flags before using again. Harry's comment, fix identation in amd/display. v5: Rename the flag, fix typo in header. Andrey Grodzovsky (3): drm/atomic: Save flip flags in drm_crtc_state drm/nouveau/kms/nv50: Switch to using atomic helper for flip. drm/amd/display: Switch to using atomic_helper for flip. drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 - .../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 113 + drivers/gpu/drm/drm_atomic_helper.c| 20 ++-- drivers/gpu/drm/nouveau/nv50_display.c | 84 ++- include/drm/drm_crtc.h | 9 +- 5 files changed, 48 insertions(+), 179 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/3] drm/amd/display: Switch to using atomic_helper for flip.
v2:
Modify for movig pflip flags to crtc_state
v4:
Fix identation.
v5:
Rename field to pageflip_flags.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 -
.../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 113 +
2 files changed, 24 insertions(+), 90 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
index 4c0a86e..3ff3c14 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h
@@ -443,7 +443,6 @@ struct amdgpu_crtc {
enum amdgpu_interrupt_state vsync_timer_enabled;
int otg_inst;
- uint32_t flip_flags;
/* After Set Mode target will be non-NULL */
struct dc_target *target;
};
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
index a443b70..81c46d6 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_types.c
@@ -1060,83 +1060,6 @@ static int dm_crtc_funcs_atomic_set_property(
return 0;
}
-
-static int amdgpu_atomic_helper_page_flip(struct drm_crtc *crtc,
- struct drm_framebuffer *fb,
- struct drm_pending_vblank_event *event,
- uint32_t flags)
-{
- struct drm_plane *plane = crtc->primary;
- struct amdgpu_crtc *acrtc = to_amdgpu_crtc(crtc);
- struct drm_atomic_state *state;
- struct drm_plane_state *plane_state;
- struct drm_crtc_state *crtc_state;
- int ret = 0;
-
- state = drm_atomic_state_alloc(plane->dev);
- if (!state)
- return -ENOMEM;
-
- ret = drm_crtc_vblank_get(crtc);
- if (ret)
- return ret;
-
- state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
-retry:
- crtc_state = drm_atomic_get_crtc_state(state, crtc);
- if (IS_ERR(crtc_state)) {
- ret = PTR_ERR(crtc_state);
- goto fail;
- }
- crtc_state->event = event;
-
- plane_state = drm_atomic_get_plane_state(state, plane);
- if (IS_ERR(plane_state)) {
- ret = PTR_ERR(plane_state);
- goto fail;
- }
-
- ret = drm_atomic_set_crtc_for_plane(plane_state, crtc);
- if (ret != 0)
- goto fail;
- drm_atomic_set_fb_for_plane(plane_state, fb);
-
- /* Make sure we don't accidentally do a full modeset. */
- state->allow_modeset = false;
- if (!crtc_state->active) {
- DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy flip\n",
-crtc->base.id);
- ret = -EINVAL;
- goto fail;
- }
- acrtc->flip_flags = flags;
-
- ret = drm_atomic_nonblocking_commit(state);
-
-fail:
- if (ret == -EDEADLK)
- goto backoff;
-
- if (ret)
- drm_crtc_vblank_put(crtc);
-
- drm_atomic_state_put(state);
-
- return ret;
-backoff:
- drm_atomic_state_clear(state);
- drm_atomic_legacy_backoff(state);
-
- /*
-* Someone might have exchanged the framebuffer while we dropped locks
-* in the backoff code. We need to fix up the fb refcount tracking the
-* core does for us.
-*/
- plane->old_fb = plane->fb;
-
- goto retry;
-}
-
/* Implemented only the options currently availible for the driver */
static const struct drm_crtc_funcs amdgpu_dm_crtc_funcs = {
.reset = drm_atomic_helper_crtc_reset,
@@ -1145,7 +1068,7 @@ static int amdgpu_atomic_helper_page_flip(struct drm_crtc
*crtc,
.destroy = amdgpu_dm_crtc_destroy,
.gamma_set = amdgpu_dm_atomic_crtc_gamma_set,
.set_config = drm_atomic_helper_set_config,
- .page_flip = amdgpu_atomic_helper_page_flip,
+ .page_flip_target = drm_atomic_helper_page_flip_target,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
.atomic_set_property = dm_crtc_funcs_atomic_set_property
@@ -1626,7 +1549,8 @@ static void clear_unrelated_fields(struct drm_plane_state
*state)
static bool page_flip_needed(
const struct drm_plane_state *new_state,
const struct drm_plane_state *old_state,
- bool commit_surface_required)
+ bool commit_surface_required,
+ uint32_t pflip_flags)
{
struct drm_plane_state old_state_tmp;
struct drm_plane_state new_state_tmp;
@@ -1679,7 +1603,7 @@ static bool page_flip_needed(
sizeof(old_state_tmp)) == 0 ? true:false;
if (new_state->crtc && page_flip_required == false) {
acrtc_new = to_amdgpu_crtc(new_state->crtc);
- if (acrtc_new->flip_flags & DRM_MODE_PAGE_FLIP_ASYNC)
+ if
[Bug 193651] Amdgpu error messages at boot with Amd RX460
https://bugzilla.kernel.org/show_bug.cgi?id=193651 --- Comment #12 from Steven A. Falco --- Created attachment 253891 --> https://bugzilla.kernel.org/attachment.cgi?id=253891&action=edit New dmesg file -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 193651] Amdgpu error messages at boot with Amd RX460
https://bugzilla.kernel.org/show_bug.cgi?id=193651 --- Comment #14 from Steven A. Falco --- One other error message I just noticed: [5.538117] amdgpu: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 193651] Amdgpu error messages at boot with Amd RX460
https://bugzilla.kernel.org/show_bug.cgi?id=193651 --- Comment #13 from Steven A. Falco --- I successfully built a custom kernel. It appears to be working well. Thanks for the help! I included a new dmesg.log file because I still see messages like: [9.719278] amdgpu: [powerplay] failed to send pre message 15b ret is 0 [ 10.158327] amdgpu: [powerplay] failed to send message 15b ret is 0 Are these harmless or do they indicate a problem? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] intel: avoid null pointer dereference
Introduced in 028715ee Move the dereference after the null check. --- intel/intel_decode.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/intel/intel_decode.c b/intel/intel_decode.c index 803d202..2721ffd 100644 --- a/intel/intel_decode.c +++ b/intel/intel_decode.c @@ -3899,7 +3899,7 @@ drm_intel_decode(struct drm_intel_decode *ctx) int ret; unsigned int index = 0; uint32_t devid; - int size = ctx->base_count * 4; + int size; void *temp; if (!ctx) @@ -3909,6 +3909,7 @@ drm_intel_decode(struct drm_intel_decode *ctx) * the batchbuffer. This lets us avoid a bunch of length * checking in statically sized packets. */ + size = ctx->base_count * 4; temp = malloc(size + 4096); memcpy(temp, ctx->base_data, size); memset((char *)temp + size, 0xd0, 4096); -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for 4.10-rc7
Hi Linus, Another fixes pull for v4.10, it's a bit big due to the backport of the VMA fixes for i915 that should fix the oops on shutdown problems that you've worked around. There are also two drm core connector registration fixes, a bunch of nouveau regression fixes and two AMD fixes. Dave. The following changes since commit 566cf877a1fcb6d6dc0126b076aad062054c2637: Linux 4.10-rc6 (2017-01-29 14:25:17 -0800) are available in the git repository at: git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.10-rc7 for you to fetch changes up to f63cf464fc379382a271f94ddef36e8c5a0628eb: Merge branch 'drm-fixes-4.10' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-02-03 09:10:08 +1000) intel vma fixes, amd and nouveau fixes. Alastair Bridgewater (1): drm/nouveau/disp/gt215: Fix HDA ELD handling (thus, HDMI audio) on gt215 Alex Deucher (1): drm/amdgpu/si: fix crash on headless asics Ben Skeggs (4): drm/nouveau/fence/g84-: protect against concurrent access to semaphore buffers drm/nouveau: prevent userspace from deleting client object drm/nouveau/disp/mcp7x: disable dptmds workaround drm/nouveau/kms/nv50: request vblank events for commits that send completion events Chris Wilson (1): drm/i915: Track pinned vma in intel_plane_state Daniel Vetter (2): drm: prevent double-(un)registration for connectors drm: Don't race connector registration Dave Airlie (4): Merge branch 'linux-4.10' of git://github.com/skeggsb/linux into drm-fixes Merge tag 'drm-misc-fixes-2017-01-31' of git://anongit.freedesktop.org/git/drm-misc into drm-fixes Merge tag 'topic/vma-fix-for-4.10-2017-02-02' of git://anongit.freedesktop.org/git/drm-intel into drm-fixes Merge branch 'drm-fixes-4.10' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Ilia Mirkin (1): drm/nouveau/nv1a,nv1f/disp: fix memory clock rate retrieval Maarten Lankhorst (2): drm/atomic: Fix double free in drm_atomic_state_default_clear drm/atomic: Unconditionally call prepare_fb. Martin Peres (1): drm/nouveau/nouveau/led: prevent compiling the led-code if nouveau=y and leds=m Michel Dänzer (1): drm/radeon: Fix vram_size/visible values in DRM_RADEON_GEM_INFO ioctl drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c | 4 +- drivers/gpu/drm/drm_atomic.c | 13 ++- drivers/gpu/drm/drm_atomic_helper.c| 9 -- drivers/gpu/drm/drm_connector.c| 23 +++- drivers/gpu/drm/drm_drv.c | 4 + drivers/gpu/drm/i915/i915_drv.h| 16 +-- drivers/gpu/drm/i915/intel_atomic_plane.c | 20 drivers/gpu/drm/i915/intel_display.c | 125 +++-- drivers/gpu/drm/i915/intel_drv.h | 9 +- drivers/gpu/drm/i915/intel_fbc.c | 52 - drivers/gpu/drm/i915/intel_fbdev.c | 4 +- drivers/gpu/drm/i915/intel_sprite.c| 8 +- drivers/gpu/drm/nouveau/dispnv04/hw.c | 3 +- drivers/gpu/drm/nouveau/nouveau_fence.h| 1 + drivers/gpu/drm/nouveau/nouveau_led.h | 2 +- drivers/gpu/drm/nouveau/nouveau_usif.c | 3 +- drivers/gpu/drm/nouveau/nv50_display.c | 6 + drivers/gpu/drm/nouveau/nv84_fence.c | 6 + .../gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c| 2 +- drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c| 2 - drivers/gpu/drm/radeon/radeon_drv.c| 3 +- drivers/gpu/drm/radeon/radeon_gem.c| 4 +- include/drm/drmP.h | 1 + include/drm/drm_connector.h| 16 ++- 24 files changed, 171 insertions(+), 165 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH xserver] modesetting: re-set the crtc's mode when link-status goes BAD
On 01/02/17 22:05, Manasi Navare wrote: On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote: Jani Nikula writes: On Tue, 31 Jan 2017, Eric Anholt wrote: Martin Peres writes: Despite all the careful planing of the kernel, a link may become insufficient to handle the currently-set mode. At this point, the kernel should mark this particular configuration as being broken and potentially prune the mode before setting the offending connector's link-status to BAD and send the userspace a hotplug event. This may happen right after a modeset or later on. When available, we should use the link-status information to reset the wanted mode. Signed-off-by: Martin Peres If I understand this right, there are two failure modes being handled: 1) A mode that won't actually work because the link isn't good enough. 2) A mode that should work, but link parameters were too optimistic and if we just ask the kernel to set the mode again it'll use more conservative parameters that work. This patch seems good for 2). For 1), the drmmode_set_mode_major is going to set our old mode back. Won't the modeset then fail to link train again, and bring us back into this loop? The only escape that I see would be some other userspace responding to the advertised mode list changing, and then asking X to modeset to something new. To avoid that failure busy loop, should we re-fetching modes at this point, and only re-setting if our mode still exists? Disclaimer: I don't know anything about the internals of the modesetting driver. Perhaps we can identify the two cases now, but I'd put this more generally: if the link status has gone bad, it's an indicator to userspace that the circumstances may have changed, and userspace should query the kernel for the list of available modes again. It should no longer trust information obtained prior to getting the bad link status, including the current mode. But specifically, I think you're right, and AFAICT asking for the list of modes again is the only way for the userspace to distinguish between the two cases. I don't think there's a shortcut for deciding the current mode is still valid. To avoid the busy-loop problem, I think I'd like this patch to re-query the kernel to ask about the current mode list, and only try to re-set the mode if our mode is still there. If the mode isn't there, then it's up to the DE to take action in response to the notification of new modes. If you don't have a DE to take appropriate action, you're kind of out of luck. As far as the ABI goes, this seems fine to me. The only concern I had about ABI was having to walk all the connectors on every uevent to see if any had gone bad -- couldn't we have a flag of some sort about what the uevent indicates? But uevents should be super rare, so I'd say the kernel could go ahead with the current plan. Yes I agree. The kernel sets the link status BAD as soona s link training fails but does not prune the modes until a new modelist is requested by the userspace. So this patch should re query the mode list as soon as it sees the link status BAD in order for the kernel to validate the modes again based on new link paarmeters and send a new mode list back. Seems like a bad behaviour from the kernel, isn't it? It should return immediatly if the mode is gonna be pruned :s With the behaviour you are talking about, I should see 2 uevents when injecting one BAD link-state (first uevent generates a new modeset that will then generate a BAD state and another uevent, but this time the mode will have been pruned so when -modesetting tries to set the mode, it will fail immediatly). During my testing, I do not remember seeing such behaviour, so the kernel seemed to be doing the right thing from my PoV (failing a modeset to a mode that is known not to be achievable). I can verify tommorow, but it would be nice to make sure it is part of the ABI. As for re-fetching the modes, this is something the DE will do anyway when asking for them via randr. So, really, that will generate double probing in the common case for what seems to be a workaround. Given that probing can be a super expensive operation (request EDID from all monitors, potentially first starting up powered-down GPUs such as NVIDIA or AMD), I would say that probing should not be taken lightly. Isn't it possible to just return an error from the kernel if the mode should disapear? As far as my testing goes, this was already what seemed to be happening... but I may be wrong, especially since my DP monitor was fine with no link training whatsoever. What is the current ABI for the userspace requesting a mode from a previous monitor to a new one, because it did not reprobe? In any case, this is a good discussion to have! Remember that it could still not prune any mode if the same mode is valid with lower bpp, it will still keep the mode list same and when the userspace retries the same mode, it will do a modeset at lower bpp (say 18bpp) an
