[PATCH] drm/sti:fix spelling mistake: "compoment" -> "component"

2017-05-13 Thread Colin King 
From: Colin Ian King 

Trivial fix to spelling mistake in DRM_ERROR message

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/sti/sti_compositor.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sti/sti_compositor.c 
b/drivers/gpu/drm/sti/sti_compositor.c
index 11d4e885893a..6e4bf68262db 100644
--- a/drivers/gpu/drm/sti/sti_compositor.c
+++ b/drivers/gpu/drm/sti/sti_compositor.c
@@ -129,7 +129,7 @@ static int sti_compositor_bind(struct device *dev,
}
break;
default:
-   DRM_ERROR("Unknown subdev compoment type\n");
+   DRM_ERROR("Unknown subdev component type\n");
return 1;
}
 
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100964] RX-480 [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 0 test failed (scratch(0xC040)=0xCAFEDEAD)

2017-05-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100964

--- Comment #5 from HV  ---
I tested a Seasonic 750W PSU with the RX480 but i got the same error on boot
(amdgpu not loading, the rest of the system boots normally and i still get
display output with nomodeset on).

Is there anything else i can test for this issue?.

Regards

HV

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101011] Shadow of Mordor crashes with mesa from 08.05.2017.

2017-05-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=101011

Gilles  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from Gilles  ---
>From my testing, this has been fixed with the latest update from padoka ppa:
17.2~git170512235200.752a638~
The game launch properly now and I can pass a performance test without issue.

Thanks to whoever fixed it :)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Notifications about ACPI events in userspace?

2017-05-13 Thread Lukas Wunner 
[cc += dri-devel]

On Fri, May 12, 2017 at 01:05:21PM +0200, Florian Echtler wrote:
> On 12.05.2017 12:06, Lukas Wunner wrote:
> > On Fri, May 12, 2017 at 10:37:47AM +0200, Florian Echtler wrote:
> >> I'm currently adding support for the iMac's target display mode (TDM) to
> >> Linux.
> >> However, I'm not seeing anything happening with either acpi_listen or
> >> kacpimon.
> >> Does this require any kernel changes, or could I subscribe to these
> >> events somehow?
> > 
> > You can subscribe to these events by calling acpi_install_notify_handler().
> > See drivers/platform/x86/apple-gmux.c for an example.  That's a driver for
> > APP000B, a custom chip found on dual-GPU MacBook Pros dubbed GMUX which is
> > responsible for multiplexing the panel between the GPUs.
> 
> OK, but this has to happen in a kernel context, correct? No way to see these
> from userspace?

So to sum it up, the built-in panel on the iMac can be driven by a
separate machine and we can switch between the two sources via the SMC.

Essentially this is the same setup as on dual GPU MacBook Pros which
(unlike muxless solutions such as Nvidia Optimus) can fully switch the
panel between GPUs.

I believe we don't have a proper abstraction yet in the DRM subsystem
to control a display which can be driven by multiple sources.  All we
have is the somewhat kludgy vga_switcheroo interface:  It allows manual
switching by writing commands to /sys/kernel/debug/vgaswitcheroo/switch
(see https://www.kernel.org/doc/html/latest/gpu/vga-switcheroo.html
and drivers/gpu/vga/vga_switcheroo.c).

I guess you could register a vga_switcheroo handler which controls
switching via the SMC.  You'd also have to register a vga_switcheroo
client whenever you detect hotplug of an external source (and unregister
on unplug).  The client is normally a DRM driver but would in this case
just be a pseudo device.

Then you could switch back and forth via the vga_switcheroo interface.

As to your question, yes, acpi_install_notify_handler() is called from
kernel space and you could pass through the event to user space e.g.
via udev.  Then the desktop environment could display an icon that an
additional source is present.

On macOS I can't find the "dppt" string in any kernel extension, but
it's present in this user space component:
/System/Library/LoginPlugins/BezelServices.loginPlugin/Contents/MacOS/BezelServices

Disassembling it reveals that it talks to a special Mach port to switch
the display but it's not listening to the Notify() events.  Perhaps this
is only used with BootCamp?

In any case the other end of the Mach port seems to be /usr/libexec/dpd.


> > I'm not sure what APP000C is, could be a similar custom controller, I'd
> > have to do some research first to know what it does.  Surely "DP" stands
> > for DisplayPort, but what does "PT" stand for?
> 
> I'm guessing DPPT is for "DisPlayPorT".

More like DisplayPort Pass-Through.


> As far as I could tell, it's just a stub
> for receiving the Notify() calls; the actual source switching is handled by
> writing to SMC keys.

Yes, the Notify() calls are used to generate some kind of interrupt,
perhaps one for hotplug and the other one for unplug?


> > Perhaps apple-gmux.c could serve as a template for an APP000C driver.
> > The code should be easy to understand, if you have questions just ask away.
> 
> Since I need to modify the applesmc.c driver anyway, it would probably make
> sense to integrate the notify handler there?

Sounds reasonable to me.

Which iMac model are you developing this on exactly, a 2009/2010 model
(without Thunderbolt) or a newer one?  The newer ones can only be driven
via DP-over-Thunderbolt tunnels, so the HPD pin is coming from the
Thunderbolt controller, not the socket.  We don't have support for
setting up DP-over-Thunderbolt tunnels in thunderbolt.ko yet, only
PCIe-over-Thunderbolt is supported.  If the external source is already
present on boot, the tunnel may be established by the Thunderbolt EFI
driver but will be gone after unplug.

Thanks,

Lukas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 23/28] drm: omapdrm: Merge the dss_features and omap_dss_features structures

2017-05-13 Thread Laurent Pinchart 
Hi Tomi,

On Wednesday 10 May 2017 10:43:07 Tomi Valkeinen wrote:
> On 10/05/17 01:09, Laurent Pinchart wrote:
> > On Tuesday 09 May 2017 15:02:36 Tomi Valkeinen wrote:
> >> On 08/05/17 14:32, Laurent Pinchart wrote:
> >>> Both structures describe features of a particular OMAP DSS version,
> >>> there's no reason to keep them separate. Merge them together, allowing
> >>> initialization of the features based on the DSS compatible string
> >>> instead of the OMAP SoC version.
> >> 
> >> I don't think this is the correct way. As I mentioned earlier,
> >> dss_features should go. We should work on moving the parts from
> >> dss_features to each individual driver. I think there are probably only
> >> a very few dss-features that need to be accessed by multiple files, and
> >> those features could have a function of their own to query them.
> > 
> > I don't disagree with that, but can't we do so on top of this series ? I
> > don't think that these patches make the situation worse.
> > 
> >> But that may also be a bit bigger work, so... I thought about it already
> >> earlier in this series: wouldn't it be easier to first reconstruct the
> >> current OMAPDSS_VER_* with soc_device_match(), at module init time,
> >> which would allow us to keep most of the omapdss side unchanged. Then
> >> continue removing the arch/arm/ stuff.
> > 
> > I considered that to start with, but decided it was really a hack. I
> > instead
>
> Is it? You already use the dss compat string and soc_device_match to
> figure out some versions. Isn't that a proper way to find out about the
> SoC? But I agree that a more fine grained version management in each
> individual driver would be better.

For OMAP2, OMAP4 or OMAP5 it shouldn't be too much of a problem, but OMAP3 
would be more painful to handle. The following machine names are used.

"AM3505"
"AM3517"
"AM437x"
"OMAP3430/3530"
"OMAP3525"
"OMAP3515"
"OMAP3503"
"OMAP3611"
"OMAP3615/AM3715"
"OMAP3621"
"OMAP3630/DM3730"
"AM3703"
"DM3725"

> > went for cleaning things up where possible, and keeping hacks where a
> > proper rework would require a set of new patch series. The result is a
> > balance between a few hacks and lots of cleanup patches, which I
> > considered was right when I realized that the series was already 28
> > patches long.
> 
> Well, my concern is that these patches change a lot of things, moving
> stuff from here to there. And I think they would be moved or changed
> again later. So lots of room for conflicts and errors.
> 
> For example, in this patch you move things from dss.c to dss_features.c,
> but I think the dss.c is the right place for them (at least most of
> them), so we'd just end up moving them back. And if instead we'd move
> things from dss_features.c to dss.c, well, many of the things don't
> belong to dss.c and would be moved again later.

I agree with that. I've been working on patches to deconstruct dss_features 
and move all features to the right place. I've achieved a v1 that I still need 
to cleanup a bit.

> Then the HDMI PLL/PHY changes, well, as I mentioned, I don't fully agree
> with those.

I'll reply to that mail separately.

> So, while I think recreating the omapdss version in the dss driver would
> clearly be a temporary measure, still afaics it would be not that many
> lines of code and in just one place, and would allow us to easily move
> on to remove the extra platform devices and dependencies to arch/arm/.
> 
> After that we could start cleaning up the version handling inside the
> driver.
> 
> It is just the omapdss version and the dsi pinmuxing we get from the
> platform data, so getting rid of just those two should allow removal of
> the platform device. So, correct me if I'm wrong, but all the hdmi, dss
> "model" and dss_feature changes could as well be done in a separate
> series later.

But I don't think that removing the extra platform devices is so urgent. I'd 
rather do it when we're ready.

The omapdss driver needs major cleanup and refactoring, and that will result 
in a large number of patches that will cause conflicts and be sources of 
potential errors. I don't think that's avoidable. However, lots of those 
cleanups will be independent from each other, so we can start merging the less 
controversial ones as soon as they're ready. I'll take care of rebasing the 
rest of the patches as needed.

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/dp: Wait up all outstanding tx waiters

2017-05-13 Thread Chris Wilson 
subject s/Wait/Wake/

D'oh
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] drm/dp: Read the tx msg state once after checking for an event

2017-05-13 Thread Chris Wilson 
Both as an exercise to document that we are reading the state outside of
the appropriate mutex and to ensure that we only read the value once
before the multiple comparisons, use READ_ONCE.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index d1cbb9c8f806..3bdd314f02b1 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -737,16 +737,16 @@ static void drm_dp_mst_put_payload_id(struct 
drm_dp_mst_topology_mgr *mgr,
 static bool check_txmsg_state(struct drm_dp_mst_topology_mgr *mgr,
  struct drm_dp_sideband_msg_tx *txmsg)
 {
-   bool ret;
+   unsigned int state;
 
/*
 * All updates to txmsg->state are protected by mgr->qlock, and the two
 * cases we check here are terminal states. For those the barriers
 * provided by the wake_up/wait_event pair are enough.
 */
-   ret = (txmsg->state == DRM_DP_SIDEBAND_TX_RX ||
-  txmsg->state == DRM_DP_SIDEBAND_TX_TIMEOUT);
-   return ret;
+   state = READ_ONCE(txmsg->state);
+   return (state == DRM_DP_SIDEBAND_TX_RX ||
+   state == DRM_DP_SIDEBAND_TX_TIMEOUT);
 }
 
 static int drm_dp_mst_wait_tx_reply(struct drm_dp_mst_branch *mstb,
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] drm/dp: Wait up all outstanding tx waiters

2017-05-13 Thread Chris Wilson 
As we can have multiple tx in the queue, with individual waiters, make
sure that all are woken when any state changes (so that we are sure the
right owner of the txmsg is woken).

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 3bdd314f02b1..222eb1a8549b 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -855,7 +855,7 @@ static void drm_dp_destroy_mst_branch_device(struct kref 
*kref)
mutex_unlock(>mgr->qlock);
 
if (wake_tx)
-   wake_up(>mgr->tx_waitq);
+   wake_up_all(>mgr->tx_waitq);
 
kref_put(kref, drm_dp_free_mst_branch_device);
 }
@@ -1510,7 +1510,7 @@ static void process_single_down_tx_qlock(struct 
drm_dp_mst_topology_mgr *mgr)
if (txmsg->seqno != -1)
txmsg->dst->tx_slots[txmsg->seqno] = NULL;
txmsg->state = DRM_DP_SIDEBAND_TX_TIMEOUT;
-   wake_up(>tx_waitq);
+   wake_up_all(>tx_waitq);
}
 }
 
@@ -2258,7 +2258,7 @@ static int drm_dp_mst_handle_down_rep(struct 
drm_dp_mst_topology_mgr *mgr)
mstb->tx_slots[slot] = NULL;
mutex_unlock(>qlock);
 
-   wake_up(>tx_waitq);
+   wake_up_all(>tx_waitq);
}
return ret;
 }
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 195743] Screen flicker and instability on hdmi monitors with AMDGPU, EDID problems

2017-05-13 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=195743

--- Comment #1 from keziolio...@gmail.com ---
Created attachment 256503
  --> https://bugzilla.kernel.org/attachment.cgi?id=256503=edit
dmesg output with the problem, and an xrandr segfault

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 195743] New: Screen flicker and instability on hdmi monitors with AMDGPU, EDID problems

2017-05-13 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=195743

Bug ID: 195743
   Summary: Screen flicker and instability on hdmi monitors with
AMDGPU, EDID problems
   Product: Drivers
   Version: 2.5
Kernel Version: 4.10.13
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: keziolio...@gmail.com
Regression: No

Hi, I want to report the bug described in this forum thread:
https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/947352-recent-extremely-annoying-multimonitor-bug-don-t-know-where-to-report

I'll copy the relevant part for convenience:

"basically it acts like monitors are unplugged and plugged back in, and often
the detected EDID is wrong, like dmesg suggests, wrong resolutions are found
and I remain with one monitor right, one in 1024*768 and the other one off, not
even detected.
This happens only with HDMI monitors, the one DVI monitor that I have seems to
always work reliably, and swapping them has no effect, the left one seems to
have always the same problems (wrong resolution).

In the video, the center monitor is DVI, the other two are identical, connected
with hdmi and are affected by the problem.


I'm 100% sure everything was working right until some weeks ago, never had any
issues with xonotic or cheese in years, i've reproduced also with serious sam
fusion beta

GPU is a sapphire RX480"

Here's a youtube video of the problem:
https://www.youtube.com/watch?v=Tfu_pxRVHag

The system now is basically unusable with multiple monitors and 3d apps, with
continuous flicker

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 195737] AMDGPU: incorrect monitor position on Xorg

2017-05-13 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=195737

--- Comment #3 from beta990 (francois5...@gmail.com) ---
(In reply to Michel Dänzer from comment #2)
> Please attach the output of dmesg and xrandr and the Xorg log file
> corresponding to the problem.
> 
> What does "wrong position" mean exactly? What would be correct?

Hi Michel,

Thanks for your reply. :)
I'll attach the logs and a screenshot later today.


When starting starting Xorg instead of Wayland on amdgpu (blacklisting radeon),
the screen position is moving 5 pixels to the right, instead of being aligned
in the center.

When using the radeon module (and blacklisting amdgpu), the screen position is
aligned correctly. It therefore seems the width/position of the screen is
calculated incorrectly, but only on X.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100239] Incorrect rendering in CS:GO

2017-05-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100239

--- Comment #10 from Bruno Jacquet (Xaapyks)  ---
Thank you Samuel.

Grazvydas, thanks for the patch, it does fix the visual issue, even though I
understand this is not a proper fix. I did not notice a performance drop (in
CS:GO at least) with it, so I will be using until this issue is resolved.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 195737] AMDGPU: incorrect monitor position on Xorg

2017-05-13 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=195737

--- Comment #2 from Michel Dänzer (mic...@daenzer.net) ---
Please attach the output of dmesg and xrandr and the Xorg log file
corresponding to the problem.

What does "wrong position" mean exactly? What would be correct?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101029] notebook does not work when not booted using nomodeset AMD APU

2017-05-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=101029

Craig  changed:

   What|Removed |Added

URL||https://bugs.launchpad.net/
   ||ubuntu/+source/linux/+bug/1
   ||683184

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101029] notebook does not work when not booted using nomodeset AMD APU

2017-05-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=101029

Bug ID: 101029
   Summary: notebook does not work when not booted using nomodeset
AMD APU
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: stein...@gmail.com

in kernel 4.10 and higher unable to boot without enabling nomodeset option
which also removes 3D acceleration for AMD APU processors with hybrid graphics.

See the following link for full detail on the bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1683184

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 101003] segfault with ideas test of glmark2

2017-05-13 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=101003

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #131335|text/x-log  |text/plain
  mime type||

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel