[Bug 91881] regression: GPU lockups since mesa-11.0.0_rc1 on RV620 (r600) driver

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91881

--- Comment #3 from markus gapp  ---
git bisect found commit 29aaab2b5f55cc6d9a84f58ce2bb8607e76a9dde as the
culprit. reverting it makes 11.0.0-rc2 work on my hw. for some reason it does
not like 
commit 29aaab2b5f55cc6d9a84f58ce2bb8607e76a9dde
Author: Grigori Goronzy 
Date:   Wed Jun 24 03:38:02 2015 +0200

winsys/radeon: align BO size to page size

This is the basic granularity for BO allocations. The alignment also
helps with BO reuse by the cached bufmgr.

This results in a huge 45% speedup in Metro 2033 Redux on my test
system. The game relies on buffer orphaning with very small buffers
(hundreds of bytes in size) and that did not work efficiently
before. This change may also affect other applications and games.

Reviewed-by: Marek Olšák 


thank you!! markus

-- 
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/20150905/8b9448a9/attachment.html>

[PATCH] drm/mst: update the link_address_sent before sending the link address

[Dave Airlie]

There is a race where the reply could get processed by another
work queue before we've updated the state.

Update the state before sending the msg to close it.

Pointed out by Adam J Richter on

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91481
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index e23df5f..18c2a74 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -1106,8 +1106,8 @@ static void drm_dp_add_port(struct drm_dp_mst_branch 
*mstb,

ret = drm_dp_port_setup_pdt(port);
if (ret == true) {
-   drm_dp_send_link_address(mstb->mgr, port->mstb);
port->mstb->link_address_sent = true;
+   drm_dp_send_link_address(mstb->mgr, port->mstb);
}
}

@@ -1203,8 +1203,8 @@ static void drm_dp_check_and_send_link_address(struct 
drm_dp_mst_topology_mgr *m
struct drm_dp_mst_port *port;
struct drm_dp_mst_branch *mstb_child;
if (!mstb->link_address_sent) {
-   drm_dp_send_link_address(mgr, mstb);
mstb->link_address_sent = true;
+   drm_dp_send_link_address(mgr, mstb);
}
list_for_each_entry(port, >ports, next) {
if (port->input)
-- 
2.4.3

[PATCH 6/9] drm: bridge/dw_hdmi: adjust pixel clock values in N calculation

[Russell King - ARM Linux]

On Sat, Sep 05, 2015 at 06:46:04AM -0700, Doug Anderson wrote:
> Russell,
> 
> On Sat, Sep 5, 2015 at 1:31 AM, Russell King - ARM Linux
>  wrote:
> > On Fri, Sep 04, 2015 at 07:03:11PM -0700, Doug Anderson wrote:
> >> AKA: just replace your entire "compute_n" function with:
> >>
> >> return (128 * freq) / 1000;
> >>
> >> ...and it's 100% simpler _and_ gets you a (marginally) better rate
> >> (assuming you really have 22.175000).  If it was just about a
> >> 32000.222 vs 32000 I'd not be saying anything right now.  It's about
> >> adding complexity.
> >
> > No.  It doesn't work for all cases.  Do the calculations for every
> > sample rate in those tables in the HDMI spec, and you'll find out
> > why.
> 
> If you know the answer, just tell me.  If you're talking about 74.25
> vs. 32 kHz it is further evidence of what I'm saying.  Note that
> picking only one of the two listed CTS values again puts you in a
> worse position for regenerating the proper audio clock then just using
> the default N=4096.

No it doesn't.

74.25MHz/1.001 * 4096 / (128 * 32000) = 74175 (rounded down)

Now do the calcuation.

(74.25MHz/1.001) / 74175 * 4096 = 4096045.511 => 32000.35556Hz
=> error of 0.00%

Now for the calcuation using the proscribed figures.

(74.25MHz/1.001) / 210937 * 11648 = 4096009.709 => 32000.07585Hz
=> error of 0.000237%

That's significantly less error using that than your "better" idea.
Now, if we take the pixel clock rate as 74.175MHz, which is just a
representation of 74.25MHz/1.001:

74.175MHz / 210937 * 11648 = 4095964.198 => 31999.72029Hz
=> error of 0.0008741%

That's still lower than your "better" idea.

And as I've already said, the pixel clock rate given to us here will
be the _specified_ clock rate of 74.175MHz, *not* some cocked up
platform screwed crap that you think we will.  It _will_ be 74175
not 74170 or some other shite like that.

Right, I've had enough.  I'm going to be ignoring this thread from now
on, this is a waste of my time - you clearly have no understanding of
what's going on here.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 09/15] vga_switcheroo: Sort headers alphabetically

[Lukas Wunner]

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/vga/vga_switcheroo.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index 6e0e705..578aa47 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -30,19 +30,17 @@

 #define pr_fmt(fmt) "vga_switcheroo: " fmt

-#include 
-#include 
-#include 
-#include 
+#include 
 #include 
 #include 
-
+#include 
+#include 
 #include 
-#include 
-#include 
 #include 
-
+#include 
+#include 
 #include 
+#include 

 /**
  * DOC: Overview
-- 
1.8.5.2 (Apple Git-48)

[PATCH 6/9] drm: bridge/dw_hdmi: adjust pixel clock values in N calculation

[Doug Anderson]

Hi,

On Sat, Sep 5, 2015 at 7:01 AM, Russell King - ARM Linux
 wrote:
>> If you know the answer, just tell me.  If you're talking about 74.25
>> vs. 32 kHz it is further evidence of what I'm saying.  Note that
>> picking only one of the two listed CTS values again puts you in a
>> worse position for regenerating the proper audio clock then just using
>> the default N=4096.
>
> No it doesn't.
>
> 74.25MHz/1.001 * 4096 / (128 * 32000) = 74175 (rounded down)
>
> Now do the calcuation.
>
> (74.25MHz/1.001) / 74175 * 4096 = 4096045.511 => 32000.35556Hz
> => error of 0.00%
>
> Now for the calcuation using the proscribed figures.
>
> (74.25MHz/1.001) / 210937 * 11648 = 4096009.709 => 32000.07585Hz
> => error of 0.000237%
>

Why would you round down???  Round to the closest.

(7425 / 1.001 * 4096)  / (128 * 32000.)
=> 74175.82417582418
=> 74176

(7425 / 1.001) / 74176 * 4096 / 128
=> 31999.924148327947

That's actually the same error as yours: 0.000237%

You're right.  Yours isn't worse, but it's also not any better.

[PATCH 15/15] drm: Spell vga_switcheroo consistently

[Lukas Wunner]

Currently everyone and their dog has their own favourite spelling
for vga_switcheroo. This makes it hard to grep dmesg for log entries
relating to vga_switcheroo. It also makes it hard to find related
source files in the tree.

vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.

Signed-off-by: Lukas Wunner 
---
 Documentation/DocBook/drm.tmpl | 2 +-
 drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
 include/linux/fb.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 9ddf8c6..30401f9 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3646,7 +3646,7 @@ void (*postclose) (struct drm_device *, struct drm_file 
*);
plane properties to default value, so that a subsequent open of the
device will not inherit state from the previous user. It can also be
used to execute delayed power switching state changes, e.g. in
-   conjunction with the vga-switcheroo infrastructure. Beyond that KMS
+   conjunction with the vga_switcheroo infrastructure. Beyond that KMS
drivers should not do any further cleanup. Only legacy UMS drivers might
need to clean up device state so that the vga console or an independent
fbdev driver could take over.
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c 
b/drivers/gpu/drm/omapdrm/omap_drv.c
index a5f9d8b..d685e23 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -753,7 +753,7 @@ static void dev_lastclose(struct drm_device *dev)
 {
int i;

-   /* we don't support vga-switcheroo.. so just make sure the fbdev
+   /* we don't support vga_switcheroo.. so just make sure the fbdev
 * mode is active
 */
struct omap_drm_private *priv = dev->dev_private;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 043f328..36da20a 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -156,7 +156,7 @@ struct fb_cursor_user {
 #define FB_EVENT_GET_REQ0x0D
 /*  Unbind from the console if possible */
 #define FB_EVENT_FB_UNBIND  0x0E
-/*  CONSOLE-SPECIFIC: remap all consoles to new fb - for vga switcheroo */
+/*  CONSOLE-SPECIFIC: remap all consoles to new fb - for vga_switcheroo */
 #define FB_EVENT_REMAP_ALL_CONSOLE  0x0F
 /*  A hardware display blank early change occured */
 #define FB_EARLY_EVENT_BLANK   0x10
-- 
1.8.5.2 (Apple Git-48)

[PATCH 14/15] drm/amdgpu: Spell vga_switcheroo consistently

[Lukas Wunner]

Currently everyone and their dog has their own favourite spelling
for vga_switcheroo. This makes it hard to grep dmesg for log entries
relating to vga_switcheroo. It also makes it hard to find related
source files in the tree.

vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c   | 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
index 3f7aaa4..1a6b239 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c
@@ -536,7 +536,7 @@ static bool amdgpu_atpx_detect(void)

if (has_atpx && vga_count == 2) {
acpi_get_name(amdgpu_atpx_priv.atpx.handle, ACPI_FULL_PATHNAME, 
);
-   printk(KERN_INFO "VGA switcheroo: detected switching method %s 
handle\n",
+   printk(KERN_INFO "vga_switcheroo: detected switching method %s 
handle\n",
   acpi_method_name);
amdgpu_atpx_priv.atpx_detected = true;
return true;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 6ff6ae9..b1a08d9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1021,7 +1021,7 @@ static void amdgpu_check_arguments(struct amdgpu_device 
*adev)
  * amdgpu_switcheroo_set_state - set switcheroo state
  *
  * @pdev: pci dev pointer
- * @state: vga switcheroo state
+ * @state: vga_switcheroo state
  *
  * Callback for the switcheroo driver.  Suspends or resumes the
  * the asics before or after it is powered up using ACPI methods.
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 2236793..a60eb4b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -488,7 +488,7 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
  *
  * @dev: drm dev pointer
  *
- * Switch vga switcheroo state after last close (all asics).
+ * Switch vga_switcheroo state after last close (all asics).
  */
 void amdgpu_driver_lastclose_kms(struct drm_device *dev)
 {
-- 
1.8.5.2 (Apple Git-48)

[PATCH 13/15] drm/radeon: Spell vga_switcheroo consistently

[Lukas Wunner]

Currently everyone and their dog has their own favourite spelling
for vga_switcheroo. This makes it hard to grep dmesg for log entries
relating to vga_switcheroo. It also makes it hard to find related
source files in the tree.

vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/radeon/radeon_atpx_handler.c | 2 +-
 drivers/gpu/drm/radeon/radeon_device.c   | 2 +-
 drivers/gpu/drm/radeon/radeon_kms.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c 
b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
index 8bc7d0b..a771b9f 100644
--- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
+++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
@@ -535,7 +535,7 @@ static bool radeon_atpx_detect(void)

if (has_atpx && vga_count == 2) {
acpi_get_name(radeon_atpx_priv.atpx.handle, ACPI_FULL_PATHNAME, 
);
-   printk(KERN_INFO "VGA switcheroo: detected switching method %s 
handle\n",
+   printk(KERN_INFO "vga_switcheroo: detected switching method %s 
handle\n",
   acpi_method_name);
radeon_atpx_priv.atpx_detected = true;
return true;
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index d8319da..38d730c 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1197,7 +1197,7 @@ static void radeon_check_arguments(struct radeon_device 
*rdev)
  * radeon_switcheroo_set_state - set switcheroo state
  *
  * @pdev: pci dev pointer
- * @state: vga switcheroo state
+ * @state: vga_switcheroo state
  *
  * Callback for the switcheroo driver.  Suspends or resumes the
  * the asics before or after it is powered up using ACPI methods.
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index 4a119c2..021abcc 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -602,7 +602,7 @@ static int radeon_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
  *
  * @dev: drm dev pointer
  *
- * Switch vga switcheroo state after last close (all asics).
+ * Switch vga_switcheroo state after last close (all asics).
  */
 void radeon_driver_lastclose_kms(struct drm_device *dev)
 {
-- 
1.8.5.2 (Apple Git-48)

[PATCH 12/15] drm/nouveau: Spell vga_switcheroo consistently

[Lukas Wunner]

Currently everyone and their dog has their own favourite spelling
for vga_switcheroo. This makes it hard to grep dmesg for log entries
relating to vga_switcheroo. It also makes it hard to find related
source files in the tree.

vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.

Signed-off-by: Lukas Wunner 
---
 drivers/gpu/drm/nouveau/nouveau_acpi.c | 4 ++--
 drivers/gpu/drm/nouveau/nouveau_vga.c  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index df2d981..af20dd2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -289,14 +289,14 @@ static bool nouveau_dsm_detect(void)
if (has_optimus == 1) {
acpi_get_name(nouveau_dsm_priv.dhandle, ACPI_FULL_PATHNAME,
);
-   printk(KERN_INFO "VGA switcheroo: detected Optimus DSM method 
%s handle\n",
+   printk(KERN_INFO "vga_switcheroo: detected Optimus DSM method 
%s handle\n",
acpi_method_name);
nouveau_dsm_priv.optimus_detected = true;
ret = true;
} else if (vga_count == 2 && has_dsm && guid_valid) {
acpi_get_name(nouveau_dsm_priv.dhandle, ACPI_FULL_PATHNAME,
);
-   printk(KERN_INFO "VGA switcheroo: detected DSM switching method 
%s handle\n",
+   printk(KERN_INFO "vga_switcheroo: detected DSM switching method 
%s handle\n",
acpi_method_name);
nouveau_dsm_priv.dsm_detected = true;
ret = true;
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c 
b/drivers/gpu/drm/nouveau/nouveau_vga.c
index af89c36..0cda8e1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -41,13 +41,13 @@ nouveau_switcheroo_set_state(struct pci_dev *pdev,
return;

if (state == VGA_SWITCHEROO_ON) {
-   printk(KERN_ERR "VGA switcheroo: switched nouveau on\n");
+   printk(KERN_ERR "vga_switcheroo: switched nouveau on\n");
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
nouveau_pmops_resume(>dev);
drm_kms_helper_poll_enable(dev);
dev->switch_power_state = DRM_SWITCH_POWER_ON;
} else {
-   printk(KERN_ERR "VGA switcheroo: switched nouveau off\n");
+   printk(KERN_ERR "vga_switcheroo: switched nouveau off\n");
dev->switch_power_state = DRM_SWITCH_POWER_CHANGING;
drm_kms_helper_poll_disable(dev);
nouveau_switcheroo_optimus_dsm();
-- 
1.8.5.2 (Apple Git-48)

[PATCH 6/9] drm: bridge/dw_hdmi: adjust pixel clock values in N calculation

[Russell King - ARM Linux]

On Fri, Sep 04, 2015 at 07:03:11PM -0700, Doug Anderson wrote:
> Then perhaps you shouldn't be using a switch statement.  You won't
> catch all values that are within .05% of (25.2 / 1.001).

No.

The clock rates you get ultimately come from the EDID via either the
detailed timing modes or from the CEA mode IDs, which are then looked
up in tables in the DRM EDID parsing code.

Either way, you will end up with 25175 and not 25170 or something
strange based on what the platform does.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 6/9] drm: bridge/dw_hdmi: adjust pixel clock values in N calculation

[Russell King - ARM Linux]

On Fri, Sep 04, 2015 at 07:03:11PM -0700, Doug Anderson wrote:
> AKA: just replace your entire "compute_n" function with:
> 
> return (128 * freq) / 1000;
> 
> ...and it's 100% simpler _and_ gets you a (marginally) better rate
> (assuming you really have 22.175000).  If it was just about a
> 32000.222 vs 32000 I'd not be saying anything right now.  It's about
> adding complexity.

No.  It doesn't work for all cases.  Do the calculations for every
sample rate in those tables in the HDMI spec, and you'll find out
why.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[Bug 91481] [Patch?] DisplayPort MST (Multistream Transport) hotplug kernel memory fault

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91481

--- Comment #2 from Dave Airlie  ---
I've missed this bug, but I've posted a patch that is like yours just not as
large a change.

Hopefully it works for you.

-- 
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/20150905/18a5c79e/attachment.html>

[PATCH 6/9] drm: bridge/dw_hdmi: adjust pixel clock values in N calculation

[Doug Anderson]

Russell,

On Sat, Sep 5, 2015 at 1:34 AM, Russell King - ARM Linux
 wrote:
> On Fri, Sep 04, 2015 at 07:03:11PM -0700, Doug Anderson wrote:
>> Then perhaps you shouldn't be using a switch statement.  You won't
>> catch all values that are within .05% of (25.2 / 1.001).
>
> No.
>
> The clock rates you get ultimately come from the EDID via either the
> detailed timing modes or from the CEA mode IDs, which are then looked
> up in tables in the DRM EDID parsing code.

I guess in my case the (non-upsteram) code is adjusting the clock in
fixup_mode.  It's no longer something based on the EDID.  Perhaps the
fault if there, but...


> Either way, you will end up with 25175 and not 25170 or something
> strange based on what the platform does.

I was talking to someone else about this and I guess the question is
whether you should be sending a N/CTS for audio based on the
theoretical or the actual clock.

If you are supposed to do calculations based on the theoretical clock
then you're right.  If you are supposed to do calculations based on
the actual clock then I'm not so sure.

Note that:
* I believe that you'll get better audio if you use the actual clock.

* If your actual clock is an integral number of kHz, the calculations
are simpler by using the actual clock.


-Doug

[PATCH 6/9] drm: bridge/dw_hdmi: adjust pixel clock values in N calculation

[Doug Anderson]

Russell,

On Sat, Sep 5, 2015 at 1:31 AM, Russell King - ARM Linux
 wrote:
> On Fri, Sep 04, 2015 at 07:03:11PM -0700, Doug Anderson wrote:
>> AKA: just replace your entire "compute_n" function with:
>>
>> return (128 * freq) / 1000;
>>
>> ...and it's 100% simpler _and_ gets you a (marginally) better rate
>> (assuming you really have 22.175000).  If it was just about a
>> 32000.222 vs 32000 I'd not be saying anything right now.  It's about
>> adding complexity.
>
> No.  It doesn't work for all cases.  Do the calculations for every
> sample rate in those tables in the HDMI spec, and you'll find out
> why.

If you know the answer, just tell me.  If you're talking about 74.25
vs. 32 kHz it is further evidence of what I'm saying.  Note that
picking only one of the two listed CTS values again puts you in a
worse position for regenerating the proper audio clock then just using
the default N=4096.

-Doug

[Bug 91481] [Patch?] DisplayPort MST (Multistream Transport) hotplug kernel memory fault

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91481

--- Comment #1 from Adam J. Richter  ---
Thank you, Dave Arlie, and anyone else involved, for the DisplayPort
MultiStream Transport fixes in Linux 4.1.6 and 4.2 (and a few of the
subreleases and release candidates leading up to these versions).

However, I think that some change along the lines of the patch that I mentioned
may still be necessary.  I cannot be sure, because when I try to boot
linux-4.1.6, I get a other kernels bugs either before I get a chance to test
this or while I am testing it.  I am pretty sure I tried Linux-4.2 and observed
the kernel getting fault that would go away when I would apply the attached
patch.

It looks to me like, toward the end of drm_dp_add_port in Linux-4.2, I still
see the following code:

   drm_dp_send_link_address(mstb->mgr, port->mstb);
   port->mstb->link_address_sent = true;

...and drm_dp_send_link_address has this line, which I think can call a
function that can change port->mstb:

   (*mgr->cbs->hotplug)(mgr);

-- 
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/20150905/0e8a4a10/attachment.html>

[PATCH 6/9] drm: bridge/dw_hdmi: adjust pixel clock values in N calculation

[Russell King - ARM Linux]

On Fri, Sep 04, 2015 at 04:50:03PM -0700, Doug Anderson wrote:
> Russell,
> 
> On Fri, Sep 4, 2015 at 2:24 PM, Russell King - ARM Linux
>  wrote:
> >> In your case you're probably making the value that Linux
> >> asked you to make, AKA 25.175000 MHz.
> >
> > ... which is the spec value.
> 
> This is where we're not on the same page.  Where in the spec does it
> say 25.17500 MHz?  I see in the spec:
>  25.2 / 1.001

Section 4 of CEA-861-B, which defines the video clock rates and their
accuracy of 0.5%.

> ...and this is a crucial difference here.  Please double-check my math, but:
> 
> (25175000 * 4576) / (128 * 32000.)
> => 28125.1953125
> 
> (25174825 * 4576) / (128 * 32000.)
> => 28125.0
> 
> This calculation is what led to my belief that the goal here is to
> make an integral CTS.  If you have 25.175 MHZ clock and N of 4576 you
> _will not_ have an integral CTS.  If you instead have 25.174825 MHz
> clock and N of 4576 you _will_ have an integral CTS.

Right, but 25.175 is close enough to 25.174825.  Do this calculation:

25175000 * 4576 / 28125 / 128

That'll give you the resulting audio sample rate, which is 32000.222Hz.
That's an error of... 0.00069%, which is probably around the typical
error of your average crystal oscillator.  Really not worth bothering
with.

> Said another way:
> 
> 1. The reason 25174825 Hz has a different N is to make an integral CTS.
> 
> 2. If you are indeed making 25175000 then there is no need for a
> different N to make an integral CTS
> 
> 3. If you use 4576 for N but you're making 25175000 Hz, you end up in
> a _worse_ position than if you use the standard 4096 for N.

Total rubbish.  Sorry, but it is.

Follow the code.  Pixel clock is 25175000.  For 32kHz, N will be 4576.
25175000 * 4576 = 1.152008e11.  Divide that by the audio clock rate
(128 * 32000) gives 28125.19531.  Since we're using integer division,
that gets rounded down to 28125.

DRM uses a clock rate of "25175" to represent 25.2/1.001 modes.  So,
if your hardware sets a video clock rate of 25.2MHz/1.001, then you
end up with a sample rate of exactly 32kHz.  If you set exactly
25.175MHz, you end up with an approximate 32kHz sample rate - one
which is 0.00069% in error, which is (excluse the language) fuck all
different from exactly 32kHz.

Are you _really_ going to continue arguing over a 0.00069% error?
If you are, I'm not going to listen anymore - it's soo damned small
that it's not worth bothering with.  At all.

The only time that you'd need to worry about it is if you wanted a
super-accurate system, and for that you'd need an atomic clock to
source your system clocks to reduce aging effects, temperature
induced drift, etc, maybe locking the atomic clock to a national
frequency standard like the Anthorn MSF 60kHz transmitter signal
broadcast by the UK National Physics Laboratory.

> >> As a first step I'd suggest just removing all the special cases and
> >> add a comment.  From real world testing it doesn't seem terribly
> >> critical to be slightly off on CTS.  ...and in any case for any clock
> >> rates except the small handful in the HDMI spec we'll be slightly off
> >> on CTS anyway...
> >
> > They're not "special cases" made up to fit something - they're from the
> > tables in the HDMI specification.
> 
> They are definitely "special cases".  There is a general rule in the
> code you posted (aim for 128 * freq) and these are cases for certain
> clocks that are an exception to the general rule.  AKA they are
> special cases.

Sorry, I disagree with you.

> > That assumes that the audio and video clocks are coherent.  On iMX6
> > hardware using this, the audio is clocked at the rate defined by the
> > TDMS clock and the CTS/N values.
> 
> I'll admit I haven't looked at the audio section of dw_hdmi much, but
> I'd imagine that for all users of this controller / PHY the audio and
> video clocks are coherent.

Not if the audio clock comes from an I2S master rather than being
sourced from the HDMI block.

> I think in the perfect world we'd be able to generate exactly
> 25174825.174825177 Hz and we'd use all the rates from the HDMI spec.

To generate something of that accuracy, you'd need something like a
caesium fountain atomic clock.

> and we'd get spot on 32 kHz audio.  ...but I'm simply saying that
> we're not in that perfect world yet.
> 
> Also note that there are many many rates not in the HDMI spec that
> could benefit from similar optimization of trying to adjust N to make
> an integral CTS.

Now go and look at the HDMI spec, where it gives the CTS value for
74.25/1.001 for 32kHz.  That can't be represented by an integer CTS
value, so using this hardware, we can't generate that sample rate
without an error.  We'd use a fixed CTS value of 210937 instead, which
works out at a 0.00024% error.  Again, not worth worrying about.


> 
> ---
> 
> As a side note: I realized one part of the HDMI spec that isn't trying
> to make an integral value but still uses a different value for N: 297
> MHz.  From the 

[git pull] drm for 4.3

[Dave Airlie]

Hi Linus,

This is the main pull request for the drm for 4.3. Nouveau is probably the 
biggest
amount of changes in here, since it missed 4.2. Highlights below, along with 
the usual
bunch of fixes. There are a few minor conflicts with your tree but nothing 
you can't handle. All stuff outside drm should have applicable acks.

Highlights:

new drivers:
freescale dcu kms driver

core:
more atomic fixes
disable some dri1 interfaces on kms drivers
drop fb panic handling, this was just getting more broken, as more 
locking was required.
new core fbdev Kconfig support - instead of each driver 
enable/disabling it
struct_mutex cleanups

panel:
more new panels
cleanup Kconfig

i915:
Skylake support enabled by default
legacy modesetting using atomic infrastructure
Skylake fixes
GEN9 workarounds

amdgpu:
Fiji support
CGS support for amdgpu
Initial GPU scheduler - off by default
Lots of bug fixes and optimisations.

radeon:
DP fixes
misc fixes

amdkfd:
Add Carrizo support for amdkfd using amdgpu.

nouveau:
long pending cleanup to complete driver,
fully bisectable which makes it larger,
perfmon work
more reclocking improvements
maxwell displayport fixes

vmwgfx:
new DX device support, supports OpenGL 3.3
screen targets support

mgag200:
G200eW support
G200e new revision support

msm:
dragonboard 410c support, msm8x94 support, msm8x74v1 support
yuv format support
dma plane support
mdp5 rotation
initial hdcp

sti:
atomic support

exynos:
lots of cleanups
atomic modesetting/pageflipping support
render node support

tegra:
tegra210 support (dc, dsi, dp/hdmi)
dpms with atomic modesetting support

atmel:
support for 3 more atmel SoCs
new input formats, PRIME support.

dwhdmi:
preparing to add audio support

rockchip:
yuv plane support

Dave.

The following changes since commit c13dcf9f2d6f5f06ef1bf79ec456df614c5e058b:

  Linux 4.2-rc8 (2015-08-23 20:52:59 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-next

for you to fetch changes up to 73bf1b7be7aab60d7c651402441dd0b0b4991098:

  Merge branch 'drm-next-4.3' of git://people.freedesktop.org/~agd5f/linux into 
drm-next (2015-09-05 07:46:09 +1000)


Abdiel Janulgue (4):
  drm/i915: Enable resource streamer bits on MI_BATCH_BUFFER_START
  drm/i915: Enable Resource Streamer state save/restore on MI_SET_CONTEXT
  drm/i915: Enable resource streamer on Execlists
  drm/i915: Expose I915_EXEC_RESOURCE_STREAMER flag and getparam

Akash Goel (6):
  drm/i915/skl: Retrieve the Rpe value from Pcode
  drm/i915/skl: Ring frequency table programming changes
  drm/i915/skl: Updated the i915_ring_freq_table debugfs function
  drm/i915/skl: Restrict the ring frequency table programming to SKL
  drm/i915: Add HAS_CORE_RING_FREQ macro
  drm/i915: Added BXT check in HAS_CORE_RING_FREQ macro

Alex Dai (1):
  drm/i915: Add GuC-related module parameters

Alex Deucher (23):
  drm/radeon/dce6: assign different audio pins to each encoder
  drm/amdgpu: Implement irq interfaces for CGS
  drm/amdgpu: cleanup context structure v2
  drm/amdgpu: add fence suspend/resume functions
  drm/amdgpu: move some atombios definitions to common folder (v2)
  drm/amdgpu: handle conditional support for CIK properly
  drm/amdgpu: add support for VCE 3.x on Fiji
  drm/amdgpu: remove VM workaround for Fiji
  drm/amdgpu: add scheduler initialization
  drm/amdgpu: disable GPU reset by default
  drm/amdgpu: Don't link train DisplayPort on HPD until we get the dpcd
  drm/amdgpu: fix IH ring allocation for bus addresses (v2)
  drm/radeon: fix HDMI quantization_range for pre-DCE5 asics
  drm/radeon/native: Send out the full AUX address
  drm/amdgpu/atom: Send out the full AUX address
  drm/amdgpu: be explicit about cpu vram access for driver BOs (v2)
  drm/amdgpu: use top down allocation for non-CPU accessible vram
  drm/amdgpu: fix typo in dce10 watermark setup
  drm/amdgpu: fix typo in dce11 watermark setup
  drm/amdgpu/cz: fix cz_dpm_update_low_memory_pstate logic
  drm/amdgpu: fix warning in scheduler
  drm/amdgpu: fix vce3 instance handling
  drm/amdgpu: rename gmc_v8_0_init_compute_vmid

Alexandre Courbot (6):
  drm/nouveau/gr: use NVIDIA-provided external firmwares
  drm/nouveau/gr/gk20a: use same initialization sequence as nvgpu
  drm/nouveau/fifo: add GM20B fifo
  drm/nouveau/gr: add GM20B support
  drm/nouveau/device: recognize GM20B
  drm/nouveau/platform: recognize GM20B

Ander Conselvan de Oliveira (7):
   

[PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir

[Heiko Stuebner]

Am Freitag, 4. September 2015, 16:06:02 schrieb Rob Herring:
> On Tue, Sep 1, 2015 at 3:46 PM, Heiko Stuebner  wrote:
> > Am Dienstag, 1. September 2015, 13:49:58 schrieb Yakir Yang:
> >> Split the dp core driver from exynos directory to bridge
> >> directory, and rename the core driver to analogix_dp_*,
> >> leave the platform code to analogix_dp-exynos.
> >> 
> >> Signed-off-by: Yakir Yang 
> > 
> > [...]
> > 
> >> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c
> >> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c similarity index 50%
> >> rename from drivers/gpu/drm/exynos/exynos_dp_core.c
> >> rename to drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> >> index bed0252..7d62f22 100644
> >> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> >> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > 
> > [...]
> > 
> >>   connector->polled = DRM_CONNECTOR_POLL_HPD;
> >>   
> >>   ret = drm_connector_init(dp->drm_dev, connector,
> >> 
> >> -  _dp_connector_funcs,
> >> +  _dp_connector_funcs,
> >> 
> >>DRM_MODE_CONNECTOR_eDP);
> >>   
> >>   if (ret) {
> >>   
> >>   DRM_ERROR("Failed to initialize connector with drm\n");
> >>   return ret;
> >>   
> >>   }
> >> 
> >> - drm_connector_helper_add(connector,
> >> _dp_connector_helper_funcs); +
> >> drm_connector_helper_add(connector,
> >> +  _dp_connector_helper_funcs);
> >> 
> >>   drm_connector_register(connector);
> > 
> > this should only run on exynos, as we're doing all our connector
> > registration in the core driver after all components are bound, so I
> > guess something like> 
> > the following is needed:
> >if (dp->plat_data && dp->plat_data->dev_type == EXYNOS_DP)
> >
> >drm_connector_register(connector);
> 
> Yuck!
> 
> Surely there is a better way. From what I've seen of DRM, I have no
> doubt this is needed, but really a better solution is needed. Surely
> there can be a more generic way for the driver to determine if it
> should handle the connector or not. This seems like a common problem
> including one I have seen. What I'm working on has onchip DSI encoder
> -> ADV7533 -> HDMI. The DSI encoder can also have a direct attached
> panel. So I have to check for a bridge in the encoder driver and only
> register the connector for the panel if a bridge is not attached.

I'm also only a part-time drm meddler, so things may be inaccurate.

This conditional is not meant to prevent the registration of the dp connector, 
only delay it for non-exynos drms. The connector registration does publish it 
to userspace, so like i.MX we're doing that for all connectors at the same 
time after all components are bound - to also make x11 happy. Exynos on the 
other hand seems to register its connectors individually and I'm not sure if 
they would be willing to change that.

see d3007dabeff4 ("drm/rockchip: register all connectors after bind") or 
simply rockchip_drm_drv.c line 178.

and e355e7dd607b ("imx-drm: delay publishing sysfs connector entries")


Heiko