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

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 i

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

--- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150905/0e8a4a10/attachment.html>

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

or the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150905/18a5c79e/attachment.html>

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

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/gp

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

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.

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

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

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

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) bett

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

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 y

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

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 *

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

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 fo

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

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 09/15] vga_switcheroo: Sort headers alphabetically

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/driver

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

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. Si

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

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. Si

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

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. Si

[PATCH 15/15] drm: Spell vga_switcheroo consistently

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. Si