[Bug 105481] New: radeon driver lockup since 3.9.*
https://bugzilla.kernel.org/show_bug.cgi?id=105481 Bug ID: 105481 Summary: radeon driver lockup since 3.9.* Product: Drivers Version: 2.5 Kernel Version: 4.2.2-1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: droidlove at ya.ru Regression: No Created attachment 189451 --> https://bugzilla.kernel.org/attachment.cgi?id=189451&action=edit dmesg output Since the Kernel 3.9.*(don't remember the last number of the version; maybe all of them) i get rare lockups of the radeon driver. The probability of a lockup is higher the more load on a graphic card. But this is not necessary. This time the driver hung while watching a video in SMPlayer. I can't reproduce the bug on purpose, it just happens from time to time, resulting in switched off monitors. Sometimes the kernel is trying to restore the driver but this never happens, resulting in endless switching on and off the monitors. Hardware: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cape Verde PRO [Radeon HD 7750/8740 / R7 250E] Thanks! -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH][RESEND] drm: panel-simple: add URT UMSH-8596MD-xT panel support
Hi Emil, Thanks for your response, On 04.10.2015 12:43, Emil Velikov wrote: > Hi Maciej, > > On 2 October 2015 at 22:40, Maciej S. Szmigiero > wrote: >> Anybody here? >> >> I've already submitted this patch two times but received no response... >> > Seems that the maintainer (Thierry) isn't Cc'ed. Yes, he was Cc'ed - see for example https://patchwork.ozlabs.org/patch/512858/ . > You might want to > split the DT binding and vendor prefix to separate patches. Do you mean to first submit new vendor prefix then panel patch with docs? Or even docs separately? > -Emil > Best regards, Maciej
[PATCH] drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl
The commit d931589c01a2 ("drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET
ioctl") removed it same with the ioctl that this patch adds. The reason
that removed DRM_EXYNOS_GEM_MAP_OFFSET was we could use
DRM_IOCTL_MODE_MAP_DUMB. Both did exactly same thing.
Now we again will revive it as DRM_EXYNOS_GEM_MAP because of render
node. DRM_IOCTL_MODE_MAP_DUMB isn't permitted in render node.
Signed-off-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 ++
drivers/gpu/drm/exynos/exynos_drm_gem.c | 9 +
drivers/gpu/drm/exynos/exynos_drm_gem.h | 4
include/uapi/drm/exynos_drm.h | 17 -
4 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index f0a5839..8fd7201 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -404,6 +404,8 @@ static const struct vm_operations_struct
exynos_drm_gem_vm_ops = {
static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_CREATE, exynos_drm_gem_create_ioctl,
DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
+ DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MAP, exynos_drm_gem_map_ioctl,
+ DRM_UNLOCKED | DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_GET, exynos_drm_gem_get_ioctl,
DRM_UNLOCKED | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_VIDI_CONNECTION, vidi_connection_ioctl,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index f1dcdd0..29f4875 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -271,6 +271,15 @@ int exynos_drm_gem_create_ioctl(struct drm_device *dev,
void *data,
return 0;
}
+int exynos_drm_gem_map_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv)
+{
+ struct drm_exynos_gem_map *args = data;
+
+ return exynos_drm_gem_dumb_map_offset(file_priv, dev, args->handle,
+ &args->offset);
+}
+
dma_addr_t *exynos_drm_gem_get_dma_addr(struct drm_device *dev,
unsigned int gem_handle,
struct drm_file *filp)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h
b/drivers/gpu/drm/exynos/exynos_drm_gem.h
index 37ab8b2..0d0ab27 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
@@ -73,6 +73,10 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct
drm_device *dev,
int exynos_drm_gem_create_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+/* get fake-offset of gem object that can be used with mmap. */
+int exynos_drm_gem_map_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv);
+
/*
* get dma address from gem handle and this function could be used for
* other drivers such as 2d/3d acceleration drivers.
diff --git a/include/uapi/drm/exynos_drm.h b/include/uapi/drm/exynos_drm.h
index 5575ed1..18f0601 100644
--- a/include/uapi/drm/exynos_drm.h
+++ b/include/uapi/drm/exynos_drm.h
@@ -33,6 +33,19 @@ struct drm_exynos_gem_create {
};
/**
+ * A structure for getting a fake-offset that can be used with mmap.
+ *
+ * @handle: handle of gem object.
+ * @reserved: just padding to be 64-bit aligned.
+ * @offset: a fake-offset of gem object.
+ */
+struct drm_exynos_gem_map {
+ __u32 handle;
+ __u32 reserved;
+ __u64 offset;
+};
+
+/**
* A structure to gem information.
*
* @handle: a handle to gem object created.
@@ -284,6 +297,7 @@ struct drm_exynos_ipp_cmd_ctrl {
};
#define DRM_EXYNOS_GEM_CREATE 0x00
+#define DRM_EXYNOS_GEM_MAP 0x01
/* Reserved 0x03 ~ 0x05 for exynos specific gem ioctl */
#define DRM_EXYNOS_GEM_GET 0x04
#define DRM_EXYNOS_VIDI_CONNECTION 0x07
@@ -301,7 +315,8 @@ struct drm_exynos_ipp_cmd_ctrl {
#define DRM_IOCTL_EXYNOS_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_GEM_CREATE, struct drm_exynos_gem_create)
-
+#define DRM_IOCTL_EXYNOS_GEM_MAP DRM_IOWR(DRM_COMMAND_BASE + \
+ DRM_EXYNOS_GEM_MAP, struct drm_exynos_gem_map)
#define DRM_IOCTL_EXYNOS_GEM_GET DRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_GEM_GET, struct drm_exynos_gem_info)
--
1.9.1
[Bug 91278] Tonga GPU lock/reset fail with Unigine Valley
https://bugs.freedesktop.org/show_bug.cgi?id=91278 --- Comment #26 from Michel Dänzer --- (In reply to Andy Furniss from comment #25) > I also see a new R600_DEBUG=check_vm in mesa. I don't know what, if any, > extra info is expected from that, but testing valley with it caused it to > quit when it hit a fault after a about minute of running - It should generate a file in ~/ddebug_dumps/ with more information about the VM fault. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/c343fca6/attachment.html>
[PATCH 1/2] drm/radeon: restore the fbdev mode in lastclose
On 03.10.2015 06:12, Alex Deucher wrote: > restore the fbdev state if a drm app like X is killed. > > Signed-off-by: Alex Deucher This patch is Tested-by: Michel Dänzer Both patches are Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer
[patch] drm/i915: unlock on error in i915_ppgtt_info()
On Fri, Oct 02, 2015 at 11:29:16PM +0800, Geliang Tang wrote:
> On Fri, Oct 02, 2015 at 06:14:22PM +0300, Dan Carpenter wrote:
> > We need to call intel_runtime_pm_put() and mutex_unlock() before
> > returning.
> >
> > Fixes: 7cb5dff8d59d ('drm/i915: fix task reference leak in i915_debugfs.c')
> > Signed-off-by: Dan Carpenter
>
> Acked-by: Geliang Tang
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 5/6] drm/sti: Build monolithic driver
Hi Thierry,
Ack-by: Vincent Abriou
BR
Vicnent
On 09/24/2015 07:02 PM, Thierry Reding wrote:
> From: Thierry Reding
>
> There's no use building the individual drivers as separate modules
> because they are all only useful if combined into a single DRM/KMS
> device.
>
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/sti/Makefile | 21 +
> drivers/gpu/drm/sti/sti_compositor.c | 4 +---
> drivers/gpu/drm/sti/sti_drv.c| 24 +++-
> drivers/gpu/drm/sti/sti_drv.h| 9 +
> drivers/gpu/drm/sti/sti_dvo.c| 2 --
> drivers/gpu/drm/sti/sti_hda.c| 2 --
> drivers/gpu/drm/sti/sti_hdmi.c | 2 --
> drivers/gpu/drm/sti/sti_hqvdp.c | 2 --
> drivers/gpu/drm/sti/sti_tvout.c | 2 --
> drivers/gpu/drm/sti/sti_vtac.c | 2 --
> drivers/gpu/drm/sti/sti_vtg.c| 2 --
> 11 files changed, 42 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/Makefile b/drivers/gpu/drm/sti/Makefile
> index e27490b492a5..b8057620b3b3 100644
> --- a/drivers/gpu/drm/sti/Makefile
> +++ b/drivers/gpu/drm/sti/Makefile
> @@ -1,26 +1,23 @@
> -sticompositor-y := \
> +sti-drm-y := \
> sti_mixer.o \
> sti_gdp.o \
> sti_vid.o \
> sti_cursor.o \
> sti_compositor.o \
> sti_crtc.o \
> - sti_plane.o
> -
> -stihdmi-y := sti_hdmi.o \
> + sti_plane.o \
> + sti_crtc.o \
> + sti_plane.o \
> + sti_hdmi.o \
> sti_hdmi_tx3g0c55phy.o \
> sti_hdmi_tx3g4c28phy.o \
> -
> -stidvo-y := sti_dvo.o \
> - sti_awg_utils.o
> -
> -obj-$(CONFIG_DRM_STI) = \
> + sti_dvo.o \
> + sti_awg_utils.o \
> sti_vtg.o \
> sti_vtac.o \
> - stihdmi.o \
> sti_hda.o \
> sti_tvout.o \
> - sticompositor.o \
> sti_hqvdp.o \
> - stidvo.o \
> sti_drv.o
> +
> +obj-$(CONFIG_DRM_STI) = sti-drm.o
> diff --git a/drivers/gpu/drm/sti/sti_compositor.c
> b/drivers/gpu/drm/sti/sti_compositor.c
> index c652627b1bca..afed2171beb9 100644
> --- a/drivers/gpu/drm/sti/sti_compositor.c
> +++ b/drivers/gpu/drm/sti/sti_compositor.c
> @@ -263,7 +263,7 @@ static int sti_compositor_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> -static struct platform_driver sti_compositor_driver = {
> +struct platform_driver sti_compositor_driver = {
> .driver = {
> .name = "sti-compositor",
> .of_match_table = compositor_of_match,
> @@ -272,8 +272,6 @@ static struct platform_driver sti_compositor_driver = {
> .remove = sti_compositor_remove,
> };
>
> -module_platform_driver(sti_compositor_driver);
> -
> MODULE_AUTHOR("Benjamin Gaignard ");
> MODULE_DESCRIPTION("STMicroelectronics SoC DRM driver");
> MODULE_LICENSE("GPL");
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index 9f85988a43ce..66f6e9864c99 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -287,7 +287,29 @@ static struct platform_driver sti_platform_driver = {
> },
> };
>
> -module_platform_driver(sti_platform_driver);
> +static struct platform_driver * const drivers[] = {
> + &sti_tvout_driver,
> + &sti_vtac_driver,
> + &sti_hqvdp_driver,
> + &sti_hdmi_driver,
> + &sti_hda_driver,
> + &sti_dvo_driver,
> + &sti_vtg_driver,
> + &sti_compositor_driver,
> + &sti_platform_driver,
> +};
> +
> +static int sti_drm_init(void)
> +{
> + return platform_register_drivers(drivers, ARRAY_SIZE(drivers));
> +}
> +module_init(sti_drm_init);
> +
> +static void sti_drm_exit(void)
> +{
> + platform_unregister_drivers(drivers, ARRAY_SIZE(drivers));
> +}
> +module_exit(sti_drm_exit);
>
> MODULE_AUTHOR("Benjamin Gaignard ");
> MODULE_DESCRIPTION("STMicroelectronics SoC DRM driver");
> diff --git a/drivers/gpu/drm/sti/sti_drv.h b/drivers/gpu/drm/sti/sti_drv.h
> index 9372f69e1859..30ddc20841c3 100644
> --- a/drivers/gpu/drm/sti/sti_drv.h
> +++ b/drivers/gpu/drm/sti/sti_drv.h
> @@ -32,4 +32,13 @@ struct sti_private {
> } commit;
> };
>
> +extern struct platform_driver sti_tvout_driver;
> +extern struct platform_driver sti_vtac_driver;
> +extern struct platform_driver sti_hqvdp_driver;
> +extern struct platform_driver sti_hdmi_driver;
> +extern struct platform_driver sti_hda_driver;
> +extern struct platform_driver sti_dvo_driver;
> +extern struct platform_driver sti_vtg_driver;
> +extern struct platform_driver sti_compositor_driver;
> +
> #endif
> diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
> index d141d645bd13..a619aa9e688d 100644
> --- a/drivers/gpu/drm/sti/sti_dvo.c
> +++ b/drivers/gpu/drm/sti/sti_dvo.c
> @@ -557,8 +557,6 @@ struct platform_driver sti_dvo_driver = {
> .remove = sti_dvo_remove,
> };
>
> -module_platform_driver(sti_dvo_driver);
> -
> MODULE_AUTHOR("Benjamin Gaignard ");
> MODULE_DESCRIPTION("STMicroelectronics So
[PATCH 6/6] drm/sti: Do not export symbols
Hi Thierry,
Ack-by: Vincent Abriou
BR
Vincent
On 09/24/2015 07:02 PM, Thierry Reding wrote:
> From: Thierry Reding
>
> None of these exported symbols are used outside of the drm-sti driver,
> so there is no reason to export them.
>
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/sti/sti_crtc.c | 3 ---
> drivers/gpu/drm/sti/sti_mixer.c | 1 -
> drivers/gpu/drm/sti/sti_plane.c | 3 ---
> drivers/gpu/drm/sti/sti_vtg.c | 6 --
> 4 files changed, 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
> index 87bb4096b9d7..342d8a617c6f 100644
> --- a/drivers/gpu/drm/sti/sti_crtc.c
> +++ b/drivers/gpu/drm/sti/sti_crtc.c
> @@ -318,7 +318,6 @@ int sti_crtc_enable_vblank(struct drm_device *dev,
> unsigned int pipe)
>
> return 0;
> }
> -EXPORT_SYMBOL(sti_crtc_enable_vblank);
>
> void sti_crtc_disable_vblank(struct drm_device *drm_dev, unsigned int pipe)
> {
> @@ -339,7 +338,6 @@ void sti_crtc_disable_vblank(struct drm_device *drm_dev,
> unsigned int pipe)
> compo->mixer[pipe]->pending_event = NULL;
> }
> }
> -EXPORT_SYMBOL(sti_crtc_disable_vblank);
>
> static struct drm_crtc_funcs sti_crtc_funcs = {
> .set_config = drm_atomic_helper_set_config,
> @@ -360,7 +358,6 @@ bool sti_crtc_is_main(struct drm_crtc *crtc)
>
> return false;
> }
> -EXPORT_SYMBOL(sti_crtc_is_main);
>
> int sti_crtc_init(struct drm_device *drm_dev, struct sti_mixer *mixer,
> struct drm_plane *primary, struct drm_plane *cursor)
> diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_mixer.c
> index 0182e9365004..4c18b50d71c5 100644
> --- a/drivers/gpu/drm/sti/sti_mixer.c
> +++ b/drivers/gpu/drm/sti/sti_mixer.c
> @@ -58,7 +58,6 @@ const char *sti_mixer_to_str(struct sti_mixer *mixer)
> return "";
> }
> }
> -EXPORT_SYMBOL(sti_mixer_to_str);
>
> static inline u32 sti_mixer_reg_read(struct sti_mixer *mixer, u32 reg_id)
> {
> diff --git a/drivers/gpu/drm/sti/sti_plane.c b/drivers/gpu/drm/sti/sti_plane.c
> index d5c5e91f2956..2e5c751910c5 100644
> --- a/drivers/gpu/drm/sti/sti_plane.c
> +++ b/drivers/gpu/drm/sti/sti_plane.c
> @@ -42,7 +42,6 @@ const char *sti_plane_to_str(struct sti_plane *plane)
> return "";
> }
> }
> -EXPORT_SYMBOL(sti_plane_to_str);
>
> static void sti_plane_destroy(struct drm_plane *drm_plane)
> {
> @@ -108,7 +107,6 @@ void sti_plane_init_property(struct sti_plane *plane,
>plane->drm_plane.base.id,
>sti_plane_to_str(plane), plane->zorder);
> }
> -EXPORT_SYMBOL(sti_plane_init_property);
>
> struct drm_plane_funcs sti_plane_helpers_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> @@ -119,4 +117,3 @@ struct drm_plane_funcs sti_plane_helpers_funcs = {
> .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
> };
> -EXPORT_SYMBOL(sti_plane_helpers_funcs);
> diff --git a/drivers/gpu/drm/sti/sti_vtg.c b/drivers/gpu/drm/sti/sti_vtg.c
> index d8bd8b76b1fa..d56630c60039 100644
> --- a/drivers/gpu/drm/sti/sti_vtg.c
> +++ b/drivers/gpu/drm/sti/sti_vtg.c
> @@ -110,7 +110,6 @@ struct sti_vtg *of_vtg_find(struct device_node *np)
> }
> return NULL;
> }
> -EXPORT_SYMBOL(of_vtg_find);
>
> static void vtg_reset(struct sti_vtg *vtg)
> {
> @@ -242,7 +241,6 @@ void sti_vtg_set_config(struct sti_vtg *vtg,
> else
> vtg_enable_irq(vtg);
> }
> -EXPORT_SYMBOL(sti_vtg_set_config);
>
> /**
>* sti_vtg_get_line_number
> @@ -265,7 +263,6 @@ u32 sti_vtg_get_line_number(struct drm_display_mode mode,
> int y)
>
> return start_line + y;
> }
> -EXPORT_SYMBOL(sti_vtg_get_line_number);
>
> /**
>* sti_vtg_get_pixel_number
> @@ -281,7 +278,6 @@ u32 sti_vtg_get_pixel_number(struct drm_display_mode
> mode, int x)
> {
> return mode.htotal - mode.hsync_start + x;
> }
> -EXPORT_SYMBOL(sti_vtg_get_pixel_number);
>
> int sti_vtg_register_client(struct sti_vtg *vtg, struct notifier_block *nb,
> struct drm_crtc *crtc)
> @@ -292,7 +288,6 @@ int sti_vtg_register_client(struct sti_vtg *vtg, struct
> notifier_block *nb,
> vtg->crtc = crtc;
> return raw_notifier_chain_register(&vtg->notifier_list, nb);
> }
> -EXPORT_SYMBOL(sti_vtg_register_client);
>
> int sti_vtg_unregister_client(struct sti_vtg *vtg, struct notifier_block
> *nb)
> {
> @@ -301,7 +296,6 @@ int sti_vtg_unregister_client(struct sti_vtg *vtg, struct
> notifier_block *nb)
>
> return raw_notifier_chain_unregister(&vtg->notifier_list, nb);
> }
> -EXPORT_SYMBOL(sti_vtg_unregister_client);
>
> static irqreturn_t vtg_irq_thread(int irq, void *arg)
> {
>
[Bug 91278] Tonga GPU lock/reset fail with Unigine Valley
https://bugs.freedesktop.org/show_bug.cgi?id=91278 --- Comment #27 from Andy Furniss --- Created attachment 118665 --> https://bugs.freedesktop.org/attachment.cgi?id=118665&action=edit valley vm fault dump Aha, here it is. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/ba9a4254/attachment-0001.html>
[Bug 92220] GL_NV_vdpau_interop partially available
https://bugs.freedesktop.org/show_bug.cgi?id=92220 Christian König changed: What|Removed |Added Priority|medium |low Severity|normal |enhancement --- Comment #11 from Christian König --- (In reply to riaasm from comment #10) > If so, userspace apps that only need frame-based interop can just check if > UVD is available since it should work on any UVD hardware. And userspace > apps that need field-based interop can check for the GL extension. Would > this be a reasonable and correct way to check for interop functionality That's what Alex suggest with his option number 3. E.g. write a new extension that allows application to query if a subset of GL_NV_vdpau_interop is supported. But since this only applies to rather old hardware nobody is probably going to do so. Option number 2 is actually rather easily doable as well, cause we already have most shaders for this available. Maybe fifty lines of code after all. But again, rather old hardware and so nobody of the devs interested in fixing this. If you are interested in coding this I can easily give you the hints where to look at. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/b43f891e/attachment.html>
WARNING: CPU: 4 PID: 863 at include/drm/drm_crtc.h:1577 drm_helper_choose_encoder_dpms+0x88/0x90() - evildoer found and neutralized
Hi Jiang,
On Sat, Oct 03, 2015 at 03:36:35PM +0800, Jiang Liu wrote:
> So to summary, I think we only need following change to fix the
> regression:
> int pcibios_alloc_irq(struct pci_dev *dev)
> {
> + if (pci_dev_msi_enabled(dev))
> + return -EBUSY;
>
> What do you think?
Yes, that works too and has the added benefit that no driver can attach
to the iommu device and get in the way of the driver.
Will you send the patch for this change or should I do it?
Joerg
5K iMac retina multi stream display port
On 4 October 2015 at 21:36, Andreas Tunek wrote: > 2015-10-04 13:31 GMT+02:00 Andreas Tunek : >> 2015-10-04 13:26 GMT+02:00 Andreas Tunek : >>> 2015-10-04 6:31 GMT+02:00 Dave Airlie : On 3 October 2015 at 04:03, Andreas Tunek wrote: > Hi > > I sort of recall that somebody (Dave Airlied) work on this in order to > get the full 5K from a retina iMac. Was that work finished or is that > coming in 4.3 or later? Or was it abandoned? Or maybe I am not > remembering correctly? you can try a 4.2 kernel with radeon.mst=1 I've no idea if it will work. >>> >>> Didn't seem to have any effect. Is this a correct boot env: >>> [ >>> root at iMacLinux tuna]# cat /proc/cmdline >>> BOOT_IMAGE=/vmlinuz-4.2.1-300.fc23.x86_64 >>> root=UUID=e3e65337-b654-495f-b7c1-0212e1fd0797 ro rhgb quiet >>> LANG=en_US.UTF-8 radeon.mst=1 >>> Dave. >> >> Sorry for replying again, but you wrote some stuff in February*, did >> you test with an iMac or some other 5K screen then? >> >> http://thread.gmane.org/gmane.comp.video.dri.devel/124345 >> >> Best regards >> Andreas No I never tested anything on an imac 5K. Can you boot with drm.debug=6 radeon.mst=1 and post the dmesg logfile? I'm not sure if the 5K mode on these would need to be reverse engineered there is definitely some trickery involved. Dave.
[PATCH v4 0/2] RFC: Secure Memory Allocation Framework
version 4 changes:
- rebased on kernel 4.3-rc3
- fix missing EXPORT_SYMBOL for smaf_create_handle()
version 3 changes:
- Remove ioctl for allocator selection instead provide the name of
the targeted allocator with allocation request.
Selecting allocator from userland isn't the prefered way of working
but is needed when the first user of the buffer is a software component.
- Fix issues in case of error while creating smaf handle.
- Fix module license.
- Update libsmaf and tests to care of the SMAF API evolution
https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
version 2 changes:
- Add one ioctl to allow allocator selection from userspace.
This is required for the uses case where the first user of
the buffer is a software IP which can't perform dma_buf attachement.
- Add name and ranking to allocator structure to be able to sort them.
- Create a tiny library to test SMAF:
https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
- Fix one issue when try to secure buffer without secure module registered
The outcome of the previous RFC about how do secure data path was the need
of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
SMAF goal is to provide a framework that allow allocating and securing
memory by using dma_buf. Each platform have it own way to perform those two
features so SMAF design allow to register helper modules to perform them.
To be sure to select the best allocation method for devices SMAF implement
deferred allocation mechanism: memory allocation is only done when the first
device effectively required it.
Allocator modules have to implement a match() to let SMAF know if they are
compatibles with devices needs.
This patch set provide an example of allocator module which use
dma_{alloc/free/mmap}_attrs() and check if at least one device have
coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if
a better name could be found for this file.
Secure modules are responsibles of granting and revoking devices access rights
on the memory. Secure module is also called to check if CPU map memory into
kernel and user address spaces.
An example of secure module implementation can be found here:
http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
This code isn't yet part of the patch set because it depends on generic TEE
which is still under discussion (https://lwn.net/Articles/644646/)
For allocation part of SMAF code I get inspirated by Sumit Semwal work about
constraint aware allocator.
Benjamin Gaignard (2):
create SMAF module
SMAF: add CMA allocator
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/smaf/Kconfig | 11 +
drivers/smaf/Makefile | 2 +
drivers/smaf/smaf-cma.c| 200 +++
drivers/smaf/smaf-core.c | 736 +
include/linux/smaf-allocator.h | 54 +++
include/linux/smaf-secure.h| 72
include/uapi/linux/smaf.h | 52 +++
9 files changed, 1130 insertions(+)
create mode 100644 drivers/smaf/Kconfig
create mode 100644 drivers/smaf/Makefile
create mode 100644 drivers/smaf/smaf-cma.c
create mode 100644 drivers/smaf/smaf-core.c
create mode 100644 include/linux/smaf-allocator.h
create mode 100644 include/linux/smaf-secure.h
create mode 100644 include/uapi/linux/smaf.h
--
1.9.1
[PATCH v4 1/2] create SMAF module
Secure Memory Allocation Framework goal is to be able
to allocate memory that can be securing.
There is so much ways to allocate and securing memory that SMAF
doesn't do it by itself but need help of additional modules.
To be sure to use the correct allocation method SMAF implement
deferred allocation (i.e. allocate memory when only really needed)
Allocation modules (smaf-alloctor.h):
SMAF could manage with multiple allocation modules at same time.
To select the good one SMAF call match() to be sure that a module
can allocate memory for a given list of devices. It is to the module
to check if the devices are compatible or not with it allocation
method.
Securing module (smaf-secure.h):
The way of how securing memory it is done is platform specific.
Secure module is responsible of grant/revoke memory access.
Signed-off-by: Benjamin Gaignard
---
drivers/Kconfig| 2 +
drivers/Makefile | 1 +
drivers/smaf/Kconfig | 5 +
drivers/smaf/Makefile | 1 +
drivers/smaf/smaf-core.c | 736 +
include/linux/smaf-allocator.h | 54 +++
include/linux/smaf-secure.h| 72
include/uapi/linux/smaf.h | 52 +++
8 files changed, 923 insertions(+)
create mode 100644 drivers/smaf/Kconfig
create mode 100644 drivers/smaf/Makefile
create mode 100644 drivers/smaf/smaf-core.c
create mode 100644 include/linux/smaf-allocator.h
create mode 100644 include/linux/smaf-secure.h
create mode 100644 include/uapi/linux/smaf.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 46b4a8e..a488c20 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -188,4 +188,6 @@ source "drivers/nvdimm/Kconfig"
source "drivers/nvmem/Kconfig"
+source "drivers/smaf/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index b250b36..693390b 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -167,3 +167,4 @@ obj-$(CONFIG_THUNDERBOLT) += thunderbolt/
obj-$(CONFIG_CORESIGHT)+= hwtracing/coresight/
obj-$(CONFIG_ANDROID) += android/
obj-$(CONFIG_NVMEM)+= nvmem/
+obj-$(CONFIG_SMAF) += smaf/
diff --git a/drivers/smaf/Kconfig b/drivers/smaf/Kconfig
new file mode 100644
index 000..d36651a
--- /dev/null
+++ b/drivers/smaf/Kconfig
@@ -0,0 +1,5 @@
+config SMAF
+ tristate "Secure Memory Allocation Framework"
+ depends on DMA_SHARED_BUFFER
+ help
+ Choose this option to enable Secure Memory Allocation Framework
diff --git a/drivers/smaf/Makefile b/drivers/smaf/Makefile
new file mode 100644
index 000..40cd882
--- /dev/null
+++ b/drivers/smaf/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SMAF) += smaf-core.o
diff --git a/drivers/smaf/smaf-core.c b/drivers/smaf/smaf-core.c
new file mode 100644
index 000..37914e7
--- /dev/null
+++ b/drivers/smaf/smaf-core.c
@@ -0,0 +1,736 @@
+/*
+ * smaf.c
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard for Linaro.
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct smaf_handle {
+ struct dma_buf *dmabuf;
+ struct smaf_allocator *allocator;
+ struct dma_buf *db_alloc;
+ size_t length;
+ unsigned int flags;
+ int fd;
+ bool is_secure;
+ void *secure_ctx;
+};
+
+/**
+ * struct smaf_device - smaf device node private data
+ * @misc_dev: the misc device
+ * @head: list of allocator
+ * @lock: list and secure pointer mutex
+ * @secure:pointer to secure functions helpers
+ */
+struct smaf_device {
+ struct miscdevice misc_dev;
+ struct list_head head;
+ /* list and secure pointer lock*/
+ struct mutex lock;
+ struct smaf_secure *secure;
+};
+
+static struct smaf_device smaf_dev;
+
+/**
+ * smaf_allow_cpu_access return true if CPU can access to memory
+ * if their is no secure module associated to SMAF assume that CPU can get
+ * access to the memory.
+ */
+static bool smaf_allow_cpu_access(struct smaf_handle *handle,
+ unsigned long flags)
+{
+ if (!handle->is_secure)
+ return true;
+
+ if (!smaf_dev.secure)
+ return true;
+
+ if (!smaf_dev.secure->allow_cpu_access)
+ return true;
+
+ return smaf_dev.secure->allow_cpu_access(handle->secure_ctx, flags);
+}
+
+static int smaf_grant_access(struct smaf_handle *handle, struct device *dev,
+dma_addr_t addr, size_t size,
+enum dma_data_direction dir)
+{
+ if (!handle->is_secure)
+ return 0;
+
+ if (!smaf_dev.secure)
+ return -EINVAL;
+
+ if (!smaf_dev.secure->grant_access)
+ return -EINVAL;
+
+ return smaf_dev.secure->grant_access(handle->secure_ctx,
+
[PATCH v4 2/2] SMAF: add CMA allocator
SMAF CMA allocator implement helpers functions to allow SMAF
to allocate contiguous memory.
match() each if at least one of the attached devices have coherent_dma_mask
set to DMA_BIT_MASK(32).
For allocation it use dma_alloc_attrs() with DMA_ATTR_WRITE_COMBINE and not
dma_alloc_writecombine to be compatible with ARM 64bits architecture
Signed-off-by: Benjamin Gaignard
---
drivers/smaf/Kconfig| 6 ++
drivers/smaf/Makefile | 1 +
drivers/smaf/smaf-cma.c | 200
3 files changed, 207 insertions(+)
create mode 100644 drivers/smaf/smaf-cma.c
diff --git a/drivers/smaf/Kconfig b/drivers/smaf/Kconfig
index d36651a..058ec4c 100644
--- a/drivers/smaf/Kconfig
+++ b/drivers/smaf/Kconfig
@@ -3,3 +3,9 @@ config SMAF
depends on DMA_SHARED_BUFFER
help
Choose this option to enable Secure Memory Allocation Framework
+
+config SMAF_CMA
+ tristate "SMAF CMA allocator"
+ depends on SMAF && HAVE_DMA_ATTRS
+ help
+ Choose this option to enable CMA allocation within SMAF
diff --git a/drivers/smaf/Makefile b/drivers/smaf/Makefile
index 40cd882..05bab01 100644
--- a/drivers/smaf/Makefile
+++ b/drivers/smaf/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_SMAF) += smaf-core.o
+obj-$(CONFIG_SMAF_CMA) += smaf-cma.o
diff --git a/drivers/smaf/smaf-cma.c b/drivers/smaf/smaf-cma.c
new file mode 100644
index 000..ab38717
--- /dev/null
+++ b/drivers/smaf/smaf-cma.c
@@ -0,0 +1,200 @@
+/*
+ * smaf-cma.c
+ *
+ * Copyright (C) Linaro SA 2015
+ * Author: Benjamin Gaignard for Linaro.
+ * License terms: GNU General Public License (GPL), version 2
+ */
+
+#include
+#include
+#include
+#include
+
+struct smaf_cma_buffer_info {
+ struct device *dev;
+ size_t size;
+ void *vaddr;
+ dma_addr_t paddr;
+};
+
+/**
+ * find_matching_device - iterate over the attached devices to find one
+ * with coherent_dma_mask correctly set to DMA_BIT_MASK(32).
+ * Matching device (if any) will be used to aim CMA area.
+ */
+static struct device *find_matching_device(struct dma_buf *dmabuf)
+{
+ struct dma_buf_attachment *attach_obj;
+
+ list_for_each_entry(attach_obj, &dmabuf->attachments, node) {
+ if (attach_obj->dev->coherent_dma_mask == DMA_BIT_MASK(32))
+ return attach_obj->dev;
+ }
+
+ return NULL;
+}
+
+/**
+ * smaf_cma_match - return true if at least one device has been found
+ */
+static bool smaf_cma_match(struct dma_buf *dmabuf)
+{
+ return !!find_matching_device(dmabuf);
+}
+
+static void smaf_cma_release(struct dma_buf *dmabuf)
+{
+ struct smaf_cma_buffer_info *info = dmabuf->priv;
+ DEFINE_DMA_ATTRS(attrs);
+
+ dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+
+ dma_free_attrs(info->dev, info->size, info->vaddr, info->paddr, &attrs);
+
+ kfree(info);
+}
+
+static struct sg_table *smaf_cma_map(struct dma_buf_attachment *attachment,
+enum dma_data_direction direction)
+{
+ struct smaf_cma_buffer_info *info = attachment->dmabuf->priv;
+ struct sg_table *sgt;
+ int ret;
+
+ sgt = kzalloc(sizeof(*sgt), GFP_KERNEL);
+ if (!sgt)
+ return NULL;
+
+ ret = dma_get_sgtable(info->dev, sgt, info->vaddr,
+ info->paddr, info->size);
+ if (ret < 0)
+ goto out;
+
+ sg_dma_address(sgt->sgl) = info->paddr;
+ return sgt;
+
+out:
+ kfree(sgt);
+ return NULL;
+}
+
+static void smaf_cma_unmap(struct dma_buf_attachment *attachment,
+ struct sg_table *sgt,
+ enum dma_data_direction direction)
+{
+ /* do nothing */
+}
+
+static int smaf_cma_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
+{
+ struct smaf_cma_buffer_info *info = dmabuf->priv;
+ int ret;
+ DEFINE_DMA_ATTRS(attrs);
+
+ dma_set_attr(DMA_ATTR_WRITE_COMBINE, &attrs);
+
+ if (info->size < vma->vm_end - vma->vm_start)
+ return -EINVAL;
+
+ vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP;
+ ret = dma_mmap_attrs(info->dev, vma, info->vaddr, info->paddr,
+info->size, &attrs);
+
+ return ret;
+}
+
+static void *smaf_cma_vmap(struct dma_buf *dmabuf)
+{
+ struct smaf_cma_buffer_info *info = dmabuf->priv;
+
+ return info->vaddr;
+}
+
+static void *smaf_kmap_atomic(struct dma_buf *dmabuf, unsigned long offset)
+{
+ struct smaf_cma_buffer_info *info = dmabuf->priv;
+
+ return (void *)info->paddr + offset;
+}
+
+static struct dma_buf_ops smaf_cma_ops = {
+ .map_dma_buf = smaf_cma_map,
+ .unmap_dma_buf = smaf_cma_unmap,
+ .mmap = smaf_cma_mmap,
+ .release = smaf_cma_release,
+ .kmap_atomic = smaf_kmap_atomic,
+ .kmap = smaf_kmap_atomic,
+ .vmap = smaf_cma_vmap,
+};
+
+static struct dma_buf *smaf_cma_allocate(struct
[PATCH] qxl: fix framebuffer dirty rectangle tracking.
Commit "c0fe07a drm/qxl: rewrite framebuffer support" has a bug in the
dirty rectangle tracking: Instead of ignoring an empty dirty rectangle
when adding a new dirty region the dirty region gets extended to the
upper left corner. Fix it.
Cc: linux-stable at vger.kernel.org
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_fb.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
index 2bbe6b8..f2f6d11 100644
--- a/drivers/gpu/drm/qxl/qxl_fb.c
+++ b/drivers/gpu/drm/qxl/qxl_fb.c
@@ -144,14 +144,17 @@ static void qxl_dirty_update(struct qxl_fbdev *qfbdev,
spin_lock_irqsave(&qfbdev->dirty.lock, flags);
- if (qfbdev->dirty.y1 < y)
- y = qfbdev->dirty.y1;
- if (qfbdev->dirty.y2 > y2)
- y2 = qfbdev->dirty.y2;
- if (qfbdev->dirty.x1 < x)
- x = qfbdev->dirty.x1;
- if (qfbdev->dirty.x2 > x2)
- x2 = qfbdev->dirty.x2;
+ if ((qfbdev->dirty.y2 - qfbdev->dirty.y1) &&
+ (qfbdev->dirty.x2 - qfbdev->dirty.x1)) {
+ if (qfbdev->dirty.y1 < y)
+ y = qfbdev->dirty.y1;
+ if (qfbdev->dirty.y2 > y2)
+ y2 = qfbdev->dirty.y2;
+ if (qfbdev->dirty.x1 < x)
+ x = qfbdev->dirty.x1;
+ if (qfbdev->dirty.x2 > x2)
+ x2 = qfbdev->dirty.x2;
+ }
qfbdev->dirty.x1 = x;
qfbdev->dirty.x2 = x2;
--
1.8.3.1
[PATCH v4 2/2] SMAF: add CMA allocator
Hi Benjamin, [auto build test WARNING on v4.3-rc4 -- if it's inappropriate base, please ignore] reproduce: # apt-get install sparse make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/smaf/smaf-cma.c:178:23: sparse: symbol 'smaf_cma' was not declared. >> Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation
[RFC PATCH] SMAF: smaf_cma can be static
Signed-off-by: Fengguang Wu
---
smaf-cma.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/smaf/smaf-cma.c b/drivers/smaf/smaf-cma.c
index ab38717..9fbd9b7 100644
--- a/drivers/smaf/smaf-cma.c
+++ b/drivers/smaf/smaf-cma.c
@@ -175,7 +175,7 @@ error:
return NULL;
}
-struct smaf_allocator smaf_cma = {
+static struct smaf_allocator smaf_cma = {
.match = smaf_cma_match,
.allocate = smaf_cma_allocate,
.name = "smaf-cma",
[PATCH][RESEND] drm: panel-simple: add URT UMSH-8596MD-xT panel support
On Mon, Oct 05, 2015 at 01:33:49AM +0200, Maciej S. Szmigiero wrote: > Hi Emil, > > Thanks for your response, > > On 04.10.2015 12:43, Emil Velikov wrote: > > Hi Maciej, > > > > On 2 October 2015 at 22:40, Maciej S. Szmigiero > > wrote: > >> Anybody here? > >> > >> I've already submitted this patch two times but received no response... > >> > > Seems that the maintainer (Thierry) isn't Cc'ed. > > Yes, he was Cc'ed - see for example > https://patchwork.ozlabs.org/patch/512858/ . Sorry, I never received any of your earlier patches. It's in none of my mailboxes nor was it classified as spam. Even searching by message ID doesn't give me a positive hit. > > You might want to > > split the DT binding and vendor prefix to separate patches. > > Do you mean to first submit new vendor prefix then panel patch with docs? > Or even docs separately? This should be three patches: the vendor prefix is usually a separate patch and needs an Acked-by from one of the device tree bindings maintainers. The binding itself should also be a separate patch and the driver changes should come last. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/718e1d05/attachment.sig>
[PATCH][RESEND] drm: panel-simple: add URT UMSH-8596MD-xT panel support
On Fri, Oct 02, 2015 at 11:40:16PM +0200, Maciej S. Szmigiero wrote: > Anybody here? > > I've already submitted this patch two times but received no response... > > Maciej Szmigiero > > On 01.09.2015 15:50, Maciej S. Szmigiero wrote: > > This patch adds support for United Radiant Technology > > UMSH-8596MD-xT 7.0" WVGA TFT LCD panels > > (both LVDS and parallel versions) to DRM > > panel-simple driver. > > > > Signed-off-by: Maciej Szmigiero > > --- > > This is a resend without changes. > > > > diff --git a/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt > > b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt > > new file mode 100644 > > index 000..2990e6b > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt > > @@ -0,0 +1,11 @@ > > +United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel > > + > > +Supported are LVDS versions (-11T, -19T) and parallel ones > > +(-T, -1T, -7T, -20T). Please don't use this kind of wildcard compatible values. If these are different models then each of them deserves a separate compatible string. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/b0f4dcdf/attachment.sig>
[Bug 92220] GL_NV_vdpau_interop partially available
https://bugs.freedesktop.org/show_bug.cgi?id=92220 --- Comment #12 from riaasm at yahoo.com --- I think option 3 would be the most suitable solution, since this would advertise exactly what the hardware does. I'm not sure if this is practical though, since it seems to me like creating a new GL extension would be a lot of administrative work. But in all fairness, I have no idea what's involved in this. I'm not sure it would be wise to emulate some hardware functionality in software (option 2), mostly because I don't see the need for "faking it". Just let the hardware say what it can and can not do, so the higher-level application can use it appropriately. Also, I have no idea how to do this anyway, so I can't really help with that. I also wanted to mention that the interop specs (https://www.opengl.org/registry/specs/NV/vdpau_interop.txt) seem to indicate that the GL_NV_vdpau_interop extension is actually supposed to be field based, not frame-based. Maybe I'm not reading it correctly or maybe the frame-based solution was added to the implementation. Either way, if the GL extension is really supposed to be field-based, it might even be useful for newer hardware (as well as older hardware) to have a separate GL extension for the frame-based solution (maybe GL_NV_vdpau_interop_frame, with the current one being for field interop only). This way it would match more closely to the specification of each GL extension. For most newer hardware, this means that both GL extensions would be enabled and it would be clear that the hardware supports both field and frame interop. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/b335303b/attachment-0001.html>
[PATCH v4 2/2] SMAF: add CMA allocator
Hi Benjamin,
[auto build test WARNING on v4.3-rc4 -- if it's inappropriate base, please
ignore]
config: sparc-allmodconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc
All warnings (new ones prefixed by >>):
drivers/smaf/smaf-cma.c: In function 'smaf_kmap_atomic':
>> drivers/smaf/smaf-cma.c:118:9: warning: cast to pointer from integer of
>> different size [-Wint-to-pointer-cast]
return (void *)info->paddr + offset;
^
vim +118 drivers/smaf/smaf-cma.c
102 info->size, &attrs);
103
104 return ret;
105 }
106
107 static void *smaf_cma_vmap(struct dma_buf *dmabuf)
108 {
109 struct smaf_cma_buffer_info *info = dmabuf->priv;
110
111 return info->vaddr;
112 }
113
114 static void *smaf_kmap_atomic(struct dma_buf *dmabuf, unsigned long
offset)
115 {
116 struct smaf_cma_buffer_info *info = dmabuf->priv;
117
> 118 return (void *)info->paddr + offset;
119 }
120
121 static struct dma_buf_ops smaf_cma_ops = {
122 .map_dma_buf = smaf_cma_map,
123 .unmap_dma_buf = smaf_cma_unmap,
124 .mmap = smaf_cma_mmap,
125 .release = smaf_cma_release,
126 .kmap_atomic = smaf_kmap_atomic,
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 43420 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/d5e5d761/attachment-0001.obj>
[Bug 92220] GL_NV_vdpau_interop partially available
https://bugs.freedesktop.org/show_bug.cgi?id=92220 --- Comment #13 from Peter Frühberger --- If I was to decide, I would suggest: >2. Add an extra step to the drivers using shaders to split the frame up into >>separate fields in vlVdpVideoSurfaceGallium >(src/gallium/state_trackers/vdpau/surface.c) for chips that don't support >field >based decode. This adds an extra copy and someone needs to write the >code. With >that done, the extension can be enabled on all asics. Reason: - No application needs to be changed and all methods would be supported by this hardware, too. - Our workarounds + extra code to handle the env would also easily be 50+ lines :-) and that per application (kodi, mpv, ...) So @Christian happy for pointers on how to get it going. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/01dd6978/attachment.html>
[PATCH 1/2] drm/radeon: restore the fbdev mode in lastclose
On 05.10.2015 08:30, Michel Dänzer wrote: > On 03.10.2015 06:12, Alex Deucher wrote: >> restore the fbdev state if a drm app like X is killed. >> >> Signed-off-by: Alex Deucher > This patch is > > Tested-by: Michel Dänzer > > Both patches are > > Reviewed-by: Michel Dänzer > > For both Reviewed-by: Christian König
[PATCH v3 1/6] vga_switcheroo: Add support for switching only the DDC
Originally by Seth Forshee , 2012-10-04:
During graphics driver initialization it's useful to be able to mux
only the DDC to the inactive client in order to read the EDID. Add
a switch_ddc callback to allow capable handlers to provide this
functionality, and add vga_switcheroo_switch_ddc() to allow DRM
to mux only the DDC.
Modified by Dave Airlie , 2012-12-22:
I can't figure out why I didn't like this, but I rewrote this [...]
to lock/unlock the ddc lines [...]. I think I'd prefer something
like that otherwise the interface got really ugly.
Modified by Lukas Wunner , 2015-08-14:
Don't lock vgasr_mutex in _lock_ddc() / _unlock_ddc(), it can cause
deadlocks because (a) during switch (with vgasr_mutex already held),
GPU is woken and probes its outputs, tries to re-acquire vgasr_mutex
to lock DDC lines; (b) Likewise during switch, GPU is suspended and
calls cancel_delayed_work_sync() to stop output polling, if poll
task is running at this moment we may wait forever for it to finish.
Instead, lock ddc_lock when unregistering the handler because the
only reason why we'd want to lock vgasr_mutex in _lock_ddc() /
_unlock_ddc() is to block the handler from disappearing while DDC
lines are switched.
Also lock ddc_lock in stage2 to avoid race condition where reading
the EDID and switching happens simultaneously. Likewise on MIGD /
MDIS commands and on runtime suspend.
Retain semantics of ->switchto handler callback to switch all pins,
including DDC. Change semantics of ->switch_ddc handler callback to
return previous DDC owner. Original version tried to determine
previous DDC owner with find_active_client() but this fails if the
inactive client registers before the active client.
v2.1: Overhaul locking, squash commits
(requested by Daniel Vetter )
v2.2: Readability improvements
(requested by Thierry Reding )
v2.3: Overhaul locking once more
v2.4: Retain semantics of ->switchto handler callback to switch all pins
(requested by Daniel Vetter )
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Pierre Moreau
[MBP 5,3 2009 nvidia MCP79 + G96pre-retina 15"]
Tested-by: William Brown
[MBP 8,2 2011 intel SNB + amd turks pre-retina 15"]
Tested-by: Lukas Wunner
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"]
Cc: Seth Forshee
Cc: Dave Airlie
Signed-off-by: Lukas Wunner
---
drivers/gpu/vga/vga_switcheroo.c | 98 +++-
include/linux/vga_switcheroo.h | 9
2 files changed, 105 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index aa077aa..9b6946e 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -73,9 +73,19 @@
* there can thus be up to three clients: Two vga clients (GPUs) and one audio
* client (on the discrete GPU). The code is mostly prepared to support
* machines with more than two GPUs should they become available.
+ *
* The GPU to which the outputs are currently switched is called the
* active client in vga_switcheroo parlance. The GPU not in use is the
- * inactive client.
+ * inactive client. When the inactive client's DRM driver is loaded,
+ * it will be unable to probe the panel's EDID and hence depends on
+ * VBIOS to provide its display modes. If the VBIOS modes are bogus or
+ * if there is no VBIOS at all (which is common on the MacBook Pro),
+ * a client may alternatively request that the DDC lines are temporarily
+ * switched to it, provided that the handler supports this. Switching
+ * only the DDC lines and not the entire output avoids unnecessary
+ * flickering. On machines which are able to mux external connectors,
+ * VBIOS cannot know of attached displays so switching the DDC lines
+ * is the only option to retrieve the displays' EDID.
*/
/**
@@ -125,6 +135,8 @@ static DEFINE_MUTEX(vgasr_mutex);
* (counting only vga clients, not audio clients)
* @clients: list of registered clients
* @handler: registered handler
+ * @ddc_lock: protects access to DDC lines while they are temporarily switched
+ * @old_ddc_owner: client to which DDC lines will be switched back on unlock
*
* vga_switcheroo private data. Currently only one vga_switcheroo instance
* per system is supported.
@@ -141,6 +153,8 @@ struct vgasr_priv {
struct list_head clients;
struct vga_switcheroo_handler *handler;
+ struct mutex ddc_lock;
+ int old_ddc_owner;
};
#define ID_BIT_AUDIO 0x100
@@ -155,6 +169,7 @@ static void vga_switcheroo_debugfs_fini(struct vgasr_priv
*priv);
/* only one switcheroo per system */
static struct vgasr_priv vgasr_priv = {
.clients = LIST_HEAD_INIT(vgasr_priv.clients),
+ .ddc_lock = __MUTEX_INITIALIZER(vgasr_priv.ddc_lock),
};
static bool vga_
[PATCH v3 2/6] apple-gmux: Add switch_ddc support
Originally by Seth Forshee , 2012-10-04:
The gmux allows muxing the DDC independently from the display, so
support this functionality. This will allow reading the EDID for the
inactive GPU, fixing issues with machines that either don't have a
VBT or have invalid mode data in the VBT.
Modified by Lukas Wunner , 2015-08-28:
Retain semantics of ->switchto handler callback to switch all pins,
including DDC. Change semantics of ->switch_ddc handler callback to
return previous DDC owner. Original version tried to determine
previous DDC owner with find_active_client() in vga_switcheroo but
this fails if the inactive client registers before the active
client.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Pierre Moreau
[MBP 5,3 2009 nvidia MCP79 + G96pre-retina 15"]
Tested-by: William Brown
[MBP 8,2 2011 intel SNB + amd turks pre-retina 15"]
Tested-by: Lukas Wunner
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"]
Cc: Seth Forshee
Signed-off-by: Lukas Wunner
---
drivers/platform/x86/apple-gmux.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/platform/x86/apple-gmux.c
b/drivers/platform/x86/apple-gmux.c
index 0dec3f5..5bb231b 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -273,6 +273,28 @@ static const struct backlight_ops gmux_bl_ops = {
.update_status = gmux_update_status,
};
+static int gmux_switch_ddc(enum vga_switcheroo_client_id id)
+{
+ enum vga_switcheroo_client_id old_ddc_owner;
+
+ if (gmux_read8(apple_gmux_data, GMUX_PORT_SWITCH_DDC) == 1)
+ old_ddc_owner = VGA_SWITCHEROO_IGD;
+ else
+ old_ddc_owner = VGA_SWITCHEROO_DIS;
+
+ pr_debug("Switching gmux DDC from %d to %d\n", old_ddc_owner, id);
+
+ if (id == old_ddc_owner)
+ return old_ddc_owner;
+
+ if (id == VGA_SWITCHEROO_IGD)
+ gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 1);
+ else
+ gmux_write8(apple_gmux_data, GMUX_PORT_SWITCH_DDC, 2);
+
+ return old_ddc_owner;
+}
+
static int gmux_switchto(enum vga_switcheroo_client_id id)
{
if (id == VGA_SWITCHEROO_IGD) {
@@ -348,6 +370,7 @@ gmux_active_client(struct apple_gmux_data *gmux_data)
static struct vga_switcheroo_handler gmux_handler = {
.switchto = gmux_switchto,
+ .switch_ddc = gmux_switch_ddc,
.power_state = gmux_set_power_state,
.get_client_id = gmux_get_client_id,
};
--
1.8.5.2 (Apple Git-48)
[PATCH v3 3/6] drm/edid: Switch DDC when reading the EDID
Originally by Seth Forshee , 2012-10-04:
Some dual graphics machines support muxing the DDC separately from
the display, so make use of this functionality when reading the EDID
on the inactive GPU. Also serialize drm_get_edid() with a mutex to
avoid races on the DDC mux state.
Modified by Dave Airlie , 2012-12-22:
I can't figure out why I didn't like this, but I rewrote this [...]
to lock/unlock the ddc lines [...]. I think I'd prefer something
like that otherwise the interface got really ugly.
Modified by Lukas Wunner , 2015-09-11:
Move vga_switcheroo calls to a wrapper around drm_get_edid() which
drivers can call on muxed machines. This avoids other drivers having
to go through the vga_switcheroo motions even though they are never
used on a muxed platform.
(suggested by Thierry Reding )
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Pierre Moreau
[MBP 5,3 2009 nvidia MCP79 + G96pre-retina 15"]
Tested-by: William Brown
[MBP 8,2 2011 intel SNB + amd turks pre-retina 15"]
Tested-by: Lukas Wunner
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"]
Cc: Seth Forshee
Cc: Dave Airlie
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/drm_edid.c | 26 ++
include/drm/drm_crtc.h | 2 ++
2 files changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index d895556..3982aa7 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1389,6 +1390,31 @@ struct edid *drm_get_edid(struct drm_connector
*connector,
EXPORT_SYMBOL(drm_get_edid);
/**
+ * drm_get_edid_switcheroo - get EDID data for a vga_switcheroo output
+ * @connector: connector we're probing
+ * @adapter: I2C adapter to use for DDC
+ *
+ * Wrapper around drm_get_edid() for laptops with dual GPUs using one set of
+ * outputs. The wrapper adds the requisite vga_switcheroo calls to temporarily
+ * switch DDC to the GPU which is retrieving EDID.
+ *
+ * Return: Pointer to valid EDID or NULL if we couldn't find any.
+ */
+struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
+struct i2c_adapter *adapter)
+{
+ struct pci_dev *pdev = connector->dev->pdev;
+ struct edid *edid;
+
+ vga_switcheroo_lock_ddc(pdev);
+ edid = drm_get_edid(connector, adapter);
+ vga_switcheroo_unlock_ddc(pdev);
+
+ return edid;
+}
+EXPORT_SYMBOL(drm_get_edid_switcheroo);
+
+/**
* drm_edid_duplicate - duplicate an EDID and the extensions
* @edid: EDID to duplicate
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 683f142..022efe7 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1295,6 +1295,8 @@ extern void drm_property_destroy_user_blobs(struct
drm_device *dev,
extern bool drm_probe_ddc(struct i2c_adapter *adapter);
extern struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter);
+extern struct edid *drm_get_edid_switcheroo(struct drm_connector *connector,
+ struct i2c_adapter *adapter);
extern struct edid *drm_edid_duplicate(const struct edid *edid);
extern int drm_add_edid_modes(struct drm_connector *connector, struct edid
*edid);
extern void drm_mode_config_init(struct drm_device *dev);
--
1.8.5.2 (Apple Git-48)
[PATCH v3 4/6] drm/i915: Switch DDC when reading the EDID
The pre-retina MacBook Pro uses an LVDS panel and a gmux controller
to switch the panel between its two GPUs. The panel mode in VBIOS
is notoriously bogus on these machines and some models have no
VBIOS at all.
Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS.
This allows us to retrieve the EDID if the outputs are currently
muxed to the discrete GPU by temporarily switching the panel's DDC
lines to the integrated GPU.
This only enables EDID probing on the pre-retina MBP (2008 - 2013).
The retina MBP (2012 - present) uses eDP and gmux is apparently not
capable of switching AUX separately from the main link on these models.
This will be addressed in later patches.
List of pre-retina MBPs with dual GPUs, one of them Intel:
[MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina 15"]
[MBP 6,1 2010 intel ILK + nvidia GT216 pre-retina 17"]
[MBP 8,2 2011 intel SNB + amd turks pre-retina 15"]
[MBP 8,3 2011 intel SNB + amd turks pre-retina 17"]
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: William Brown
[MBP 8,2 2011 intel SNB + amd turks pre-retina 15"]
Tested-by: Lukas Wunner
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"]
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/intel_lvds.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 2c2d1f0..dbc2682 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -1082,7 +1082,8 @@ void intel_lvds_init(struct drm_device *dev)
* preferred mode is the right one.
*/
mutex_lock(&dev->mode_config.mutex);
- edid = drm_get_edid(connector, intel_gmbus_get_adapter(dev_priv, pin));
+ edid = drm_get_edid_switcheroo(connector,
+ intel_gmbus_get_adapter(dev_priv, pin));
if (edid) {
if (drm_add_edid_modes(connector, edid)) {
drm_mode_connector_update_edid_property(connector,
--
1.8.5.2 (Apple Git-48)
[PATCH v3 5/6] drm/nouveau: Switch DDC when reading the EDID
The pre-retina MacBook Pro uses an LVDS panel and a gmux controller
to switch the panel between its two GPUs. The panel mode in VBIOS
is notoriously bogus on these machines.
Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS.
This allows us to retrieve the EDID if the outputs are currently
muxed to the other GPU by temporarily switching the panel's DDC
lines. Likewise, ask vga_switcheroo to switch DDC before probing
LVDS connectors.
This only enables EDID probing on the pre-retina MBP (2008 - 2013).
The retina MBP (2012 - present) uses eDP and gmux is apparently not
capable of switching AUX separately from the main link on these models.
This will be addressed in later patches.
List of pre-retina MBPs with dual GPUs, either or both Nvidia:
[MBP 5,1 2008 nvidia MCP79 + G96pre-retina 15"]
[MBP 5,2 2009 nvidia MCP79 + G96pre-retina 17"]
[MBP 5,3 2009 nvidia MCP79 + G96pre-retina 15"]
[MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina 15"]
[MBP 6,1 2010 intel ILK + nvidia GT216 pre-retina 17"]
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"]
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: Pierre Moreau
[MBP 5,3 2009 nvidia MCP79 + G96pre-retina 15"]
Tested-by: Lukas Wunner
[MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina 15"]
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 2e7cbe9..b3b0ca5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -27,6 +27,7 @@
#include
#include
+#include
#include
#include
@@ -148,7 +149,13 @@ nouveau_connector_ddc_detect(struct drm_connector
*connector)
break;
} else
if (nv_encoder->i2c) {
- if (nvkm_probe_i2c(nv_encoder->i2c, 0x50))
+ int ret;
+ if (nv_encoder->dcb->type == DCB_OUTPUT_LVDS)
+ vga_switcheroo_lock_ddc(dev->pdev);
+ ret = nvkm_probe_i2c(nv_encoder->i2c, 0x50);
+ if (nv_encoder->dcb->type == DCB_OUTPUT_LVDS)
+ vga_switcheroo_unlock_ddc(dev->pdev);
+ if (ret)
break;
}
}
@@ -259,7 +266,9 @@ nouveau_connector_detect(struct drm_connector *connector,
bool force)
nv_encoder = nouveau_connector_ddc_detect(connector);
if (nv_encoder && (i2c = nv_encoder->i2c) != NULL) {
- nv_connector->edid = drm_get_edid(connector, i2c);
+ nv_connector->edid = nv_encoder->dcb->type == DCB_OUTPUT_LVDS ?
+drm_get_edid_switcheroo(connector, i2c) :
+drm_get_edid(connector, i2c);
drm_mode_connector_update_edid_property(connector,
nv_connector->edid);
if (!nv_connector->edid) {
--
1.8.5.2 (Apple Git-48)
[Bug 92270] Radeon R7 M260/M265 - *ERROR* amdgpu: ring 0 test failed (scratch(0xC040)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=92270 --- Comment #2 from Christian König --- I wouldn't call this "properly loaded", the kernel driver completely fails to initialize the hardware and unloads itself after realizing that this won't work. Good to know that unloading the driver works, but I don't have any idea what's going wrong here. @Alex: How well did we already tested Topaz? If not we might want to disable the PCI-ID for now. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/cd66e9e3/attachment.html>
[PATCH v3 6/6] drm/radeon: Switch DDC when reading the EDID
The pre-retina MacBook Pro uses an LVDS panel and a gmux controller
to switch the panel between its two GPUs. The panel mode in VBIOS
is notoriously bogus on these machines.
Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS.
This allows us to retrieve the EDID if the outputs are currently
muxed to the integrated GPU by temporarily switching the panel's
DDC lines to the discrete GPU.
This only enables EDID probing on the pre-retina MBP (2008 - 2013).
The retina MBP (2012 - present) uses eDP and gmux is apparently not
capable of switching AUX separately from the main link on these models.
This will be addressed in later patches.
List of pre-retina MBPs with dual GPUs, one of them AMD:
[MBP 8,2 2011 intel SNB + amd turks pre-retina 15"]
[MBP 8,3 2011 intel SNB + amd turks pre-retina 17"]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115
Tested-by: William Brown
[MBP 8,2 2011 intel SNB + amd turks pre-retina 15"]
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/radeon/radeon_connectors.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 5a2cafb..569f63c 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -344,6 +344,10 @@ static void radeon_connector_get_edid(struct drm_connector
*connector)
else if (radeon_connector->ddc_bus)
radeon_connector->edid =
drm_get_edid(&radeon_connector->base,
&radeon_connector->ddc_bus->adapter);
+ } else if (connector->connector_type == DRM_MODE_CONNECTOR_LVDS &&
+ radeon_connector->ddc_bus) {
+ radeon_connector->edid =
drm_get_edid_switcheroo(&radeon_connector->base,
+
&radeon_connector->ddc_bus->adapter);
} else if (radeon_connector->ddc_bus) {
radeon_connector->edid = drm_get_edid(&radeon_connector->base,
&radeon_connector->ddc_bus->adapter);
--
1.8.5.2 (Apple Git-48)
[PATCH v3 0/6] Enable gpu switching on the MacBook Pro
Hi, I've also pushed this series to GitHub now to ease reviewing: https://github.com/l1k/linux/commits/mbp_switcheroo_v3 Thanks, Lukas
[alsa-devel] [PATCH RFC V2 0/5] another generic audio hdmi codec proposal
On 10/01/15 19:50, Arnaud Pouliquen wrote: > > Version 2: > This version integrates missing features upgraded to be aligned when possible > with patch set: > [PATCH RFC v4 0/8] Implement generic ASoC HDMI codec and use it in tda998x > There are still some details I would like to change if we decide to go the drm audio bridge way. But before all that, I would like to ask, why should we go forward with your approach? Is there anything that can be done with your approach, but can not be done with mine? Don't take me wrong, I do not see anything fundamentally wrong with your approach. I would just like hear some justification why we should abandon my approach - that I've been working on for some time - and go forward with yours. Here is couple of benefits I can name in my approach: Â Video side agnostic implementation The ASoC side does not need to know anything about video side implementation. There is no real exposure ASoC side internals in video side either. Even fbdev driver, or some other non DRM video driver, could use my implementation. - HDMI encoder driver implementations that do not use DRM bridge abstraction do not need add an extra DRM object just to get the audio working. Short comings I see in the current HDMI audio bridge approach: In its current from the DRM audio bridge abstraction pretends to be a generic audio abstraction for DRM devices, but the implementation is quite specific to external HDMI encoders with spdif and/or i2s interface. There is a lot of HDMI video devices that provide the digital audio interface (ASoC DAI) directly and there is no need for anything but dummy codec implementation (if following ASoC paradigm). Before going forward I think we should at least consider how this abstraction would serve those devices. Also, I am not entirely happy how the drm_audio_bridge_funcs are used at the moment. The do not map too well to ASoC DAI callbacks and I do not see too much point in creating a completely new audio-callback abstraction, that is sligtly incompatible with ALSA, and then translating alsa callbacks to these new callbacks. I think the callbacks should map more or less directly ALSA callbacks. Best regards, Jyri > It does not support the abort callback, the mute and syclk ops. > This could be added in V3 or separate patch if justified. > >[RFC 1/5]video: hdmi: add help function for N and CTS > - Replace real frequency value by enum in switch case > Notice that this patch is independant from the rest of the implentation >[RFC 2/5]drm: add helper functions to add audio capabilities for bridge > - extend audio bridge ops >[RFC 3/5]ASoC: codec: hdmi drm codec driver > aligned when possible with hdmi-codec.c implementation > . ELD management for alsa contraints > . Support of SPDIF and I2S mode > . hwparam ond set_fmt functions implemented >[RFC 4/5]drm: sti: connect audio driver > => Implementation for STI platform >[RFC 5/5]DT: sti: add audio HDMI dai link in audio card > => Devicetree example > > Version 1: > > This patch set is a tentative to implement a generic code for the HDMI audio. > Main concept are aligned with solution proposeded for TI platform. > - ASoC codec driver registered by DRM driver > - ASOC driver is a generic driver. > - compatible with simple card > > Difference is that i propose a DRM generic interface based on bridge > structure. > Advantage is that all data exchanges are done through the DRM API. > > I think also that some helper functions could been used for N and CTS > parameters calculation, > as suggested by Russell King in a previous mail. > > I full aware that some features (like ELD and info frame) are partially or > not implemented in my patches. > This patch set is more a skeleton than a full implementation... > I just post it to suggest a possible DRM API. > > Arnaud Pouliquen (5): >video: hdmi: add helper function for N and CTS >drm: add helper function to add audio capabilities for bridge >ASoC: codec: hdmi drm codec driver >drm: sti: connect audio driver >DT: sti: add audio HDMI dai link in audio card > > arch/arm/boot/dts/stih410.dtsi | 6 +- > arch/arm/boot/dts/stihxxx-b2120.dtsi | 21 ++ > drivers/gpu/drm/drm_bridge.c | 137 +- > drivers/gpu/drm/sti/sti_hdmi.c | 184 -- > drivers/gpu/drm/sti/sti_hdmi.h | 3 + > drivers/video/hdmi.c | 147 ++ > include/drm/drm_crtc.h | 62 ++ > include/drm/drm_modes.h | 12 ++ > include/linux/hdmi.h | 12 ++ > include/sound/hdmi_drm.h | 15 ++ > sound/soc/codecs/Kconfig | 8 +- > sound/soc/codecs/Makefile| 2 + > sound/soc/codecs/hdmi_drm.c | 358 > +++ > 13 files changed, 951 insertions(+), 16 deletions(-) > create mo
[Bug 92220] GL_NV_vdpau_interop partially available
https://bugs.freedesktop.org/show_bug.cgi?id=92220 --- Comment #14 from Christian König --- (In reply to Peter Frühberger from comment #13) > So @Christian happy for pointers on how to get it going. Yeah, completely agree with you. Software workarounds are very common in OpenGL and nothing unusual. Here are a few pointers into the code: 1. vlVdpVideoSurfaceGallium() in src/gallium/state_trackers/vdpau/surface.c. That one is called to "export" video surfaces to OpenGL and the right place to convert from frame to field. 2. vlVdpDecoderRender() in src/gallium/state_trackers/vdpau/decode.c. Here we reallocate the buffer backing the surface before the decoding if the frame/field flag doesn't match what the decoder expects. 3. vlVdpVideoMixerRender() in src/gallium/state_trackers/vdpau/mixer.c. Here we use a vl_compositor_render() to compose the mixed output picture. Essentially you only need to test if the surface is field based and if not reallocate it and either use vl_compositor_render() or pipe->blit() to copy the frame into fields. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/09b9750f/attachment.html>
[RFC v4] i965/gen8+: bo in state base address must be in 32-bit address range
Gen8+ supports 48-bit virtual addresses, but some objects must always be
allocated inside the 32-bit address range.
In specific, any resource used with flat/heapless (0x-0xf000)
General State Heap or Instruction State Heap must be in a 32-bit range
(GSH / ISH), because the General State Offset and Instruction State
Offset are limited to 32-bits.
Use drm_intel_bo_use_48b_address_range to flag when the 4GB limit is not
necessary, and the bo can be in the full address space.
This commit introduces a dependency of libdrm 2.4.6x, which introduces
the drm_intel_bo_use_48b_address_range function.
v2: s/48baddress/48b_address/,
Only use in OUT_RELOC64 cases, OUT_RELOC implies a 32-bit address
offset is needed (Ben)
v3: Added OUT_RELOC64_INSIDE_4G, so it stands out when a 64-bit
relocation needs the 32-bit workaround (Chris)
v4: In order to use full address space, libdrm requires to set the
support flag before calling emit_reloc.
References:
http://lists.freedesktop.org/archives/dri-devel/2015-September/089757.html
Cc: Ben Widawsky
Cc: Chris Wilson
Signed-off-by: Michel Thierry
---
configure.ac | 2 +-
src/mesa/drivers/dri/i965/gen8_misc_state.c | 17 ++---
src/mesa/drivers/dri/i965/intel_batchbuffer.c | 18 ++
src/mesa/drivers/dri/i965/intel_batchbuffer.h | 16
4 files changed, 37 insertions(+), 16 deletions(-)
diff --git a/configure.ac b/configure.ac
index 217281f..e31f4d3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -71,7 +71,7 @@ dnl Versions for external dependencies
LIBDRM_REQUIRED=2.4.60
LIBDRM_RADEON_REQUIRED=2.4.56
LIBDRM_AMDGPU_REQUIRED=2.4.63
-LIBDRM_INTEL_REQUIRED=2.4.61
+LIBDRM_INTEL_REQUIRED=2.4.66 #yes, it does not exist yet
LIBDRM_NVVIEUX_REQUIRED=2.4.33
LIBDRM_NOUVEAU_REQUIRED=2.4.62
LIBDRM_FREEDRENO_REQUIRED=2.4.65
diff --git a/src/mesa/drivers/dri/i965/gen8_misc_state.c
b/src/mesa/drivers/dri/i965/gen8_misc_state.c
index a46b252..7b4e448 100644
--- a/src/mesa/drivers/dri/i965/gen8_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_misc_state.c
@@ -28,6 +28,9 @@
/**
* Define the base addresses which some state is referenced from.
+ * Use OUT_RELOC64_INSIDE_4G instead of OUT_RELOC64, because the General State
+ * Offset and Instruction State Offset are limited to 32-bits by hardware,
+ * and must be located in the first 4GBs (32-bit offset).
*/
static void
gen8_upload_state_base_address(struct brw_context *brw)
@@ -42,18 +45,18 @@ gen8_upload_state_base_address(struct brw_context *brw)
OUT_BATCH(0);
OUT_BATCH(mocs_wb << 16);
/* Surface state base address: */
- OUT_RELOC64(brw->batch.bo, I915_GEM_DOMAIN_SAMPLER, 0,
- mocs_wb << 4 | 1);
+ OUT_RELOC64_INSIDE_4G(brw->batch.bo, I915_GEM_DOMAIN_SAMPLER, 0,
+ mocs_wb << 4 | 1);
/* Dynamic state base address: */
- OUT_RELOC64(brw->batch.bo,
- I915_GEM_DOMAIN_RENDER | I915_GEM_DOMAIN_INSTRUCTION, 0,
- mocs_wb << 4 | 1);
+ OUT_RELOC64_INSIDE_4G(brw->batch.bo,
+ I915_GEM_DOMAIN_RENDER | I915_GEM_DOMAIN_INSTRUCTION,
0,
+ mocs_wb << 4 | 1);
/* Indirect object base address: MEDIA_OBJECT data */
OUT_BATCH(mocs_wb << 4 | 1);
OUT_BATCH(0);
/* Instruction base address: shader kernels (incl. SIP) */
- OUT_RELOC64(brw->cache.bo, I915_GEM_DOMAIN_INSTRUCTION, 0,
- mocs_wb << 4 | 1);
+ OUT_RELOC64_INSIDE_4G(brw->cache.bo, I915_GEM_DOMAIN_INSTRUCTION, 0,
+ mocs_wb << 4 | 1);
/* General state buffer size */
OUT_BATCH(0xf001);
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
index 0363bd3..b15d627 100644
--- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
+++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
@@ -427,11 +427,21 @@ uint64_t
intel_batchbuffer_reloc64(struct brw_context *brw,
drm_intel_bo *buffer, uint32_t offset,
uint32_t read_domains, uint32_t write_domain,
- uint32_t delta)
+ uint32_t delta, uint32_t support_48bit_offset)
{
- int ret = drm_intel_bo_emit_reloc(brw->batch.bo, offset,
- buffer, delta,
- read_domains, write_domain);
+ int ret;
+
+ /* Not all buffers can be allocated outside the first 4GB, and
+* the offset must be limited to 32-bits.
+*/
+ if (support_48bit_offset)
+ drm_intel_bo_use_48b_address_range(buffer, 1);
+ else
+ drm_intel_bo_use_48b_address_range(buffer, 0);
+
+ ret = drm_intel_bo_emit_reloc(brw->batch.bo, offset,
+ buffer, delta,
+ read_domains, write_domain);
assert(ret == 0);
(void) ret;
diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.h
b/src/mesa/dri
[PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)
On 9/14/2015 2:54 PM, MichaÅ Winiarski wrote:
> On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote:
>> Gen8+ supports 48-bit virtual addresses, but some objects must always be
>> allocated inside the 32-bit address range.
>>
>> In specific, any resource used with flat/heapless (0x-0xf000)
>> General State Heap (GSH) or Instruction State Heap (ISH) must be in a
>> 32-bit range, because the General State Offset and Instruction State Offset
>> are limited to 32-bits.
>>
>> The i915 driver has been modified to provide a flag to set when the 4GB
>> limit is not necessary in a given bo (EXEC_OBJECT_SUPPORTS_48B_ADDRESS).
>> 48-bit range will only be used when explicitly requested.
>>
>> Callers to the existing drm_intel_bo_emit_reloc function should set the
>> use_48b_address_range flag beforehand, in order to use full ppgtt range.
>>
>> v2: Make set/clear functions nops on pre-gen8 platforms, and use them
>> internally in emit_reloc functions (Ben)
>> s/48BADDRESS/48B_ADDRESS/ (Dave)
>> v3: Keep set/clear functions internal, no-one needs to use them directly.
>> v4: Don't set 48bit-support flag in emit reloc, check for ppgtt type
>> before enabling set/clear function, print full offsets in debug
>> statements, using port of lower_32_bits and upper_32_bits from linux
>> kernel (MichaÅ)
>>
>> References:
>> http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
>> Cc: Ben Widawsky
>> Cc: MichaÅ Winiarski
>
> +Kristian
>
> LGTM.
> Acked-by: MichaÅ Winiarski
>
>> Signed-off-by: Michel Thierry
Hi Kristian,
More comments on this?
I've resent the mesa patch with the last changes
(http://lists.freedesktop.org/archives/dri-devel/2015-October/091752.html).
MichaÅ has agreed with the interface and will use it for his work.
If mesa doesn't plan to use this for now, it's ok. The kernel changes
have been done to prevent any regressions when the support 48-bit flag
is not set.
Thanks,
-Michel
>> ---
>> include/drm/i915_drm.h| 3 +-
>> intel/intel_bufmgr.c | 11 ++
>> intel/intel_bufmgr.h | 1 +
>> intel/intel_bufmgr_gem.c | 88
>> +--
>> intel/intel_bufmgr_priv.h | 14
>> 5 files changed, 97 insertions(+), 20 deletions(-)
>>
>> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
>> index ded43b1..426b25c 100644
>> --- a/include/drm/i915_drm.h
>> +++ b/include/drm/i915_drm.h
>> @@ -680,7 +680,8 @@ struct drm_i915_gem_exec_object2 {
>> #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
>> #define EXEC_OBJECT_NEEDS_GTT (1<<1)
>> #define EXEC_OBJECT_WRITE (1<<2)
>> -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
>> +#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3)
>> +#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_SUPPORTS_48B_ADDRESS<<1)
>> __u64 flags;
>>
>> __u64 rsvd1;
>> diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
>> index 14ea9f9..0856e60 100644
>> --- a/intel/intel_bufmgr.c
>> +++ b/intel/intel_bufmgr.c
>> @@ -293,6 +293,17 @@ drm_intel_bo_madvise(drm_intel_bo *bo, int madv)
>> }
>>
>> int
>> +drm_intel_bo_use_48b_address_range(drm_intel_bo *bo, uint32_t enable)
>> +{
>> +if (bo->bufmgr->bo_use_48b_address_range) {
>> +bo->bufmgr->bo_use_48b_address_range(bo, enable);
>> +return 0;
>> +}
>> +
>> +return -ENODEV;
>> +}
>> +
>> +int
>> drm_intel_bo_references(drm_intel_bo *bo, drm_intel_bo *target_bo)
>> {
>> return bo->bufmgr->bo_references(bo, target_bo);
>> diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
>> index 95eecb8..a14c78f 100644
>> --- a/intel/intel_bufmgr.h
>> +++ b/intel/intel_bufmgr.h
>> @@ -164,6 +164,7 @@ int drm_intel_bo_get_tiling(drm_intel_bo *bo, uint32_t *
>> tiling_mode,
>> int drm_intel_bo_flink(drm_intel_bo *bo, uint32_t * name);
>> int drm_intel_bo_busy(drm_intel_bo *bo);
>> int drm_intel_bo_madvise(drm_intel_bo *bo, int madv);
>> +int drm_intel_bo_use_48b_address_range(drm_intel_bo *bo, uint32_t enable);
>>
>> int drm_intel_bo_disable_reuse(drm_intel_bo *bo);
>> int drm_intel_bo_is_reusable(drm_intel_bo *bo);
>> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
>> index 2723e21..09d82d2 100644
>> --- a/intel/intel_bufmgr_gem.c
>> +++ b/intel/intel_bufmgr_gem.c
>> @@ -83,6 +83,22 @@
>> #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
>> #define MAX2(A, B) ((A) > (B) ? (A) : (B))
>>
>> +/**
>> + * upper_32_bits - return bits 32-63 of a number
>> + * @n: the number we're accessing
>> + *
>> + * A basic shift-right of a 64- or 32-bit quantity. Use this to suppress
>> + * the "right shift count >= width of type" warning when that quantity is
>> + * 32-bits.
>> + */
>> +#define upper_32_bits(n) ((__u32)(((n) >> 16) >> 16))
>> +
>> +/**
>> + * lower_32_bits - return bits 0-31 of a number
>> + * @n: the number we're accessing
>> + */
>> +#define lower_32_bits(n) ((__u32)(n))
>> +
>> typedef struct _drm_inte
[PATCH 0/5] qcom-scm fixes and support for OCMEM
Split out the restore-secure-config part from the ocmem lock/unlock, and updates to address review comments. Rob Clark (5): qcom-scm: fix endianess issue in __qcom_scm_is_call_available qcom-scm: fix header compile errors qcom-scm: add missing prototype for qcom_scm_is_available() qcom-scm: add support to restore secure config qcom-scm: add OCMEM lock/unlock interface drivers/firmware/qcom_scm-32.c | 60 -- drivers/firmware/qcom_scm-64.c | 16 +++ drivers/firmware/qcom_scm.c| 65 -- drivers/firmware/qcom_scm.h| 12 include/linux/qcom_scm.h | 16 +-- 5 files changed, 162 insertions(+), 7 deletions(-) -- 2.4.3
[PATCH 1/5] qcom-scm: fix endianess issue in __qcom_scm_is_call_available
Signed-off-by: Rob Clark
Reviewed-by: Stephen Boyd
---
drivers/firmware/qcom_scm-32.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index e9c306b..c1e4325 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -480,15 +480,15 @@ void __qcom_scm_cpu_power_down(u32 flags)
int __qcom_scm_is_call_available(u32 svc_id, u32 cmd_id)
{
int ret;
- u32 svc_cmd = (svc_id << 10) | cmd_id;
- u32 ret_val = 0;
+ __le32 svc_cmd = cpu_to_le32((svc_id << 10) | cmd_id);
+ __le32 ret_val = 0;
ret = qcom_scm_call(QCOM_SCM_SVC_INFO, QCOM_IS_CALL_AVAIL_CMD, &svc_cmd,
sizeof(svc_cmd), &ret_val, sizeof(ret_val));
if (ret)
return ret;
- return ret_val;
+ return le32_to_cpu(ret_val);
}
int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt, u32 *resp)
--
2.4.3
[PATCH 2/5] qcom-scm: fix header compile errors
Add missing #include for types.h to have u32, etc. And fwd declare
'struct cpumask'.
Signed-off-by: Rob Clark
---
drivers/firmware/qcom_scm.c | 4 ++--
include/linux/qcom_scm.h| 7 +--
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 118df0a..39082c1 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -76,7 +76,7 @@ static void qcom_scm_clk_disable(void)
* Set the cold boot address of the cpus. Any cpu outside the supported
* range would be removed from the cpu present mask.
*/
-int qcom_scm_set_cold_boot_addr(void *entry, const cpumask_t *cpus)
+int qcom_scm_set_cold_boot_addr(void *entry, const struct cpumask *cpus)
{
return __qcom_scm_set_cold_boot_addr(entry, cpus);
}
@@ -90,7 +90,7 @@ EXPORT_SYMBOL(qcom_scm_set_cold_boot_addr);
* Set the Linux entry point for the SCM to transfer control to when coming
* out of a power down. CPU power down may be executed on cpuidle or hotplug.
*/
-int qcom_scm_set_warm_boot_addr(void *entry, const cpumask_t *cpus)
+int qcom_scm_set_warm_boot_addr(void *entry, const struct cpumask *cpus)
{
return __qcom_scm_set_warm_boot_addr(entry, cpus);
}
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index 46d41e4..c536b70 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -13,8 +13,11 @@
#ifndef __QCOM_SCM_H
#define __QCOM_SCM_H
-extern int qcom_scm_set_cold_boot_addr(void *entry, const cpumask_t *cpus);
-extern int qcom_scm_set_warm_boot_addr(void *entry, const cpumask_t *cpus);
+#include
+
+struct cpumask;
+extern int qcom_scm_set_cold_boot_addr(void *entry, const struct cpumask
*cpus);
+extern int qcom_scm_set_warm_boot_addr(void *entry, const struct cpumask
*cpus);
#define QCOM_SCM_HDCP_MAX_REQ_CNT 5
--
2.4.3
[PATCH 3/5] qcom-scm: add missing prototype for qcom_scm_is_available()
Signed-off-by: Rob Clark
---
include/linux/qcom_scm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index c536b70..e407c0a 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -26,6 +26,8 @@ struct qcom_scm_hdcp_req {
u32 val;
};
+extern bool qcom_scm_is_available(void);
+
extern bool qcom_scm_hdcp_available(void);
extern int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt,
u32 *resp);
--
2.4.3
[PATCH 4/5] qcom-scm: add support to restore secure config
Needed by OCMEM driver.
Signed-off-by: Rob Clark
---
drivers/firmware/qcom_scm-32.c | 20
drivers/firmware/qcom_scm-64.c | 5 +
drivers/firmware/qcom_scm.c| 22 ++
drivers/firmware/qcom_scm.h| 5 +
include/linux/qcom_scm.h | 3 +++
5 files changed, 55 insertions(+)
diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index c1e4325..a7bf6d4 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -500,6 +500,26 @@ int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32
req_cnt, u32 *resp)
req, req_cnt * sizeof(*req), resp, sizeof(*resp));
}
+int __qcom_scm_restore_sec_config(u32 sec_id, u32 ctx_bank_num)
+{
+ int ret, scm_ret = 0;
+ struct msm_scm_sec_cfg {
+ __le32 id;
+ __le32 ctx_bank_num;
+ } cfg;
+
+ cfg.id = cpu_to_le32(sec_id);
+ cfg.ctx_bank_num = cpu_to_le32(sec_id);
+
+ ret = qcom_scm_call(QCOM_SCM_MP_SVC, QCOM_SCM_MP_RESTORE_SEC_CFG,
+ &cfg, sizeof(cfg), &scm_ret, sizeof(scm_ret));
+
+ if (ret || scm_ret)
+ return ret ? ret : -EINVAL;
+
+ return 0;
+}
+
bool __qcom_scm_pas_supported(u32 peripheral)
{
__le32 out;
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index e64fd92..7329cf0f 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -62,6 +62,11 @@ int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32
req_cnt, u32 *resp)
return -ENOTSUPP;
}
+int __qcom_scm_restore_sec_config(u32 sec_id, u32 ctx_bank_num)
+{
+ return -ENOTSUPP;
+}
+
bool __qcom_scm_pas_supported(u32 peripheral)
{
return false;
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 39082c1..8f43c0b 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -154,6 +154,28 @@ int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32
req_cnt, u32 *resp)
EXPORT_SYMBOL(qcom_scm_hdcp_req);
/**
+ * qcom_scm_restore_sec_config_available() - Check if secure environment
+ * supports restore security config interface.
+ *
+ * Return true if restore-cfg interface is supported, false if not.
+ */
+bool qcom_scm_restore_sec_config_available(void)
+{
+ return __qcom_scm_is_call_available(QCOM_SCM_MP_SVC,
+ QCOM_SCM_MP_RESTORE_SEC_CFG);
+}
+EXPORT_SYMBOL(qcom_scm_restore_sec_config_available);
+
+/**
+ * qcom_scm_restore_sec_config() - call restore-cfg interface
+ */
+int qcom_scm_restore_sec_config(unsigned sec_id)
+{
+ return __qcom_scm_restore_sec_config(sec_id, 0);
+}
+EXPORT_SYMBOL(qcom_scm_restore_sec_config);
+
+/**
* qcom_scm_pas_supported() - Check if the peripheral authentication service is
* available for the given peripherial
* @peripheral:peripheral id
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 220d19c..3085616 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -36,6 +36,11 @@ extern int __qcom_scm_is_call_available(u32 svc_id, u32
cmd_id);
extern int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt,
u32 *resp);
+#define QCOM_SCM_MP_SVC0xc
+#define QCOM_SCM_MP_RESTORE_SEC_CFG0x2
+
+extern int __qcom_scm_restore_sec_config(u32 sec_id, u32 ctx_bank_num);
+
#define QCOM_SCM_SVC_PIL 0x2
#define QCOM_SCM_PAS_INIT_IMAGE_CMD0x1
#define QCOM_SCM_PAS_MEM_SETUP_CMD 0x2
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index e407c0a..7be3d91 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -32,6 +32,9 @@ extern bool qcom_scm_hdcp_available(void);
extern int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt,
u32 *resp);
+extern bool qcom_scm_restore_sec_config_available(void);
+extern int qcom_scm_restore_sec_config(unsigned sec_id);
+
extern bool qcom_scm_pas_supported(u32 peripheral);
extern int qcom_scm_pas_init_image(u32 peripheral, const void *metadata,
size_t size);
extern int qcom_scm_pas_mem_setup(u32 peripheral, phys_addr_t addr,
phys_addr_t size);
--
2.4.3
[PATCH 5/5] qcom-scm: add OCMEM lock/unlock interface
Needed to enable device access to OCMEM.
Signed-off-by: Rob Clark
---
drivers/firmware/qcom_scm-32.c | 34 ++
drivers/firmware/qcom_scm-64.c | 11 +++
drivers/firmware/qcom_scm.c| 39 +++
drivers/firmware/qcom_scm.h| 7 +++
include/linux/qcom_scm.h | 4
5 files changed, 95 insertions(+)
diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index a7bf6d4..dc84771b 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -520,6 +520,40 @@ int __qcom_scm_restore_sec_config(u32 sec_id, u32
ctx_bank_num)
return 0;
}
+int __qcom_scm_ocmem_lock(u32 id, u32 offset, u32 size, u32 mode)
+{
+ struct ocmem_tz_lock {
+ __le32 id;
+ __le32 offset;
+ __le32 size;
+ __le32 mode;
+ } request;
+
+ request.id = cpu_to_le32(id);
+ request.offset = cpu_to_le32(offset);
+ request.size = cpu_to_le32(size);
+ request.mode = cpu_to_le32(mode);
+
+ return qcom_scm_call(QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_LOCK_CMD,
+ &request, sizeof(request), NULL, 0);
+}
+
+int __qcom_scm_ocmem_unlock(u32 id, u32 offset, u32 size)
+{
+ struct ocmem_tz_unlock {
+ __le32 id;
+ __le32 offset;
+ __le32 size;
+ } request;
+
+ request.id = cpu_to_le32(id);
+ request.offset = cpu_to_le32(offset);
+ request.size = cpu_to_le32(size);
+
+ return qcom_scm_call(QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_UNLOCK_CMD,
+ &request, sizeof(request), NULL, 0);
+}
+
bool __qcom_scm_pas_supported(u32 peripheral)
{
__le32 out;
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 7329cf0f..0ca20a3 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -67,6 +67,17 @@ int __qcom_scm_restore_sec_config(u32 sec_id, u32
ctx_bank_num)
return -ENOTSUPP;
}
+int __qcom_scm_ocmem_lock(uint32_t id, uint32_t offset, uint32_t size,
+ uint32_t mode)
+{
+ return -ENOTSUPP;
+}
+
+int __qcom_scm_ocmem_unlock(uint32_t id, uint32_t offset, uint32_t size)
+{
+ return -ENOTSUPP;
+}
+
bool __qcom_scm_pas_supported(u32 peripheral)
{
return false;
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 8f43c0b..0e7ce42 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -176,6 +176,45 @@ int qcom_scm_restore_sec_config(unsigned sec_id)
EXPORT_SYMBOL(qcom_scm_restore_sec_config);
/**
+ * qcom_scm_ocmem_lock_available() - is OCMEM lock/unlock interface available
+ */
+bool qcom_scm_ocmem_lock_available(void)
+{
+ return __qcom_scm_is_call_available(QCOM_SCM_OCMEM_SVC,
+ QCOM_SCM_OCMEM_LOCK_CMD);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_lock_available);
+
+/**
+ * qcom_scm_ocmem_lock() - call OCMEM lock interface to assign an OCMEM
+ * region to the specified initiator
+ *
+ * @id: tz initiator id
+ * @offset: OCMEM offset
+ * @size: OCMEM size
+ * @mode: access mode (WIDE/NARROW)
+ */
+int qcom_scm_ocmem_lock(u32 id, u32 offset, u32 size, u32 mode)
+{
+ return __qcom_scm_ocmem_lock(id, offset, size, mode);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_lock);
+
+/**
+ * qcom_scm_ocmem_unlock() - call OCMEM unlock interface to release an OCMEM
+ * region from the specified initiator
+ *
+ * @id: tz initiator id
+ * @offset: OCMEM offset
+ * @size: OCMEM size
+ */
+int qcom_scm_ocmem_unlock(u32 id, u32 offset, u32 size)
+{
+ return __qcom_scm_ocmem_unlock(id, offset, size);
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_unlock);
+
+/**
* qcom_scm_pas_supported() - Check if the peripheral authentication service is
* available for the given peripherial
* @peripheral:peripheral id
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 3085616..ec3435e 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -41,6 +41,13 @@ extern int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req
*req, u32 req_cnt,
extern int __qcom_scm_restore_sec_config(u32 sec_id, u32 ctx_bank_num);
+#define QCOM_SCM_OCMEM_SVC 0xf
+#define QCOM_SCM_OCMEM_LOCK_CMD0x1
+#define QCOM_SCM_OCMEM_UNLOCK_CMD 0x2
+
+extern int __qcom_scm_ocmem_lock(u32 id, u32 offset, u32 size, u32 mode);
+extern int __qcom_scm_ocmem_unlock(u32 id, u32 offset, u32 size);
+
#define QCOM_SCM_SVC_PIL 0x2
#define QCOM_SCM_PAS_INIT_IMAGE_CMD0x1
#define QCOM_SCM_PAS_MEM_SETUP_CMD 0x2
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index 7be3d91..beadca4 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -35,6 +35,10 @@ extern int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req,
u32 req_cnt,
extern bool
[PATCH 4/5] qcom-scm: add support to restore secure config
On Mon, Oct 5, 2015 at 10:22 AM, Rob Clark wrote:
> Needed by OCMEM driver.
>
> Signed-off-by: Rob Clark
> ---
Note: I am contemplating squashing something like this in:
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index beadca4..d3f209d 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -32,8 +32,18 @@ extern bool qcom_scm_hdcp_available(void);
extern int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt,
u32 *resp);
+enum qcom_scm_sec_dev_id {
+QCOM_SCM_MDSS_DEV_ID= 1,
+QCOM_SCM_OCMEM_DEV_ID= 5,
+QCOM_SCM_PCIE0_DEV_ID= 11,
+QCOM_SCM_PCIE1_DEV_ID= 12,
+QCOM_SCM_GFX_DEV_ID= 18,
+QCOM_SCM_UFS_DEV_ID= 19,
+QCOM_SCM_ICE_DEV_ID= 20,
+};
+
extern bool qcom_scm_restore_sec_config_available(void);
-extern int qcom_scm_restore_sec_config(unsigned sec_id);
+extern int qcom_scm_restore_sec_config(enum qcom_scm_sec_dev_id sec_id);
The thing I am unsure about is whether the device-id's are always
stable across different parts. From what I can tell from
dumpster-diving the downstream kernel, there is a mix of hard-coding
dev-id in code, vs taking it out of devicetree. But in cases where it
comes from devicetree, it seems like it is always using the same
values across different SoCs. But I may be missing something.. and
since downstream kernel branches tend to shed support for older
generations I may not be going far enough back in time..
BR,
-R
> drivers/firmware/qcom_scm-32.c | 20
> drivers/firmware/qcom_scm-64.c | 5 +
> drivers/firmware/qcom_scm.c| 22 ++
> drivers/firmware/qcom_scm.h| 5 +
> include/linux/qcom_scm.h | 3 +++
> 5 files changed, 55 insertions(+)
>
> diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
> index c1e4325..a7bf6d4 100644
> --- a/drivers/firmware/qcom_scm-32.c
> +++ b/drivers/firmware/qcom_scm-32.c
> @@ -500,6 +500,26 @@ int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req,
> u32 req_cnt, u32 *resp)
> req, req_cnt * sizeof(*req), resp, sizeof(*resp));
> }
>
> +int __qcom_scm_restore_sec_config(u32 sec_id, u32 ctx_bank_num)
> +{
> + int ret, scm_ret = 0;
> + struct msm_scm_sec_cfg {
> + __le32 id;
> + __le32 ctx_bank_num;
> + } cfg;
> +
> + cfg.id = cpu_to_le32(sec_id);
> + cfg.ctx_bank_num = cpu_to_le32(sec_id);
> +
> + ret = qcom_scm_call(QCOM_SCM_MP_SVC, QCOM_SCM_MP_RESTORE_SEC_CFG,
> + &cfg, sizeof(cfg), &scm_ret, sizeof(scm_ret));
> +
> + if (ret || scm_ret)
> + return ret ? ret : -EINVAL;
> +
> + return 0;
> +}
> +
> bool __qcom_scm_pas_supported(u32 peripheral)
> {
> __le32 out;
> diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
> index e64fd92..7329cf0f 100644
> --- a/drivers/firmware/qcom_scm-64.c
> +++ b/drivers/firmware/qcom_scm-64.c
> @@ -62,6 +62,11 @@ int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32
> req_cnt, u32 *resp)
> return -ENOTSUPP;
> }
>
> +int __qcom_scm_restore_sec_config(u32 sec_id, u32 ctx_bank_num)
> +{
> + return -ENOTSUPP;
> +}
> +
> bool __qcom_scm_pas_supported(u32 peripheral)
> {
> return false;
> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> index 39082c1..8f43c0b 100644
> --- a/drivers/firmware/qcom_scm.c
> +++ b/drivers/firmware/qcom_scm.c
> @@ -154,6 +154,28 @@ int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32
> req_cnt, u32 *resp)
> EXPORT_SYMBOL(qcom_scm_hdcp_req);
>
> /**
> + * qcom_scm_restore_sec_config_available() - Check if secure environment
> + * supports restore security config interface.
> + *
> + * Return true if restore-cfg interface is supported, false if not.
> + */
> +bool qcom_scm_restore_sec_config_available(void)
> +{
> + return __qcom_scm_is_call_available(QCOM_SCM_MP_SVC,
> + QCOM_SCM_MP_RESTORE_SEC_CFG);
> +}
> +EXPORT_SYMBOL(qcom_scm_restore_sec_config_available);
> +
> +/**
> + * qcom_scm_restore_sec_config() - call restore-cfg interface
> + */
> +int qcom_scm_restore_sec_config(unsigned sec_id)
> +{
> + return __qcom_scm_restore_sec_config(sec_id, 0);
> +}
> +EXPORT_SYMBOL(qcom_scm_restore_sec_config);
> +
> +/**
> * qcom_scm_pas_supported() - Check if the peripheral authentication service
> is
> * available for the given peripherial
> * @peripheral:peripheral id
> diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
> index 220d19c..3085616 100644
> --- a/drivers/firmware/qcom_scm.h
> +++ b/drivers/firmware/qcom_scm.h
> @@ -36,6 +36,11 @@ extern int __qcom_scm_is_call_available(u32 svc_id, u32
> cmd_id);
> extern int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 req_cnt,
> u32 *resp);
>
> +#define QCOM_SCM_MP_SVC
[PATCH v9 0/4] Allow USB devices to remain runtime-suspended when sleeping
Hi, this is v9 of an attempt to make it easier for devices to remain in runtime PM when the system goes to sleep, mainly to reduce the time spent resuming devices. For this, we interpret the absence of all PM callback implementations as it being safe to do direct_complete, so their ancestors aren't prevented from remaining runtime-suspended. Additionally, the prepare() callback of USB devices will return 1 if runtime PM is enabled and the current wakeup settings are correct. With these changes, a uvcvideo device (for example) stays in runtime suspend when the system goes to sleep and is left in that state when the system resumes, not delaying it unnecessarily. Thanks, Tomeu Changes in v9: - Add docs noting the need for the device lock to be held before calling device_is_bound() - Add docs noting the need for the device lock to be held before calling dev_pm_domain_set() - Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf. - Rename from device_check_pm_callbacks to device_pm_check_callbacks to follow with the naming convention of existing API. - Re-add calling to device_pm_check_callbacks from device registration and when updating the PM domain of a device. Changes in v8: - Add device_is_bound() - Add dev_pm_domain_set() and update code to use it - Move no_pm_callbacks field into CONFIG_PM_SLEEP - Call device_check_pm_callbacks only after a device is bound or unbound Changes in v7: - Reduce indentation by adding a label in device_prepare() Changes in v6: - Add stub for !CONFIG_PM. - Move implementation of device_check_pm_callbacks to power/main.c as it doesn't belong to CONFIG_PM_SLEEP. - Take dev->power.lock before modifying flag. Changes in v5: - Check for all dev_pm_ops instances associated to a device, updating a no_pm_callbacks flag at the times when that could change. Tomeu Vizoso (4): device core: add device_is_bound() PM / Domains: add setter for dev.pm_domain PM / sleep: Go direct_complete if driver has no callbacks USB / PM: Allow USB devices to remain runtime-suspended when sleeping arch/arm/mach-omap2/omap_device.c | 7 --- drivers/acpi/acpi_lpss.c | 5 +++-- drivers/acpi/device_pm.c | 5 +++-- drivers/base/dd.c | 21 +++-- drivers/base/power/clock_ops.c| 5 +++-- drivers/base/power/common.c | 24 drivers/base/power/domain.c | 6 -- drivers/base/power/main.c | 35 +++ drivers/base/power/power.h| 3 +++ drivers/gpu/vga/vga_switcheroo.c | 10 +- drivers/misc/mei/pci-me.c | 5 +++-- drivers/misc/mei/pci-txe.c| 5 +++-- drivers/usb/core/port.c | 6 ++ drivers/usb/core/usb.c| 11 ++- include/linux/device.h| 2 ++ include/linux/pm.h| 1 + include/linux/pm_domain.h | 3 +++ 17 files changed, 131 insertions(+), 23 deletions(-) -- 2.4.3
[PATCH v9 2/4] PM / Domains: add setter for dev.pm_domain
Adds a function that sets the pointer to dev_pm_domain in struct device
and that warns if the device has already finished probing. The reason
why we want to enforce that is because in the general case that can
cause problems and also that we can simplify code quite a bit if we can
always assume that.
This patch also changes all current code that directly sets the
dev.pm_domain pointer.
Signed-off-by: Tomeu Vizoso
---
Changes in v9:
- Add docs noting the need for the device lock to be held before calling
dev_pm_domain_set()
Changes in v8:
- Add dev_pm_domain_set() and update code to use it
arch/arm/mach-omap2/omap_device.c | 7 ---
drivers/acpi/acpi_lpss.c | 5 +++--
drivers/acpi/device_pm.c | 5 +++--
drivers/base/power/clock_ops.c| 5 +++--
drivers/base/power/common.c | 21 +
drivers/base/power/domain.c | 4 ++--
drivers/gpu/vga/vga_switcheroo.c | 10 +-
drivers/misc/mei/pci-me.c | 5 +++--
drivers/misc/mei/pci-txe.c| 5 +++--
include/linux/pm_domain.h | 3 +++
10 files changed, 50 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 4cb8fd9f741f..204101d11632 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -168,7 +169,7 @@ static int omap_device_build_from_dt(struct platform_device
*pdev)
r->name = dev_name(&pdev->dev);
}
- pdev->dev.pm_domain = &omap_device_pm_domain;
+ dev_pm_domain_set(&pdev->dev, &omap_device_pm_domain);
if (device_active) {
omap_device_enable(pdev);
@@ -180,7 +181,7 @@ odbfd_exit1:
odbfd_exit:
/* if data/we are at fault.. load up a fail handler */
if (ret)
- pdev->dev.pm_domain = &omap_device_fail_pm_domain;
+ dev_pm_domain_set(&pdev->dev, &omap_device_fail_pm_domain);
return ret;
}
@@ -701,7 +702,7 @@ int omap_device_register(struct platform_device *pdev)
{
pr_debug("omap_device: %s: registering\n", pdev->name);
- pdev->dev.pm_domain = &omap_device_pm_domain;
+ dev_pm_domain_set(&pdev->dev, &omap_device_pm_domain);
return platform_device_add(pdev);
}
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index f51bd0d0bc17..cc6e1abc69b3 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -706,7 +707,7 @@ static int acpi_lpss_platform_notify(struct notifier_block
*nb,
switch (action) {
case BUS_NOTIFY_ADD_DEVICE:
- pdev->dev.pm_domain = &acpi_lpss_pm_domain;
+ dev_pm_domain_set(&pdev->dev, &acpi_lpss_pm_domain);
if (pdata->dev_desc->flags & LPSS_LTR)
return sysfs_create_group(&pdev->dev.kobj,
&lpss_attr_group);
@@ -714,7 +715,7 @@ static int acpi_lpss_platform_notify(struct notifier_block
*nb,
case BUS_NOTIFY_DEL_DEVICE:
if (pdata->dev_desc->flags & LPSS_LTR)
sysfs_remove_group(&pdev->dev.kobj, &lpss_attr_group);
- pdev->dev.pm_domain = NULL;
+ dev_pm_domain_set(&pdev->dev, NULL);
break;
default:
break;
diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index 4806b7f856c4..8c5955bf9bbf 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include "internal.h"
@@ -1076,7 +1077,7 @@ static void acpi_dev_pm_detach(struct device *dev, bool
power_off)
struct acpi_device *adev = ACPI_COMPANION(dev);
if (adev && dev->pm_domain == &acpi_general_pm_domain) {
- dev->pm_domain = NULL;
+ dev_pm_domain_set(dev, NULL);
acpi_remove_pm_notifier(adev);
if (power_off) {
/*
@@ -1128,7 +1129,7 @@ int acpi_dev_pm_attach(struct device *dev, bool power_on)
return -EBUSY;
acpi_add_pm_notifier(adev, dev, acpi_pm_notify_work_func);
- dev->pm_domain = &acpi_general_pm_domain;
+ dev_pm_domain_set(dev, &acpi_general_pm_domain);
if (power_on) {
acpi_dev_pm_full_power(adev);
acpi_device_wakeup(adev, ACPI_STATE_S0, false);
diff --git a/drivers/base/power/clock_ops.c b/drivers/base/power/clock_ops.c
index 652b5a367c1f..e80fda6c03a9 100644
--- a/drivers/base/power/clock_ops.c
+++ b/drivers/base/power/clock_ops.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#ifdef CONFIG_PM
@@ -346,7 +347,7 @@ static int pm_clk_notify(struct notifier_block *nb,
if (error)
[Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro
Hi Evan, On Mon, Oct 05, 2015 at 10:15:53AM -0400, Evan Foss wrote: > On Mon, Oct 5, 2015 at 9:23 AM, Lukas Wunner wrote: > > I've also pushed this series to GitHub now to ease reviewing: > > https://github.com/l1k/linux/commits/mbp_switcheroo_v3 > > So to test this all someone has to do is pull this and try it? No > patching required? Yes. But if you don't already have a kernel git repo, this will be a > 1 GByte download. Which MacBook Pro model do you want to test this on? As noted in the cover letter, this will only work on pre-retinas and only if the apple-gmux module loads before the DRM drivers. You can try to ensure the latter by editing modules.dep, or grab this tarball which contains reprobing patches on top: http://wunner.de/mbp_switcheroo_v3_reprobe_4.3-rc4pre.tar.gz Best regards, Lukas
[Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro
The repo is a fork of Linus' tree, with the patches on top of it. So you just need to build that modified version of the kernel and boot it. :-) Pierre > On 05 Oct 2015, at 16:15, Evan Foss wrote: > >> On Mon, Oct 5, 2015 at 9:23 AM, Lukas Wunner wrote: >> Hi, >> >> I've also pushed this series to GitHub now to ease reviewing: >> https://github.com/l1k/linux/commits/mbp_switcheroo_v3 > > So to test this all someone has to do is pull this and try it? No > patching required? > >> Thanks, >> >> Lukas >> ___ >> Nouveau mailing list >> Nouveau at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/nouveau > > > > -- > Home > http://evanfoss.googlepages.com/ > Work > http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/ > ___ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro
Hi Evan, On Mon, Oct 05, 2015 at 11:23:21AM -0400, Evan Foss wrote: > $ dmesg|grep Apple > [0.00] efi: EFI v1.10 by Apple > [0.00] DMI: Apple Inc. MacBookPro9,1/Mac- > 4B7AC7E43945597E, > BIOS MBP91.88Z.00D3.B08.1208081132 08/08/2012 That was the last of the pre-retinas. I have exactly the same machine, so yes, it should work just fine on that one. Best regards, Lukas
[PATCH 5/5] qcom-scm: add OCMEM lock/unlock interface
On Mon, Oct 5, 2015 at 10:22 AM, Rob Clark wrote:
> Needed to enable device access to OCMEM.
>
> Signed-off-by: Rob Clark
> ---
and similar to the previous patch, considering squashing in:
---
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index d3f209d..41ad996 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -45,9 +45,19 @@ enum qcom_scm_sec_dev_id {
extern bool qcom_scm_restore_sec_config_available(void);
extern int qcom_scm_restore_sec_config(enum qcom_scm_sec_dev_id sec_id);
+enum qcom_scm_ocmem_client {
+QCOM_SCM_OCMEM_UNUSED_ID = 0x0,
+QCOM_SCM_OCMEM_GRAPHICS_ID,
+QCOM_SCM_OCMEM_VIDEO_ID,
+QCOM_SCM_OCMEM_LP_AUDIO_ID,
+QCOM_SCM_OCMEM_SENSORS_ID,
+QCOM_SCM_OCMEM_OTHER_OS_ID,
+QCOM_SCM_OCMEM_DEBUG_ID,
+};
+
extern bool qcom_scm_ocmem_lock_available(void);
-extern int qcom_scm_ocmem_lock(u32 id, u32 offset, u32 size, u32 mode);
-extern int qcom_scm_ocmem_unlock(u32 id, u32 offset, u32 size);
+extern int qcom_scm_ocmem_lock(enum qcom_scm_ocmem_client id, u32
offset, u32 size, u32 mode);
+extern int qcom_scm_ocmem_unlock(enum qcom_scm_ocmem_client id, u32
offset, u32 size);
---
BR,
-R
> drivers/firmware/qcom_scm-32.c | 34 ++
> drivers/firmware/qcom_scm-64.c | 11 +++
> drivers/firmware/qcom_scm.c| 39 +++
> drivers/firmware/qcom_scm.h| 7 +++
> include/linux/qcom_scm.h | 4
> 5 files changed, 95 insertions(+)
>
> diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
> index a7bf6d4..dc84771b 100644
> --- a/drivers/firmware/qcom_scm-32.c
> +++ b/drivers/firmware/qcom_scm-32.c
> @@ -520,6 +520,40 @@ int __qcom_scm_restore_sec_config(u32 sec_id, u32
> ctx_bank_num)
> return 0;
> }
>
> +int __qcom_scm_ocmem_lock(u32 id, u32 offset, u32 size, u32 mode)
> +{
> + struct ocmem_tz_lock {
> + __le32 id;
> + __le32 offset;
> + __le32 size;
> + __le32 mode;
> + } request;
> +
> + request.id = cpu_to_le32(id);
> + request.offset = cpu_to_le32(offset);
> + request.size = cpu_to_le32(size);
> + request.mode = cpu_to_le32(mode);
> +
> + return qcom_scm_call(QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_LOCK_CMD,
> + &request, sizeof(request), NULL, 0);
> +}
> +
> +int __qcom_scm_ocmem_unlock(u32 id, u32 offset, u32 size)
> +{
> + struct ocmem_tz_unlock {
> + __le32 id;
> + __le32 offset;
> + __le32 size;
> + } request;
> +
> + request.id = cpu_to_le32(id);
> + request.offset = cpu_to_le32(offset);
> + request.size = cpu_to_le32(size);
> +
> + return qcom_scm_call(QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_UNLOCK_CMD,
> + &request, sizeof(request), NULL, 0);
> +}
> +
> bool __qcom_scm_pas_supported(u32 peripheral)
> {
> __le32 out;
> diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
> index 7329cf0f..0ca20a3 100644
> --- a/drivers/firmware/qcom_scm-64.c
> +++ b/drivers/firmware/qcom_scm-64.c
> @@ -67,6 +67,17 @@ int __qcom_scm_restore_sec_config(u32 sec_id, u32
> ctx_bank_num)
> return -ENOTSUPP;
> }
>
> +int __qcom_scm_ocmem_lock(uint32_t id, uint32_t offset, uint32_t size,
> + uint32_t mode)
> +{
> + return -ENOTSUPP;
> +}
> +
> +int __qcom_scm_ocmem_unlock(uint32_t id, uint32_t offset, uint32_t size)
> +{
> + return -ENOTSUPP;
> +}
> +
> bool __qcom_scm_pas_supported(u32 peripheral)
> {
> return false;
> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> index 8f43c0b..0e7ce42 100644
> --- a/drivers/firmware/qcom_scm.c
> +++ b/drivers/firmware/qcom_scm.c
> @@ -176,6 +176,45 @@ int qcom_scm_restore_sec_config(unsigned sec_id)
> EXPORT_SYMBOL(qcom_scm_restore_sec_config);
>
> /**
> + * qcom_scm_ocmem_lock_available() - is OCMEM lock/unlock interface available
> + */
> +bool qcom_scm_ocmem_lock_available(void)
> +{
> + return __qcom_scm_is_call_available(QCOM_SCM_OCMEM_SVC,
> + QCOM_SCM_OCMEM_LOCK_CMD);
> +}
> +EXPORT_SYMBOL(qcom_scm_ocmem_lock_available);
> +
> +/**
> + * qcom_scm_ocmem_lock() - call OCMEM lock interface to assign an OCMEM
> + * region to the specified initiator
> + *
> + * @id: tz initiator id
> + * @offset: OCMEM offset
> + * @size: OCMEM size
> + * @mode: access mode (WIDE/NARROW)
> + */
> +int qcom_scm_ocmem_lock(u32 id, u32 offset, u32 size, u32 mode)
> +{
> + return __qcom_scm_ocmem_lock(id, offset, size, mode);
> +}
> +EXPORT_SYMBOL(qcom_scm_ocmem_lock);
> +
> +/**
> + * qcom_scm_ocmem_unlock() - call OCMEM unlock interface to release an OCMEM
> + * region from the specified initiator
> + *
> + * @id: tz initiator id
> + * @offset: OCMEM offset
> + * @size: OCMEM size
> + */
> +int qcom_scm_ocmem_unlock(u32
[PATCH v4 1/2] intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag)
On Mon, Oct 5, 2015 at 7:03 AM, Michel Thierry
wrote:
> On 9/14/2015 2:54 PM, MichaÅ Winiarski wrote:
>>
>> On Thu, Sep 03, 2015 at 03:23:58PM +0100, Michel Thierry wrote:
>>>
>>> Gen8+ supports 48-bit virtual addresses, but some objects must always be
>>> allocated inside the 32-bit address range.
>>>
>>> In specific, any resource used with flat/heapless (0x-0xf000)
>>> General State Heap (GSH) or Instruction State Heap (ISH) must be in a
>>> 32-bit range, because the General State Offset and Instruction State
>>> Offset
>>> are limited to 32-bits.
>>>
>>> The i915 driver has been modified to provide a flag to set when the 4GB
>>> limit is not necessary in a given bo (EXEC_OBJECT_SUPPORTS_48B_ADDRESS).
>>> 48-bit range will only be used when explicitly requested.
>>>
>>> Callers to the existing drm_intel_bo_emit_reloc function should set the
>>> use_48b_address_range flag beforehand, in order to use full ppgtt range.
>>>
>>> v2: Make set/clear functions nops on pre-gen8 platforms, and use them
>>> internally in emit_reloc functions (Ben)
>>> s/48BADDRESS/48B_ADDRESS/ (Dave)
>>> v3: Keep set/clear functions internal, no-one needs to use them directly.
>>> v4: Don't set 48bit-support flag in emit reloc, check for ppgtt type
>>> before enabling set/clear function, print full offsets in debug
>>> statements, using port of lower_32_bits and upper_32_bits from linux
>>> kernel (MichaÅ)
>>>
>>> References:
>>> http://lists.freedesktop.org/archives/intel-gfx/2015-July/072612.html
>>> Cc: Ben Widawsky
>>> Cc: MichaÅ Winiarski
>>
>>
>> +Kristian
>>
>> LGTM.
>> Acked-by: MichaÅ Winiarski
>>
>>> Signed-off-by: Michel Thierry
>
>
>
> Hi Kristian,
>
> More comments on this?
> I've resent the mesa patch with the last changes
> (http://lists.freedesktop.org/archives/dri-devel/2015-October/091752.html).
>
> MichaÅ has agreed with the interface and will use it for his work.
> If mesa doesn't plan to use this for now, it's ok. The kernel changes have
> been done to prevent any regressions when the support 48-bit flag is not
> set.
I didn't get any replies to my last comments on this:
http://lists.freedesktop.org/archives/mesa-dev/2015-August/091398.html
Basically, I tried explicitly placing buffers above 8G and didn't see
the HW problem described (ie it all worked fine). I still think
there's some confusion as to what the W/A is about.
Here's my take: the W/A is a SW-only workaround to handle the cases
where a driver uses heapless and 48-bit ppgtt. The problem is that the
heaps are limited to 4G but with 48bit ppgtt a buffer can be placed
anywhere it the 48 bit address space. If that happens it's consideredd
out-of-bounds for the heap and access fails. To prevent this we need
to make sure the bos we address in a heapless fashion are placed below
4g.
For mesa, we only configure general state base as heap-less, which
affects scratch bos. What this boils down to is that we need the 4G
restriction only for the scratch bos set up on 3DSTATE_VS, 3DSTATE_GS
and 3DSTATE_PS (and tesselation stage eventually). Look for the
OUT_RELOC64 for stage->scratch_bo in gen8_vs_state.c, gen8_gs_state.c
and gen8_ps_state.c
Kristian
> Thanks,
>
> -Michel
>
>
>>> ---
>>> include/drm/i915_drm.h| 3 +-
>>> intel/intel_bufmgr.c | 11 ++
>>> intel/intel_bufmgr.h | 1 +
>>> intel/intel_bufmgr_gem.c | 88
>>> +--
>>> intel/intel_bufmgr_priv.h | 14
>>> 5 files changed, 97 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
>>> index ded43b1..426b25c 100644
>>> --- a/include/drm/i915_drm.h
>>> +++ b/include/drm/i915_drm.h
>>> @@ -680,7 +680,8 @@ struct drm_i915_gem_exec_object2 {
>>> #define EXEC_OBJECT_NEEDS_FENCE (1<<0)
>>> #define EXEC_OBJECT_NEEDS_GTT (1<<1)
>>> #define EXEC_OBJECT_WRITE (1<<2)
>>> -#define __EXEC_OBJECT_UNKNOWN_FLAGS -(EXEC_OBJECT_WRITE<<1)
>>> +#define EXEC_OBJECT_SUPPORTS_48B_ADDRESS (1<<3)
>>> +#define __EXEC_OBJECT_UNKNOWN_FLAGS
>>> -(EXEC_OBJECT_SUPPORTS_48B_ADDRESS<<1)
>>> __u64 flags;
>>>
>>> __u64 rsvd1;
>>> diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
>>> index 14ea9f9..0856e60 100644
>>> --- a/intel/intel_bufmgr.c
>>> +++ b/intel/intel_bufmgr.c
>>> @@ -293,6 +293,17 @@ drm_intel_bo_madvise(drm_intel_bo *bo, int madv)
>>> }
>>>
>>> int
>>> +drm_intel_bo_use_48b_address_range(drm_intel_bo *bo, uint32_t enable)
>>> +{
>>> + if (bo->bufmgr->bo_use_48b_address_range) {
>>> + bo->bufmgr->bo_use_48b_address_range(bo, enable);
>>> + return 0;
>>> + }
>>> +
>>> + return -ENODEV;
>>> +}
>>> +
>>> +int
>>> drm_intel_bo_references(drm_intel_bo *bo, drm_intel_bo *target_bo)
>>> {
>>> return bo->bufmgr->bo_references(bo, target_bo);
>>> diff --git a/intel/intel_bufmgr.h b/intel/intel_bufmgr.h
>>> index 95eecb8..a14c78f 100644
>>> --- a/intel/intel_bufmgr.h
[PATCH] CHROMIUM: drm: bridge/dw_hdmi: Eliminate unused cable_plugin
On Sat, Sep 26, 2015 at 05:32:12PM -0300, Fabio Estevam wrote: > On Mon, Sep 21, 2015 at 11:15 AM, Russell King - ARM Linux > wrote: > > > My current patch stack for imx-drm related stuff looks like this at > > present: > > > > drm: bridge/dw_hdmi: place PHY into low power mode when disabled > > drm: bridge/dw_hdmi: start of support for pixel doubled modes > > drm: bridge/dw_hdmi: remove CEC engine register definitions > > drm: bridge/dw_hdmi-cec: add Designware HDMI CEC driver > > cec: add HDMI CEC input driver > > cec: add HDMI CEC core driver > > drm: bridge/dw_hdmi: replace CTS calculation for the ACR > > drm: bridge/dw_hdmi: remove ratio support from ACR code > > drm: bridge/dw_hdmi: adjust pixel clock values in N calculation > > drm: bridge/dw_hdmi: avoid being recursive in N calculation > > drm: bridge/dw_hdmi-ahb-audio: allow larger buffer sizes > > drm: bridge/dw_hdmi-ahb-audio: basic support for multi-channel PCM audio > > drm: bridge/dw_hdmi-ahb-audio: parse ELD from HDMI driver > > drm: bridge/dw_hdmi-ahb-audio: add audio driver > > drm: bridge/dw_hdmi: improve HDMI enable/disable handling > > drm: bridge/dw_hdmi: add connector mode forcing > > drm: bridge/dw_hdmi: add support for interlaced video modes > > gpu: imx: fix support for interlaced modes > > gpu: imx: simplify sync polarity setting > > > > I haven't yet decided what, if anything, from that stack I'm going to > > try to get into the next merge window. Given the lack of interest last > > time I posted these patches, I'm loosing interest myself in trying to > > get them merged, especially ones which are getting on for being 2 years > > old. > > These are all good material. Please consider getting them merged. If you want to see them merged, how about sending me an Acked-by for these patches? You were copied on them in August, and there was a deathly silence from _everyone_ on the initial set of patches. There's been a few changes to "gpu: imx: fix support for interlaced modes" and "drm: bridge/dw_hdmi-ahb-audio: add audio driver" as per the (little) review that was done in August, but other than that, the patches are essentially the same, just rebased on top of (now) -rc4. Maybe some people can also take a look at the CTS/N changes, and maybe back me up against Doug Anderson, so I'm not feeling like I can't merge those patches due to the lack of concensus. -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
[PATCH] CHROMIUM: drm: bridge/dw_hdmi: Eliminate unused cable_plugin
On Mon, Oct 5, 2015 at 4:17 PM, Russell King - ARM Linux wrote: > On Sat, Sep 26, 2015 at 05:32:12PM -0300, Fabio Estevam wrote: >> On Mon, Sep 21, 2015 at 11:15 AM, Russell King - ARM Linux >> wrote: >> >> > My current patch stack for imx-drm related stuff looks like this at >> > present: >> > >> > drm: bridge/dw_hdmi: place PHY into low power mode when disabled >> > drm: bridge/dw_hdmi: start of support for pixel doubled modes >> > drm: bridge/dw_hdmi: remove CEC engine register definitions >> > drm: bridge/dw_hdmi-cec: add Designware HDMI CEC driver >> > cec: add HDMI CEC input driver >> > cec: add HDMI CEC core driver >> > drm: bridge/dw_hdmi: replace CTS calculation for the ACR >> > drm: bridge/dw_hdmi: remove ratio support from ACR code >> > drm: bridge/dw_hdmi: adjust pixel clock values in N calculation >> > drm: bridge/dw_hdmi: avoid being recursive in N calculation >> > drm: bridge/dw_hdmi-ahb-audio: allow larger buffer sizes >> > drm: bridge/dw_hdmi-ahb-audio: basic support for multi-channel PCM audio >> > drm: bridge/dw_hdmi-ahb-audio: parse ELD from HDMI driver >> > drm: bridge/dw_hdmi-ahb-audio: add audio driver >> > drm: bridge/dw_hdmi: improve HDMI enable/disable handling >> > drm: bridge/dw_hdmi: add connector mode forcing >> > drm: bridge/dw_hdmi: add support for interlaced video modes >> > gpu: imx: fix support for interlaced modes >> > gpu: imx: simplify sync polarity setting >> > >> > I haven't yet decided what, if anything, from that stack I'm going to >> > try to get into the next merge window. Given the lack of interest last >> > time I posted these patches, I'm loosing interest myself in trying to >> > get them merged, especially ones which are getting on for being 2 years >> > old. >> >> These are all good material. Please consider getting them merged. > > If you want to see them merged, how about sending me an Acked-by for > these patches? You were copied on them in August, and there was a > deathly silence from _everyone_ on the initial set of patches. Sure, will go through each one the patches. Just give me one day or two. Regards, Fabio Estevam
[Bug 92269] (Unity3D) A small game Sol 0 have graphic glitches
https://bugs.freedesktop.org/show_bug.cgi?id=92269 --- Comment #1 from Krzysztof A. Sobiecki --- Created attachment 118682 --> https://bugs.freedesktop.org/attachment.cgi?id=118682&action=edit Works on intel with mesa 11.0 Works on mesa from debian with intel driver, probably only amd problem *** 11.0.2-1 506 506 ftp://ftp.pl.debian.org/debian experimental/main amd64 Packages 100 /var/lib/dpkg/status -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/3faa7090/attachment.html>
[Bug 92269] (Unity3D) A small game Sol 0 have graphic glitches
https://bugs.freedesktop.org/show_bug.cgi?id=92269 Krzysztof A. Sobiecki changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/78f741d3/attachment.html>
[Bug 91656] Pillars of Eternity glitch in maps
https://bugs.freedesktop.org/show_bug.cgi?id=91656 --- Comment #8 from Edmondo Tommasina --- Thanks Daniel. Reverting commit c1de7df6d4086070e63369ab0af3950f53a03592 fixes the map issue on my EVERGREEN (HD5850). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/9d6af840/attachment.html>
[Bug 92269] (Unity3D) A small game Sol 0 have graphic glitches
https://bugs.freedesktop.org/show_bug.cgi?id=92269 --- Comment #2 from Krzysztof A. Sobiecki --- A working trace from Intel driver: https://drive.google.com/file/d/0B3J0Mg89izcbbDBpZkhZN0dtTUE/view?usp=sharing -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/48b7bd8b/attachment.html>
[Bug 92266] Unigine Valley hangs up on 3840x2160 resolution on R390X, while lower resolutions work
https://bugs.freedesktop.org/show_bug.cgi?id=92266 MC Return changed: What|Removed |Added Summary|Unigine Valley hangs up on |Unigine Valley hangs up on |3840x2160 and 2560x1600 |3840x2160 resolution on |resolutions on R390X, while |R390X, while lower |lower resolutions work |resolutions work -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/1ff6474d/attachment-0001.html>
[Bug 92266] Unigine Valley hangs up on 3840x2160 resolution on R390X, while lower resolutions work
https://bugs.freedesktop.org/show_bug.cgi?id=92266 --- Comment #2 from MC Return --- With a recent kernel upgrade to 4.3-rc4 the benchmark finished in 2560x1600 for the first time. 3840x2160 still crashes Valley reliably in scene 9. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/a202af8a/attachment.html>
[Bug 92301] Unigine Sanctuary freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92301 Bug ID: 92301 Summary: Unigine Sanctuary freeze-crashes R390X Product: Mesa Version: 11.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: mc.return at gmx.net QA Contact: dri-devel at lists.freedesktop.org I understand that this benchmark might not use the latest version of the Unigine engine, but starting it should not make my machine lock up with actual high-end hardware, especially since the benchmark works flawless on pre-GCN AMD hardware. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/21d27b2f/attachment.html>
[Bug 92302] Unigine Tropics freeze-crashes R390X
https://bugs.freedesktop.org/show_bug.cgi?id=92302 Bug ID: 92302 Summary: Unigine Tropics freeze-crashes R390X Product: Mesa Version: 11.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: mc.return at gmx.net QA Contact: dri-devel at lists.freedesktop.org I understand that this benchmark might not use the latest version of the Unigine engine, but starting it should not make my machine lock up with actual high-end hardware, especially since the benchmark works flawless on pre-GCN AMD hardware. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/f3a1cb24/attachment.html>
[Bug 92269] (Unity3D) A small game Sol 0 have graphic glitches
https://bugs.freedesktop.org/show_bug.cgi?id=92269 --- Comment #3 from Krzysztof A. Sobiecki --- It have same problems with LIBGL_ALWAYS_SOFTWARE set... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/29284fe7/attachment.html>
[Bug 92303] [radeonsi] Buffer sharing (with/without IOMMU) locks up GPU display with dGPU only
https://bugs.freedesktop.org/show_bug.cgi?id=92303 Bug ID: 92303 Summary: [radeonsi] Buffer sharing (with/without IOMMU) locks up GPU display with dGPU only Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: shawn.starr at rogers.com Kernel: 4.3.0-0.rc3.git3.2.fc24.x86_64 Mesa: git master (mesa-libGL-11.0.0-0.devel.70.20150926.fc22.x86_64) libdrm: (Sept 16th build) kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.3.0-0.rc3.git3.2.fc24.x86_64 root=UUID=f834b05c-55f3-407b-9a63-fc6b04d4c845 ro rhgb slub_debug=- cgroup_disable=memory console=tty0 console=ttyS0,115200n8 nmi_watchdog=0 i915.powersave=1 intel_iommu=igfx_off vfio_iommu_type1.allow_unsafe_interrupts=1 zswap.zpool=zsmalloc zswap.enabled=1 video=LVDS-1:d video=VGA-0:e pcie_aspm=off i915.enable_rc6=1 i915.enable_fbc=1 intel_iommu=on audit=0 rd.driver.blacklist=amdgpu radeon.gartsize=8192 intel_iommu=off When trying to play ARK with high level graphics options, GPU fails to recover on reset, setting GART to 2048 or 8192 results in same fault. If I keep graphics - textures - to high vs ultimate, the game works. I've attached various logs from the fault. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/eb5d1058/attachment.html>
[Bug 92303] [radeonsi] Buffer sharing (with/without IOMMU) locks up GPU display with dGPU only
https://bugs.freedesktop.org/show_bug.cgi?id=92303 --- Comment #1 from Shawn Starr --- Created attachment 118685 --> https://bugs.freedesktop.org/attachment.cgi?id=118685&action=edit XOrg log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/425b38af/attachment.html>
[Bug 92303] [radeonsi] Buffer sharing (with/without IOMMU) locks up GPU display with dGPU only
https://bugs.freedesktop.org/show_bug.cgi?id=92303 --- Comment #2 from Shawn Starr --- Created attachment 118686 --> https://bugs.freedesktop.org/attachment.cgi?id=118686&action=edit dmesg w/ IOMMU enabled output -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/f1187310/attachment-0001.html>
[Bug 92303] [radeonsi] Buffer sharing (with/without IOMMU) locks up GPU display with dGPU only
https://bugs.freedesktop.org/show_bug.cgi?id=92303 --- Comment #3 from Shawn Starr --- Created attachment 118687 --> https://bugs.freedesktop.org/attachment.cgi?id=118687&action=edit dmesg w/ no IOMMU enabled -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/b16ac0f7/attachment.html>
[Bug 92303] [radeonsi] Buffer sharing (with/without IOMMU) locks up GPU display with dGPU only
https://bugs.freedesktop.org/show_bug.cgi?id=92303 --- Comment #4 from Shawn Starr --- Video result: https://www.youtube.com/watch?v=K-y-fsLlAAw -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/781ca274/attachment.html>
[PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver
On Mon, Sep 07, 2015 at 03:44:43PM +0200, Hans Verkuil wrote:
> + if (status & CEC_STATUS_TX_DONE) {
> + if (status & CEC_STATUS_TX_ERROR) {
> + dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
> + cec->tx = STATE_ERROR;
> + } else {
> + dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
> + cec->tx = STATE_DONE;
> + }
> + s5p_clr_pending_tx(cec);
> + }
Your CEC implementation seems to be written around the idea that there
are only two possible outcomes from a CEC message - "done" and "error",
which get translated to:
> + case STATE_DONE:
> + cec_transmit_done(cec->adap, CEC_TX_STATUS_OK);
> + cec->tx = STATE_IDLE;
> + break;
> + case STATE_ERROR:
> + cec_transmit_done(cec->adap, CEC_TX_STATUS_RETRY_TIMEOUT);
> + cec->tx = STATE_IDLE;
"okay" and "retry_timeout". So, if we have an adapter which can report
(eg) a NACK, we have to report it as the obscure "retry timeout" status?
Why this obscure naming - why can't we have something that uses the
terminology in the spec?
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
[Bug 91278] Tonga GPU lock/reset fail with Unigine Valley
https://bugs.freedesktop.org/show_bug.cgi?id=91278 --- Comment #28 from Mathias Tillman --- (In reply to Andy Furniss from comment #27) > Created attachment 118665 [details] > valley vm fault dump > > Aha, here it is. I am getting similar results using check_vm. However, since the hang usually doesn't happen after the first vm fail (it did actually for me a few times, but most of the time it didn't) I modified the mesa code to disable closing the program once a vm fault happened. Unfortunately this doesn't really provide me with any interesting information - they have all complained about the paging fault happening in a VERTEX_BUFFER with an identical, or close to identical address. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/2fe23108/attachment.html>
[Bug 92270] Radeon R7 M260/M265 - *ERROR* amdgpu: ring 0 test failed (scratch(0xC040)=0xCAFEDEAD)
https://bugs.freedesktop.org/show_bug.cgi?id=92270 --- Comment #3 from Ederson --- Well, I've said "properly loaded" because `amdgpu` is listed on `lsmod`. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/b9fff9ad/attachment.html>
[Bug 92269] (Unity3D) A small game Sol 0 have graphic glitches
https://bugs.freedesktop.org/show_bug.cgi?id=92269 --- Comment #4 from Daniel Scharrer --- Was the r600 trace also recorded with mesa 11.0.2 or a different version? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/4c42fea3/attachment.html>
[PATCH v4 1/2] create SMAF module
On 10/05/2015 03:11 AM, Benjamin Gaignard wrote:
> diff --git a/drivers/smaf/smaf-core.c b/drivers/smaf/smaf-core.c
> new file mode 100644
> index 000..37914e7
> --- /dev/null
> +++ b/drivers/smaf/smaf-core.c
> @@ -0,0 +1,736 @@
> +/*
> + * smaf.c
> + *
> + * Copyright (C) Linaro SA 2015
> + * Author: Benjamin Gaignard for Linaro.
> + * License terms: GNU General Public License (GPL), version 2
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct smaf_handle {
> + struct dma_buf *dmabuf;
> + struct smaf_allocator *allocator;
> + struct dma_buf *db_alloc;
> + size_t length;
> + unsigned int flags;
> + int fd;
> + bool is_secure;
> + void *secure_ctx;
> +};
> +
> +/**
> + * struct smaf_device - smaf device node private data
> + * @misc_dev:the misc device
> + * @head:list of allocator
> + * @lock:list and secure pointer mutex
> + * @secure: pointer to secure functions helpers
> + */
> +struct smaf_device {
> + struct miscdevice misc_dev;
> + struct list_head head;
> + /* list and secure pointer lock*/
> + struct mutex lock;
> + struct smaf_secure *secure;
> +};
> +
> +static struct smaf_device smaf_dev;
> +
> +/**
> + * smaf_allow_cpu_access return true if CPU can access to memory
> + * if their is no secure module associated to SMAF assume that CPU can get
> + * access to the memory.
> + */
> +static bool smaf_allow_cpu_access(struct smaf_handle *handle,
> + unsigned long flags)
> +{
> + if (!handle->is_secure)
> + return true;
> +
> + if (!smaf_dev.secure)
> + return true;
> +
> + if (!smaf_dev.secure->allow_cpu_access)
> + return true;
> +
> + return smaf_dev.secure->allow_cpu_access(handle->secure_ctx, flags);
> +}
> +
> +static int smaf_grant_access(struct smaf_handle *handle, struct device *dev,
> + dma_addr_t addr, size_t size,
> + enum dma_data_direction dir)
> +{
> + if (!handle->is_secure)
> + return 0;
> +
> + if (!smaf_dev.secure)
> + return -EINVAL;
> +
> + if (!smaf_dev.secure->grant_access)
> + return -EINVAL;
> +
> + return smaf_dev.secure->grant_access(handle->secure_ctx,
> + dev, addr, size, dir);
> +}
> +
> +static void smaf_revoke_access(struct smaf_handle *handle, struct device
> *dev,
> +dma_addr_t addr, size_t size,
> +enum dma_data_direction dir)
> +{
> + if (!handle->is_secure)
> + return;
> +
> + if (!smaf_dev.secure)
> + return;
> +
> + if (!smaf_dev.secure->revoke_access)
> + return;
> +
> + smaf_dev.secure->revoke_access(handle->secure_ctx,
> +dev, addr, size, dir);
> +}
> +
> +static int smaf_secure_handle(struct smaf_handle *handle)
> +{
> + if (handle->is_secure)
> + return 0;
> +
> + if (!smaf_dev.secure)
> + return -EINVAL;
> +
> + if (!smaf_dev.secure->create_context)
> + return -EINVAL;
> +
> + handle->secure_ctx = smaf_dev.secure->create_context();
> +
> + if (!handle->secure_ctx)
> + return -EINVAL;
> +
> + handle->is_secure = true;
> + return 0;
> +}
> +
> +static int smaf_unsecure_handle(struct smaf_handle *handle)
> +{
> + if (!handle->is_secure)
> + return 0;
> +
> + if (!smaf_dev.secure)
> + return -EINVAL;
> +
> + if (!smaf_dev.secure->destroy_context)
> + return -EINVAL;
> +
> + if (smaf_dev.secure->destroy_context(handle->secure_ctx))
> + return -EINVAL;
> +
> + handle->secure_ctx = NULL;
> + handle->is_secure = false;
> + return 0;
> +}
All these functions need to be protected by a lock, otherwise the
secure state could change. For that matter, I think the smaf_handle
needs a lock to protect its state as well for places like map_dma_buf
>
> +static long smaf_ioctl(struct file *file, unsigned int cmd, unsigned long
> arg)
> +{
> + switch (cmd) {
> + case SMAF_IOC_CREATE:
> + {
> + struct smaf_create_data data;
> + struct smaf_handle *handle;
> +
> + if (copy_from_user(&data, (void __user *)arg, _IOC_SIZE(cmd)))
> + return -EFAULT;
> +
> + handle = smaf_create_handle(data.length, data.flags);
> + if (!handle)
> + return -EINVAL;
> +
> + if (data.name[0]) {
> + /* user force allocator selection */
> + if (smaf_select_allocator_by_name(handle->dmabuf,
> + data.name)) {
> + dma_buf_put(handle->dmab
[PATCH v4 0/2] RFC: Secure Memory Allocation Framework
On 10/05/2015 03:11 AM, Benjamin Gaignard wrote:
> version 4 changes:
> - rebased on kernel 4.3-rc3
> - fix missing EXPORT_SYMBOL for smaf_create_handle()
>
> version 3 changes:
> - Remove ioctl for allocator selection instead provide the name of
> the targeted allocator with allocation request.
> Selecting allocator from userland isn't the prefered way of working
> but is needed when the first user of the buffer is a software component.
> - Fix issues in case of error while creating smaf handle.
> - Fix module license.
> - Update libsmaf and tests to care of the SMAF API evolution
> https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
>
> version 2 changes:
> - Add one ioctl to allow allocator selection from userspace.
> This is required for the uses case where the first user of
> the buffer is a software IP which can't perform dma_buf attachement.
> - Add name and ranking to allocator structure to be able to sort them.
> - Create a tiny library to test SMAF:
> https://git.linaro.org/people/benjamin.gaignard/libsmaf.git
> - Fix one issue when try to secure buffer without secure module registered
>
> The outcome of the previous RFC about how do secure data path was the need
> of a secure memory allocator (https://lkml.org/lkml/2015/5/5/551)
>
> SMAF goal is to provide a framework that allow allocating and securing
> memory by using dma_buf. Each platform have it own way to perform those two
> features so SMAF design allow to register helper modules to perform them.
>
> To be sure to select the best allocation method for devices SMAF implement
> deferred allocation mechanism: memory allocation is only done when the first
> device effectively required it.
> Allocator modules have to implement a match() to let SMAF know if they are
> compatibles with devices needs.
> This patch set provide an example of allocator module which use
> dma_{alloc/free/mmap}_attrs() and check if at least one device have
> coherent_dma_mask set to DMA_BIT_MASK(32) in match function.
> I have named smaf-cma.c like it is done for drm_gem_cma_helper.c even if
> a better name could be found for this file.
>
> Secure modules are responsibles of granting and revoking devices access rights
> on the memory. Secure module is also called to check if CPU map memory into
> kernel and user address spaces.
> An example of secure module implementation can be found here:
> http://git.linaro.org/people/benjamin.gaignard/optee-sdp.git
> This code isn't yet part of the patch set because it depends on generic TEE
> which is still under discussion (https://lwn.net/Articles/644646/)
>
> For allocation part of SMAF code I get inspirated by Sumit Semwal work about
> constraint aware allocator.
>
Overall I like the abstraction. Do you have a use case in mind right now for
the best allocation method? Some of the classic examples (mmu vs. no mmu)
are gradually becoming less relevant as the systems have evolved. I was
discussing constraints with Sumit w.r.t. Ion at plumbers so I'm curious about
your uses.
Thanks,
Laura
[PATCH][RESEND] drm: panel-simple: add URT UMSH-8596MD-xT panel support
Hi Thierry, On 05.10.2015 13:01, Thierry Reding wrote: >> On 01.09.2015 15:50, Maciej S. Szmigiero wrote: >>> This patch adds support for United Radiant Technology >>> UMSH-8596MD-xT 7.0" WVGA TFT LCD panels >>> (both LVDS and parallel versions) to DRM >>> panel-simple driver. >>> >>> Signed-off-by: Maciej Szmigiero >>> --- >>> This is a resend without changes. >>> >>> diff --git a/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt >>> b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt >>> new file mode 100644 >>> index 000..2990e6b >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/panel/urt,umsh-8596md.txt >>> @@ -0,0 +1,11 @@ >>> +United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel >>> + >>> +Supported are LVDS versions (-11T, -19T) and parallel ones >>> +(-T, -1T, -7T, -20T). > > Please don't use this kind of wildcard compatible values. If these are > different models then each of them deserves a separate compatible > string. The differences between these revisions are like different maximum backlight luminance or presence / absence of touch panel. None of this changes panel timings - should they be split into different compatible values anyway? >>> You might want to >>> split the DT binding and vendor prefix to separate patches. >> >> Do you mean to first submit new vendor prefix then panel patch with docs? >> Or even docs separately? > > This should be three patches: the vendor prefix is usually a separate > patch and needs an Acked-by from one of the device tree bindings > maintainers. The binding itself should also be a separate patch and the > driver changes should come last. I will split the patch and first submit DT binding docs. > Thierry Best regards, Maciej
[PATCH 1/5] ASoC : dwc : support dw i2s in slave mode
On Fri, Sep 25, 2015 at 05:48:22PM -0400, Alex Deucher wrote: > From: Maruthi Srinivas Bayyavarapu > > dw i2s controller can work in slave mode, codec being master. > dw i2s is made to support master/slave operation, by reading dwc > register. I'll apply this but can you please send a followup implementing a _dai_fmt() operation that checks to make sure that the mode we're setting corresponds to what we read back from the hardware. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/1d396e54/attachment.sig>
[PATCH 2/5] ASoC : dwc : support dw i2s in AMD platform
On Fri, Sep 25, 2015 at 05:48:23PM -0400, Alex Deucher wrote:
> From: Maruthi Srinivas Bayyavarapu
>
> Vendor specific quirk was added to:
> 1. Support AMD platform which has two dwc controllers with different
>base address for playback and capture. Also, I2S_COMP_PARAM_*
>registers offsets differed.
> 2. Resume audio which was active before system suspend.
>After 'resume', dwc need to be reconfigured with params
>configured during 'hw_params' callback. With this, audio usecase
>continues from where it got stopped because of 'suspend'.
This is hard to review since there are several different changes in
here, one change per commit is muuch more helpful. As is I'm not 100%
sure exactly what each bit of the change is intended to do. One example
here is that a separate patch splitting pbase and cbase would be really
helpful.
> --- a/include/sound/designware_i2s.h
> +++ b/include/sound/designware_i2s.h
> @@ -44,6 +44,9 @@ struct i2s_platform_data {
> int channel;
> u32 snd_fmts;
> u32 snd_rates;
> + #define DW_I2S_VENDOR_AMD (1 << 0)
> + unsigned int quirks;
I would expect to see a set of quirks with the AMD devices selecting
those that apply to them rather than just a per vendor define - this
is more generic and more maintainable long term. AMD may require
different sets of quirks with some future device and systems from other
vendors may require some but not all of the quirks that AMD requires.
> + if (dev->quirks & DW_I2S_VENDOR_AMD) {
> + comp1 = i2s_read_reg(dev->i2s_pbase, 0x124);
> + comp2 = i2s_read_reg(dev->i2s_pbase, 0x120);
Please add defines for these registers. Rather than having the quirk
code throughout the driver it might be clearer to have the comp1 and
comp2 register offsets stored in the driver data so you can just do the
actual quirk once at probe time.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151005/00250f24/attachment.sig>
[Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro
On Mon, Oct 5, 2015 at 9:23 AM, Lukas Wunner wrote: > Hi, > > I've also pushed this series to GitHub now to ease reviewing: > https://github.com/l1k/linux/commits/mbp_switcheroo_v3 So to test this all someone has to do is pull this and try it? No patching required? > Thanks, > > Lukas > ___ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau -- Home http://evanfoss.googlepages.com/ Work http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
[PATCH 11/15] sfc: don't call dma_supported
On 03/10/15 16:19, Christoph Hellwig wrote: > dma_set_mask already checks for a supported DMA mask before updating it, > the call to dma_supported is redundant. > > Signed-off-by: Christoph Hellwig Acked-by: Bert Kenward The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited.
[PATCH v9 0/4] Allow USB devices to remain runtime-suspended when sleeping
On Monday, October 05, 2015 04:45:28 PM Tomeu Vizoso wrote: > Hi, > > this is v9 of an attempt to make it easier for devices to remain in > runtime PM when the system goes to sleep, mainly to reduce the time > spent resuming devices. > > For this, we interpret the absence of all PM callback implementations as > it being safe to do direct_complete, so their ancestors aren't prevented > from remaining runtime-suspended. > > Additionally, the prepare() callback of USB devices will return 1 if > runtime PM is enabled and the current wakeup settings are correct. > > With these changes, a uvcvideo device (for example) stays in runtime > suspend when the system goes to sleep and is left in that state when the > system resumes, not delaying it unnecessarily. > > Thanks, > > Tomeu > > Changes in v9: > - Add docs noting the need for the device lock to be held before calling > device_is_bound() > - Add docs noting the need for the device lock to be held before calling > dev_pm_domain_set() > - Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf. > - Rename from device_check_pm_callbacks to device_pm_check_callbacks to > follow with the naming convention of existing API. > - Re-add calling to device_pm_check_callbacks from device registration > and when updating the PM domain of a device. > > Changes in v8: > - Add device_is_bound() > - Add dev_pm_domain_set() and update code to use it > - Move no_pm_callbacks field into CONFIG_PM_SLEEP > - Call device_check_pm_callbacks only after a device is bound or unbound > > Changes in v7: > - Reduce indentation by adding a label in device_prepare() > > Changes in v6: > - Add stub for !CONFIG_PM. > - Move implementation of device_check_pm_callbacks to power/main.c as it > doesn't belong to CONFIG_PM_SLEEP. > - Take dev->power.lock before modifying flag. > > Changes in v5: > - Check for all dev_pm_ops instances associated to a device, updating a > no_pm_callbacks flag at the times when that could change. > > Tomeu Vizoso (4): > device core: add device_is_bound() > PM / Domains: add setter for dev.pm_domain > PM / sleep: Go direct_complete if driver has no callbacks > USB / PM: Allow USB devices to remain runtime-suspended when sleeping > > arch/arm/mach-omap2/omap_device.c | 7 --- > drivers/acpi/acpi_lpss.c | 5 +++-- > drivers/acpi/device_pm.c | 5 +++-- > drivers/base/dd.c | 21 +++-- > drivers/base/power/clock_ops.c| 5 +++-- > drivers/base/power/common.c | 24 > drivers/base/power/domain.c | 6 -- > drivers/base/power/main.c | 35 +++ > drivers/base/power/power.h| 3 +++ > drivers/gpu/vga/vga_switcheroo.c | 10 +- > drivers/misc/mei/pci-me.c | 5 +++-- > drivers/misc/mei/pci-txe.c| 5 +++-- > drivers/usb/core/port.c | 6 ++ > drivers/usb/core/usb.c| 11 ++- > include/linux/device.h| 2 ++ > include/linux/pm.h| 1 + > include/linux/pm_domain.h | 3 +++ > 17 files changed, 131 insertions(+), 23 deletions(-) The series looks good to me now, but patch [4/4] needs an ACK from the USB maintainers and patch [1/4] needs an ACK from Greg. Thanks, Rafael
[PATCH v9 0/4] Allow USB devices to remain runtime-suspended when sleeping
On 5 October 2015 at 16:45, Tomeu Vizoso wrote: > Hi, > > this is v9 of an attempt to make it easier for devices to remain in > runtime PM when the system goes to sleep, mainly to reduce the time > spent resuming devices. > > For this, we interpret the absence of all PM callback implementations as > it being safe to do direct_complete, so their ancestors aren't prevented > from remaining runtime-suspended. > > Additionally, the prepare() callback of USB devices will return 1 if > runtime PM is enabled and the current wakeup settings are correct. > > With these changes, a uvcvideo device (for example) stays in runtime > suspend when the system goes to sleep and is left in that state when the > system resumes, not delaying it unnecessarily. > > Thanks, > > Tomeu > > Changes in v9: > - Add docs noting the need for the device lock to be held before calling > device_is_bound() > - Add docs noting the need for the device lock to be held before calling > dev_pm_domain_set() > - Move to CONFIG_PM_SLEEP as suggested by Rafael and Ulf. > - Rename from device_check_pm_callbacks to device_pm_check_callbacks to > follow with the naming convention of existing API. > - Re-add calling to device_pm_check_callbacks from device registration > and when updating the PM domain of a device. > > Changes in v8: > - Add device_is_bound() > - Add dev_pm_domain_set() and update code to use it > - Move no_pm_callbacks field into CONFIG_PM_SLEEP > - Call device_check_pm_callbacks only after a device is bound or unbound > > Changes in v7: > - Reduce indentation by adding a label in device_prepare() > > Changes in v6: > - Add stub for !CONFIG_PM. > - Move implementation of device_check_pm_callbacks to power/main.c as it > doesn't belong to CONFIG_PM_SLEEP. > - Take dev->power.lock before modifying flag. > > Changes in v5: > - Check for all dev_pm_ops instances associated to a device, updating a > no_pm_callbacks flag at the times when that could change. > > Tomeu Vizoso (4): > device core: add device_is_bound() > PM / Domains: add setter for dev.pm_domain > PM / sleep: Go direct_complete if driver has no callbacks > USB / PM: Allow USB devices to remain runtime-suspended when sleeping > > arch/arm/mach-omap2/omap_device.c | 7 --- > drivers/acpi/acpi_lpss.c | 5 +++-- > drivers/acpi/device_pm.c | 5 +++-- > drivers/base/dd.c | 21 +++-- > drivers/base/power/clock_ops.c| 5 +++-- > drivers/base/power/common.c | 24 > drivers/base/power/domain.c | 6 -- > drivers/base/power/main.c | 35 +++ > drivers/base/power/power.h| 3 +++ > drivers/gpu/vga/vga_switcheroo.c | 10 +- > drivers/misc/mei/pci-me.c | 5 +++-- > drivers/misc/mei/pci-txe.c| 5 +++-- > drivers/usb/core/port.c | 6 ++ > drivers/usb/core/usb.c| 11 ++- > include/linux/device.h| 2 ++ > include/linux/pm.h| 1 + > include/linux/pm_domain.h | 3 +++ > 17 files changed, 131 insertions(+), 23 deletions(-) > > -- > 2.4.3 > This looks good to me, for the series you may add: Reviewed-by: Ulf Hansson Kind regards Uffe
[Nouveau] [PATCH v3 0/6] Enable gpu switching on the MacBook Pro
On Mon, Oct 5, 2015 at 11:17 AM, Lukas Wunner wrote: > Hi Evan, > > On Mon, Oct 05, 2015 at 10:15:53AM -0400, Evan Foss wrote: >> On Mon, Oct 5, 2015 at 9:23 AM, Lukas Wunner wrote: >> > I've also pushed this series to GitHub now to ease reviewing: >> > https://github.com/l1k/linux/commits/mbp_switcheroo_v3 >> >> So to test this all someone has to do is pull this and try it? No >> patching required? > > Yes. But if you don't already have a kernel git repo, this will be > a > 1 GByte download. 2012 Macbook Pro 9,2 $ dmesg|grep Apple [0.00] efi: EFI v1.10 by Apple [0.00] DMI: Apple Inc. MacBookPro9,1/Mac- 4B7AC7E43945597E, BIOS MBP91.88Z.00D3.B08.1208081132 08/08/2012 > Which MacBook Pro model do you want to test this on? As noted in the > cover letter, this will only work on pre-retinas and only if the > apple-gmux module loads before the DRM drivers. You can try to ensure > the latter by editing modules.dep, or grab this tarball which contains > reprobing patches on top: > http://wunner.de/mbp_switcheroo_v3_reprobe_4.3-rc4pre.tar.gz Ok thanks > Best regards, > > Lukas Evan -- Home http://evanfoss.googlepages.com/ Work http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
[PATCH 01/15] pcnet32: use pci_set_dma_mask insted of pci_dma_supported
On Sat, 2015-10-03 at 17:19 +0200, Christoph Hellwig wrote:
> This ensures the dma mask that is supported by the driver is recorded
> in the device structure.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/net/ethernet/amd/pcnet32.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Acked-by: Don Fry
> diff --git a/drivers/net/ethernet/amd/pcnet32.c
> b/drivers/net/ethernet/amd/pcnet32.c
> index bc8b04f..e2afabf 100644
> --- a/drivers/net/ethernet/amd/pcnet32.c
> +++ b/drivers/net/ethernet/amd/pcnet32.c
> @@ -1500,7 +1500,7 @@ pcnet32_probe_pci(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> return -ENODEV;
> }
>
> - if (!pci_dma_supported(pdev, PCNET32_DMA_MASK)) {
> + if (!pci_set_dma_mask(pdev, PCNET32_DMA_MASK)) {
> if (pcnet32_debug & NETIF_MSG_PROBE)
> pr_err("architecture does not support 32bit PCI
> busmaster DMA\n");
> return -ENODEV;
