[PATCH] drm: msm: remove unused variable
A recent cleanup removed the only user of the 'kms' variable in
msm_preclose(), causing a harmless compiler warning:
drivers/gpu/drm/msm/msm_drv.c: In function 'msm_preclose':
drivers/gpu/drm/msm/msm_drv.c:468:18: error: unused variable 'kms'
[-Werror=unused-variable]
This removes the variable as well.
Signed-off-by: Arnd Bergmann
Fixes: 4016260ba47a ("drm/msm: fix bug after preclose removal")
---
drivers/gpu/drm/msm/msm_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index c03b96709179..701c51ed3e7c 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -465,7 +465,6 @@ static void msm_preclose(struct drm_device *dev, struct
drm_file *file)
{
struct msm_drm_private *priv = dev->dev_private;
struct msm_file_private *ctx = file->driver_priv;
- struct msm_kms *kms = priv->kms;
mutex_lock(&dev->struct_mutex);
if (ctx == priv->lastctx)
--
2.7.0
[PATCH 6/6] drm/fsl-dcu: implement lastclose callback
Use CMA helper drm_fbdev_cma_restore_mode to restore fbdev mode
in process which uses drm/kms dies.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index f9227b7..ef41bde 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -168,6 +168,13 @@ static void fsl_dcu_drm_disable_vblank(struct drm_device
*dev,
regmap_write(fsl_dev->regmap, DCU_INT_MASK, value);
}
+static void fsl_dcu_drm_lastclose(struct drm_device *dev)
+{
+ struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+
+ drm_fbdev_cma_restore_mode(fsl_dev->fbdev);
+}
+
static const struct file_operations fsl_dcu_drm_fops = {
.owner = THIS_MODULE,
.open = drm_open,
@@ -185,6 +192,7 @@ static const struct file_operations fsl_dcu_drm_fops = {
static struct drm_driver fsl_dcu_drm_driver = {
.driver_features= DRIVER_HAVE_IRQ | DRIVER_GEM | DRIVER_MODESET
| DRIVER_PRIME | DRIVER_ATOMIC,
+ .lastclose = fsl_dcu_drm_lastclose,
.load = fsl_dcu_load,
.unload = fsl_dcu_unload,
.irq_handler= fsl_dcu_drm_irq,
--
2.8.0
[PATCH 5/6] drm/fsl-dcu: disable output polling on driver unload
Disabling output polling before unloading the driver.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 182578d..f9227b7 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -91,6 +91,8 @@ static int fsl_dcu_load(struct drm_device *dev, unsigned long
flags)
return 0;
done:
+ drm_kms_helper_poll_fini(dev);
+
if (fsl_dev->fbdev)
drm_fbdev_cma_fini(fsl_dev->fbdev);
@@ -106,6 +108,8 @@ static int fsl_dcu_unload(struct drm_device *dev)
{
struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+ drm_kms_helper_poll_fini(dev);
+
if (fsl_dev->fbdev)
drm_fbdev_cma_fini(fsl_dev->fbdev);
--
2.8.0
[PATCH 4/6] drm/fsl-dcu: deallocate fbdev CMA on unload
Free fbdev CMA using drm_fbdev_cma_fini on unload. This fixes
a warning when unloading the driver:
WARNING: CPU: 0 PID: 164 at drivers/gpu/drm/drm_crtc.c:5930
drm_mode_config_cleanup+0x204/0x208
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 9cbabb2..182578d 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include
#include "fsl_dcu_drm_crtc.h"
@@ -90,6 +91,9 @@ static int fsl_dcu_load(struct drm_device *dev, unsigned long
flags)
return 0;
done:
+ if (fsl_dev->fbdev)
+ drm_fbdev_cma_fini(fsl_dev->fbdev);
+
drm_mode_config_cleanup(dev);
drm_vblank_cleanup(dev);
drm_irq_uninstall(dev);
@@ -100,6 +104,11 @@ done:
static int fsl_dcu_unload(struct drm_device *dev)
{
+ struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+
+ if (fsl_dev->fbdev)
+ drm_fbdev_cma_fini(fsl_dev->fbdev);
+
drm_mode_config_cleanup(dev);
drm_vblank_cleanup(dev);
drm_irq_uninstall(dev);
--
2.8.0
[PATCH 3/6] drm/fsl-dcu: use variable name dev for struct drm_device
The driver uses different variable names for struct drm_device
across functions which is confusing. Stick to the more common
variable name dev. While at it, remove unnecessary if statement
in error handling.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index f62bff2..9cbabb2 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -63,40 +63,37 @@ static int fsl_dcu_drm_irq_init(struct drm_device *dev)
return ret;
}
-static int fsl_dcu_load(struct drm_device *drm, unsigned long flags)
+static int fsl_dcu_load(struct drm_device *dev, unsigned long flags)
{
- struct device *dev = drm->dev;
- struct fsl_dcu_drm_device *fsl_dev = drm->dev_private;
+ struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
int ret;
ret = fsl_dcu_drm_modeset_init(fsl_dev);
if (ret < 0) {
- dev_err(dev, "failed to initialize mode setting\n");
+ dev_err(dev->dev, "failed to initialize mode setting\n");
return ret;
}
- ret = drm_vblank_init(drm, drm->mode_config.num_crtc);
+ ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
if (ret < 0) {
- dev_err(dev, "failed to initialize vblank\n");
+ dev_err(dev->dev, "failed to initialize vblank\n");
goto done;
}
- drm->vblank_disable_allowed = true;
+ dev->vblank_disable_allowed = true;
- ret = fsl_dcu_drm_irq_init(drm);
+ ret = fsl_dcu_drm_irq_init(dev);
if (ret < 0)
goto done;
- drm->irq_enabled = true;
+ dev->irq_enabled = true;
- fsl_dcu_fbdev_init(drm);
+ fsl_dcu_fbdev_init(dev);
return 0;
done:
- if (ret) {
- drm_mode_config_cleanup(drm);
- drm_vblank_cleanup(drm);
- drm_irq_uninstall(drm);
- drm->dev_private = NULL;
- }
+ drm_mode_config_cleanup(dev);
+ drm_vblank_cleanup(dev);
+ drm_irq_uninstall(dev);
+ dev->dev_private = NULL;
return ret;
}
--
2.8.0
[PATCH 2/6] drm/fsl-dcu: handle missing panel gracefully
If the device tree property fsl,panel is missing, drm_panel_attach
is called with a NULL pointer as first argument. Having a panel is
basically mandatory since RGB is the only supported connector.
Check if a panel node has been found, return -ENODEV and cleanup
otherwise.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index a07886f..819fe12 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -171,14 +171,18 @@ int fsl_dcu_drm_connector_create(struct
fsl_dcu_drm_device *fsl_dev,
DRM_MODE_DPMS_OFF);
panel_node = of_parse_phandle(fsl_dev->np, "fsl,panel", 0);
- if (panel_node) {
- fsl_dev->connector.panel = of_drm_find_panel(panel_node);
- if (!fsl_dev->connector.panel) {
- ret = -EPROBE_DEFER;
- goto err_sysfs;
- }
- of_node_put(panel_node);
+ if (!panel_node) {
+ dev_err(fsl_dev->dev, "fsl,panel property not found\n");
+ ret = -ENODEV;
+ goto err_sysfs;
+ }
+
+ fsl_dev->connector.panel = of_drm_find_panel(panel_node);
+ if (!fsl_dev->connector.panel) {
+ ret = -EPROBE_DEFER;
+ goto err_panel;
}
+ of_node_put(panel_node);
ret = drm_panel_attach(fsl_dev->connector.panel, connector);
if (ret) {
@@ -188,6 +192,8 @@ int fsl_dcu_drm_connector_create(struct fsl_dcu_drm_device
*fsl_dev,
return 0;
+err_panel:
+ of_node_put(panel_node);
err_sysfs:
drm_connector_unregister(connector);
err_cleanup:
--
2.8.0
[PATCH 1/6] drm/fsl-dcu: detach panel on destroy
Disable the earlier attached panel on connector destroy.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index f586f1e..a07886f 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -79,7 +79,10 @@ int fsl_dcu_drm_encoder_create(struct fsl_dcu_drm_device
*fsl_dev,
static void fsl_dcu_drm_connector_destroy(struct drm_connector *connector)
{
+ struct fsl_dcu_drm_connector *fsl_con = to_fsl_dcu_connector(connector);
+
drm_connector_unregister(connector);
+ drm_panel_detach(fsl_con->panel);
drm_connector_cleanup(connector);
}
--
2.8.0
[PATCH 0/6] drm/fsl-dcu: unload fixes
Hi all, This patchset fixes several issues around unloading/unbinding the driver. There is still one WARNING when unloading the driver while vblank interrupts are enabled. I am not sure what/who should make sure that vblank interrupts get disabled before unloading the driver: root at colibri-vf:~# echo 40058000.dcu > /sys/bus/platform/drivers/fsl-dcu/unbind [ 37.209656] Console: switching to colour dummy device 80x30 [ 37.224954] [ cut here ] [ 37.245375] WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_irq.c:380 drm_vblank_cleanup+0x5c/0x8c ... Hints welcome... Stefan Agner (6): drm/fsl-dcu: detach panel on destroy drm/fsl-dcu: handle missing panel gracefully drm/fsl-dcu: use variable name dev for struct drm_device drm/fsl-dcu: deallocate fbdev CMA on unload drm/fsl-dcu: disable output polling on driver unload drm/fsl-dcu: implement lastclose callback drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 50 +-- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 23 +- 2 files changed, 50 insertions(+), 23 deletions(-) -- 2.8.0
[Bug 94973] R9 380X (Tonga) SMC failure with pcie_dpm_key_disabled=0
https://bugs.freedesktop.org/show_bug.cgi?id=94973 --- Comment #1 from Jay Cornwall --- Created attachment 123001 --> https://bugs.freedesktop.org/attachment.cgi?id=123001&action=edit R9 380X VBIOS -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160416/fcea8a3a/attachment-0001.html>
[Bug 94973] R9 380X (Tonga) SMC failure with pcie_dpm_key_disabled=0
https://bugs.freedesktop.org/show_bug.cgi?id=94973 Bug ID: 94973 Summary: R9 380X (Tonga) SMC failure with pcie_dpm_key_disabled=0 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: jay at jcornwall.me Created attachment 123000 --> https://bugs.freedesktop.org/attachment.cgi?id=123000&action=edit dmesg from drm-fixes-4.6 HW is R9 380X in primary PCIe 3 slot on ASUS P8B75-V with three monitors attached (2x DVI and 1 HDMI). First observed in 4.5 when Powerplay was enabled by default. Trace of SMC messages around failure from drm-fixes-4.6 kernel: [9.666775] tonga_send_msg_to_smc(..., 0x145) [9.666799] tonga_send_msg_to_smc(..., 0x146) [9.666875] tonga_send_msg_to_smc(..., 0x5E) [9.666895] tonga_send_msg_to_smc(..., 0x148) [9.667775] tonga_send_msg_to_smc(..., 0x145) [9.667800] tonga_send_msg_to_smc(..., 0x146) [9.774079] [drm] fb mappable at 0xE0BAA000 [9.774083] [drm] vram apper at 0xE000 [9.774085] [drm] size 9216000 [9.774087] [drm] fb depth is 24 [9.774089] [drm]pitch is 7680 [9.774213] fbcon: amdgpudrmfb (fb0) is primary device [9.774345] tonga_send_msg_to_smc(..., 0x5E) [9.943267] Failed to send Message. [ 10.112239] tonga_send_msg_to_smc(..., 0x145) Other Powerplay functionality works correctly with pcie_dpm_key_disabled=1. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160416/5cf27a07/attachment.html>
[Bug 94667] Artifacts on applications on discrete and kernel freezes
https://bugs.freedesktop.org/show_bug.cgi?id=94667 --- Comment #19 from Vladislav Kamenev --- On AMD Hainan (RadeonSI driver) Z-like tearing and past frames is also present. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160416/1b17aa51/attachment.html>
[Nouveau] [PATCH 1/2] nouveau/bl: Assign different names to interfaces
On 02:40 PM - Apr 15 2016, Nick Tenney wrote:
> On Fri, Apr 15, 2016 at 11:25 AM, Ilia Mirkin wrote:
>
> > On Fri, Apr 15, 2016 at 11:22 AM, Pierre Moreau
> > wrote:
> > > On 11:06 AM - Apr 15 2016, Ilia Mirkin wrote:
> > >> On Fri, Apr 15, 2016 at 10:57 AM, Pierre Moreau > >> free.fr>
> > wrote:
> > >> > Currently, every backlight interface created by Nouveau uses the same
> > name,
> > >> > nv_backlight. This leads to a sysfs warning as it tries to create an
> > already
> > >> > existing folder. This patch adds a incremented number to the name,
> > but keeps
> > >> > the initial name as nv_backlight, to avoid possibly breaking
> > userspace; the
> > >> > second interface will be named nv_backlight1, and so on.
> > >> >
> > >> > Fixes: fdo#86539
> >
> I believe Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86539 is
> the preferred format. I think this is picked up by the mesa release scripts
> or some such.
Ackâed. Iâll fix that in the v2.
Thanks!
Pierre
>
> > >> > Signed-off-by: Pierre Moreau
> > >> > ---
> > >> > drm/nouveau/nouveau_backlight.c | 35
> > +--
> > >> > 1 file changed, 33 insertions(+), 2 deletions(-)
> > >> >
> > >> > diff --git a/drm/nouveau/nouveau_backlight.c
> > b/drm/nouveau/nouveau_backlight.c
> > >> > index 89eb460..914e2cb 100644
> > >> > --- a/drm/nouveau/nouveau_backlight.c
> > >> > +++ b/drm/nouveau/nouveau_backlight.c
> > >> > @@ -36,6 +36,10 @@
> > >> > #include "nouveau_reg.h"
> > >> > #include "nouveau_encoder.h"
> > >> >
> > >> > +static atomic_t bl_interfaces_nb = { 0 };
> > >>
> > >> static data is initialized to 0, this should be unnecessary.
> > >
> > > I didnât know that. But on the other hand, I like having it explicit,
> > and it
> > > should not add any overhead.
> >
> > It increases the size of the object file. I believe it's kernel policy
> > to avoid static initializations to 0. (Note that this doesn't hold in
> > regular user applications, just the kernel.)
> >
> > -ilia
> > ___
> > Nouveau mailing list
> > Nouveau at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/nouveau
> >
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160416/ca9a9d2f/attachment.sig>
Allocation of frame buffer at a specific memory range or address
On Sat, Apr 16, 2016 at 2:07 AM, Vineet Gupta
wrote:
> On Friday 15 April 2016 09:18 PM, Alexey Brodkin wrote:
>
>> And now the question is how to force DRM subsystem or just that driver
>> to use whatever predefined (say via device tree) location in memory
>> for data buffer allocation.
>
> It seems this is pretty easy to do with DT reserved-memory binding.
>
> You need to partition memory into @memory and @reserved-memory.
> Later can be subdivided into more granular regions and your driver can refer
> to
> one of the regions.
jfyi, it might be useful to look at msm_init_vram() which has support
to wrap vram carveout as gem buffer, for exact same purpose..
BR,
-R
> Something like below (untested)
>
> + memory {
> + device_type = "memory";
> + reg = <0x0 0x8000 0x0 0xA000>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> + /* This memory bypasses IOC port */
> + fb_reserved at A000 {
> + reg = <0x0 0xA000 0x0 0xAF00>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> + /* no-map; */
> + };
> + };
> +
> +
> + fb0: video at 1230 {
> + memory-region = <&fb_reserved>;
> + /* ... */
> + };
>
> This might also need a DT helper in ARC mm init code.
>
> + early_init_fdt_scan_reserved_mem();
>
> HTH,
> -Vineet
[PATCH] drm: msm: remove unused variable
On Sat, Apr 16, 2016 at 4:41 PM, Arnd Bergmann wrote:
> A recent cleanup removed the only user of the 'kms' variable in
> msm_preclose(), causing a harmless compiler warning:
>
> drivers/gpu/drm/msm/msm_drv.c: In function 'msm_preclose':
> drivers/gpu/drm/msm/msm_drv.c:468:18: error: unused variable 'kms'
> [-Werror=unused-variable]
>
> This removes the variable as well.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 4016260ba47a ("drm/msm: fix bug after preclose removal")
thanks, I'll pull that in for 4.7.. danvet actually pointed that out
to me yesterday (a needed fix of a fix.. ;-))
BR,
-R
> ---
> drivers/gpu/drm/msm/msm_drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
> index c03b96709179..701c51ed3e7c 100644
> --- a/drivers/gpu/drm/msm/msm_drv.c
> +++ b/drivers/gpu/drm/msm/msm_drv.c
> @@ -465,7 +465,6 @@ static void msm_preclose(struct drm_device *dev, struct
> drm_file *file)
> {
> struct msm_drm_private *priv = dev->dev_private;
> struct msm_file_private *ctx = file->driver_priv;
> - struct msm_kms *kms = priv->kms;
>
> mutex_lock(&dev->struct_mutex);
> if (ctx == priv->lastctx)
> --
> 2.7.0
>
Allocation of frame buffer at a specific memory range or address
On Friday 15 April 2016 09:18 PM, Alexey Brodkin wrote:
> And now the question is how to force DRM subsystem or just that driver
> to use whatever predefined (say via device tree) location in memory
> for data buffer allocation.
It seems this is pretty easy to do with DT reserved-memory binding.
You need to partition memory into @memory and @reserved-memory.
Later can be subdivided into more granular regions and your driver can refer to
one of the regions.
Something like below (untested)
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x8000 0x0 0xA000>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ /* This memory bypasses IOC port */
+ fb_reserved at A000 {
+ reg = <0x0 0xA000 0x0 0xAF00>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ /* no-map; */
+ };
+ };
+
+
+ fb0: video at 1230 {
+ memory-region = <&fb_reserved>;
+ /* ... */
+ };
This might also need a DT helper in ARC mm init code.
+ early_init_fdt_scan_reserved_mem();
HTH,
-Vineet
making a COW mapping on the fly from existing vma
This was just a random thought process I was having last night, and wondered if it was possible. We have a scenario with OpenGL where certain APIs hand large amounts of data from the user to the API and when you return from the API call the user can then free/overwrite/do whatever they want with the data they gave you, which pretty much means you have to straight away process the data. Now there have been attempts at threading the GL API, but one thing they usually hit is they have to do a lot of unthreaded processing for these scenarios, so I was wondering could we do some COW magic with the data. More than likely the data will be anonymous mappings though maybe some filebacked, and my idea would be you'd in the main thread create a new readonly VMA from the old pages and set the original mapping to do COW on all of its pages. Then the thread would pick up the readonly VMA mapping and do whatever background processing it wants while the main thread continues happily on its way. I'm not sure if anyone who's done glthread has thought around this, or if the kernel APIs are in place to do something like this so I just thought I'd throw it out there. Dave.
[Bug 76490] Hang during boot when DPM is on (R9 270X)
https://bugs.freedesktop.org/show_bug.cgi?id=76490 --- Comment #106 from samdenies at zhentarim.net --- (In reply to Alex Deucher from comment #105) > Does this attached patch help? I was not able to apply the patch itself as it didn't match the source for 4.5.1 that I downloaded. However, adding the line manually did fix my problem. I am able to boot without radeon.dpm=0 and have good 3d performance. Thanks! -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160416/cff512c4/attachment.html>
