[RFC] drm + i915 DP MST code preview
On 2 May 2014 18:52, Chris Wilson wrote: > On Fri, May 02, 2014 at 02:39:37PM +1000, Dave Airlie wrote: >> Hi, >> >> Branch: >> http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-i915-mst-support >> >> Okay I've gotten this to light up some monitors using -modesetting so it >> must be ready for an initial posting, > > I see that connectors are added/removed dynamically based on branch > discovery, but I haven't spotted how that is communicated to userspace. > I was expecting to see a new uevent. Or do you simply want userspace to > update it lists of connectors on every hotplug event? Is there anyway to > retrieve the guid so that we can associate the same XID to each branch > device for the server lifetime? (Is that even a sane idea?) Can we > detect when a DP dongle is present splitting DVI/VGA using MST but since > they use different encoders they already falsely appear as unique > connectors to i915.ko? I hadn't considered a new hotplug event but I suppose one makes sense for this actually, however userspace will still get old school hotplug events anyways as the connectors transition to connected state. I'm not sure how much overhead userspace would have calling drmGetResources on every hotplug it certainly shouldn't be a common event, the GUID is only on DP 1.2 devices, so you don't get one for ever port, also GUIDs are wiped on powerdown on most devices, default GUID is 0 except where devices have USB hubs as well, so it probably doesn't make much sense to bother exposing them directly. I'm not sure about the last question, MST is always active DP conversion, each port the protocol advertises will appear as a connector, the protocol doesn't offer much more detail, like my dock has a DP port and a HDMI port shared on one DP port, depending on what is plugged in the port is configured different, but it appears as the same connector. Dave.
[Bug 73528] Deferred lighting in Second Life causes system hiccups and screen flickering
https://bugs.freedesktop.org/show_bug.cgi?id=73528 --- Comment #5 from MirceaKitsune --- Any news on this? With a new distribution upgrade coming slowly, I'm worried that Second Life might no longer work properly and even crash my system. Can anyone with a 6xxx series card try the latest Mesa GIT and attempt to reproduce the problem? -- 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/20140503/9f603a7a/attachment.html>
[Bug 78061] KWin rendering broken on SUMO2 with enabled glamor
https://bugs.freedesktop.org/show_bug.cgi?id=78061 --- Comment #2 from russianneuromancer at ya.ru --- > Please attach your xorg log and dmesg output. Attached. > Is this still and issue with a newer kernel or mesa? Yes, still issue with libdrm 2.4.54+git1405030630.5126fc, Mesa 10.3~git1405030730.64c467, radeon driver 7.3.99+git1405030730.be1469 and Linux 3.15rc3. -- 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/20140503/c37244b5/attachment.html>
[Bug 78061] KWin rendering broken on SUMO2 with enabled glamor
https://bugs.freedesktop.org/show_bug.cgi?id=78061 --- Comment #3 from russianneuromancer at ya.ru --- Created attachment 98364 --> https://bugs.freedesktop.org/attachment.cgi?id=98364&action=edit dmesg -- 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/20140503/eea8f013/attachment.html>
[Bug 78061] KWin rendering broken on SUMO2 with enabled glamor
https://bugs.freedesktop.org/show_bug.cgi?id=78061 --- Comment #4 from russianneuromancer at ya.ru --- Created attachment 98365 --> https://bugs.freedesktop.org/attachment.cgi?id=98365&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/20140503/c64055cf/attachment-0001.html>
[RFC] drm + i915 DP MST code preview
On Sat, May 03, 2014 at 07:08:02AM +1000, Dave Airlie wrote: > On 2 May 2014 18:52, Chris Wilson wrote: > > On Fri, May 02, 2014 at 02:39:37PM +1000, Dave Airlie wrote: > >> Hi, > >> > >> Branch: > >> http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-i915-mst-support > >> > >> Okay I've gotten this to light up some monitors using -modesetting so it > >> must be ready for an initial posting, > > > > I see that connectors are added/removed dynamically based on branch > > discovery, but I haven't spotted how that is communicated to userspace. > > I was expecting to see a new uevent. Or do you simply want userspace to > > update it lists of connectors on every hotplug event? Is there anyway to > > retrieve the guid so that we can associate the same XID to each branch > > device for the server lifetime? (Is that even a sane idea?) Can we > > detect when a DP dongle is present splitting DVI/VGA using MST but since > > they use different encoders they already falsely appear as unique > > connectors to i915.ko? > > I hadn't considered a new hotplug event but I suppose one makes sense > for this actually, > however userspace will still get old school hotplug events anyways as > the connectors transition to connected state. > > I'm not sure how much overhead userspace would have calling > drmGetResources on every hotplug it certainly shouldn't be a common > event, I realised that GETRESOURCES is not too heavy later. I was thinking that the maintainance of the X state would be more troublesome, but it doesn't appear so. I still think having a separate event type for branch changes will be useful, if only for the purposes of diagnostics. > the GUID is only on DP 1.2 devices, so you don't get one for ever > port, also GUIDs are wiped on powerdown on most devices, default GUID > is 0 except where devices have USB hubs as well, so it probably > doesn't make much sense to bother exposing them directly. Ok. It looks like if we do attempt to maintain persistent naming, we need to do it in the kernel anyway. That is to make sure that a downstream device always has the same type-id upon reconnection - at least for the lifetime of module. Or maybe the output name is irrelevant for preserving extended desktop configurations? > I'm not sure about the last question, MST is always active DP > conversion, each port the protocol advertises will appear as a > connector, the protocol doesn't offer much more detail, like my dock > has a DP port and a HDMI port shared on one DP port, depending on what > is plugged in the port is configured different, but it appears as the > same connector. Hmm. I think I am confused. I thought we had a recent report of a DP-to-VGA/DVI splitter that on Windows you could drive the VGA + DVI separately, but on Linux they could only be cloned. That sounds like MST. However, I am pretty sure the xrandr was reporting VGA and HDMI outputs (behind the splitter) that the user had some control over. I am not too sure if I have the details right though. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 77394] Desktop freezes often when KDE starts compositing or mplayer GL window changes
https://bugs.freedesktop.org/show_bug.cgi?id=77394 --- Comment #12 from nine at detonation.org --- Today I gave in and installed fglrx. Despite considerable torture the system is stable, so I can at least rule out some hardware problem. Do you have any suggestions on what I can do to help fix this problem? Considering that I have a way to reliably reproduce these GPU lockups, that I have the kernel source to play with and that I can ssh into the system, I may be able to gather more information. Unless the problem is likely to be in the firmware. -- 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/20140503/01a771a9/attachment.html>
[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3
https://bugzilla.kernel.org/show_bug.cgi?id=75241 --- Comment #6 from Christian K?nig --- (In reply to Clemens Ladisch from comment #5) > It's an Eizo S2100, but this should not matter because the clocks seen by the > monitor are always about the same (162MHz/75kHz/60Hz). If some were out of > range, the monitor would show an error message, but with the PLL problem, the > monitor does not appear to detect even an out-of-range signal. I'd guess > the > PLL itself cannot handle the parameters. The PLL should be able to handle this quite fine. It's just that when you increase the reference and post divider you can better match the wanted frequency for the cost of increased jitter and general signal stability. I have one monitor here that practically works with everything I give to it, another one can't handle it when the frequency doesn't precisely match and a third one doesn't like it when we have a high jitter in the signal. The trick is to find the right sweet spot where you can make everbody happy. > The largest working ref_div_max limit is 131. Thanks allot, going to use 128 then (just because it's a nice round number) until somebody else starts to complain that his monitor doesn't likes the signal. Christian. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #80 from Honza Br?zdil --- Created attachment 98377 --> https://bugs.freedesktop.org/attachment.cgi?id=98377&action=edit /var/log/Xorg.0.log I tried also to rebuild kernel with the Tahiti Fix, but still nothing. -- 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/20140503/bfa97df0/attachment.html>
[Bug 60879] [radeonsi] X11 can't start with acceleration enabled
https://bugs.freedesktop.org/show_bug.cgi?id=60879 --- Comment #81 from Pali Roh?r --- (In reply to comment #74) > Created attachment 98257 [details] [review] > Fix v2 > > Pali, I have sent this patch to the mailing list for review, can you confirm > that it fixes the issue for you. Hello, I applied this patch on top of mesa, but it is not working :-( Xserver show only black screen. And in dmesg I see this: [ 31.269778] radeon :05:00.0: GPU fault detected: 147 0x09e25201 [ 31.269785] radeon :05:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0E6B9BCF [ 31.269788] radeon :05:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x02052001 [ 31.269792] VM fault (0x01, vmid 1) at page 241933263, read from CB_CMASK (82) In Xorg.0.log are no errors. After killing X in dmesg are these lines: [ 307.388090] radeon :05:00.0: GPU lockup CP stall for more than 276120msec [ 307.388104] radeon :05:00.0: GPU lockup (waiting for 0x0002 last fence id 0x0001 on ring 0) [ 312.832194] pci_pm_runtime_suspend(): radeon_pmops_runtime_suspend+0x0/0xc0 [radeon] returns -22 [ 320.270503] detected fb_set_par error, error code: -22 When I start X again, it immediately crash and in Xorg.0.log are these errors: [ 320.199] drmOpenDevice: node name is /dev/dri/card0 [ 320.199] drmOpenDevice: open result is -1, (Invalid argument) [ 320.199] drmOpenByBusid: Searching for BusID pci::05:00.0 [ 320.199] drmOpenDevice: node name is /dev/dri/card0 [ 320.199] drmOpenDevice: open result is -1, (Invalid argument) ... [ 320.270] (EE) RADEON(0): [drm] Failed to open DRM device for pci::05:00.0: No such file or directory [ 320.270] (EE) RADEON(0): Kernel modesetting setup failed [ 320.270] (II) UnloadModule: "radeon" [ 320.270] (II) Unloading radeon [ 320.270] (EE) Screen(s) found, but none have a usable configuration. [ 320.270] Fatal server error: [ 320.270] no screens found Old patch (which can be applied on older mesa version) worked fine without any problem. Note that I did not changed kernel, still using same version 3.14-rc1. -- 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/20140503/1cda3c42/attachment.html>
[Bug 75211] Division error in radeon_compute_pll_avivo (X hang)
https://bugzilla.kernel.org/show_bug.cgi?id=75211 --- Comment #10 from Christian K?nig --- (In reply to Darren Salt from comment #9) > No crash now. Good, thanks for testing. > However, the kernel log is spammed with > [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:14] Well, X is sending totally nonsense to the kernel. It's actually good that the logs get spammed so somebody notices that something is really going wrong here. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 2/2] drm/radeon: lower the ref * post PLL maximum
From: Christian K?nig
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=75241
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 9ff0e2f..408b6ac 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_display.c
@@ -862,7 +862,7 @@ static void avivo_get_fb_ref_div(unsigned nom, unsigned
den, unsigned post_div,
unsigned *fb_div, unsigned *ref_div)
{
/* limit reference * post divider to a maximum */
- ref_div_max = min(210 / post_div, ref_div_max);
+ ref_div_max = min(128 / post_div, ref_div_max);
/* get matching reference and feedback divider */
*ref_div = min(max(DIV_ROUND_CLOSEST(den, post_div), 1u), ref_div_max);
--
1.9.1
[PATCH 1/2] drm/radeon: check that we have a clock before PLL setup
From: Christian K?nig Partially fixes: https://bugzilla.kernel.org/show_bug.cgi?id=75211 Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/atombios_crtc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index 6da10d2..c31c12b 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -1902,6 +1902,9 @@ int atombios_crtc_mode_set(struct drm_crtc *crtc, (ATOM_DEVICE_TV_SUPPORT | ATOM_DEVICE_CV_SUPPORT)) is_tvcv = true; + if (!radeon_crtc->adjusted_clock) + return -EINVAL; + atombios_crtc_set_pll(crtc, adjusted_mode); if (ASIC_IS_DCE4(rdev)) -- 1.9.1
[Bug 77142] Garbled text in Gtk2 applications
https://bugs.freedesktop.org/show_bug.cgi?id=77142 --- Comment #2 from eric --- The problem I've described in the top comment, is when using agpmode=4. I somehow can not use agpmode=8. When agpmode is set to 8, the X server will not start. Loading the radeon module with modprobe is no problem, but starting the X server, for example with startx, will hang the computer. Xstart should open 3 xterm windows, but during the opening of the first xterm window the computer hanged. When setting agpmode to 1 or 2, I get this message: [drm:radeon_agp_init] *ERROR* Illegal AGP Mode: 1 (valid 4, 8), leaving at 8 So I can only set agpmode to -1. With agpmode=-1 the garbled text has disappeared. But certain movements on the screen can not keep up with the mouse movement. For example when moving around a window with the mouse (I use KDE's wobbling window) and scrolling a long webpage by dragging the vertical slider up and down with the mouse in Konqueror/Rekonq (Firefox doesn't have this problem). The movement on the screen is smooth, but it is more behind the mouse than when agpmode is set to 4. Setting agpmode to -1 is a better solution than disabeling EXAPixmaps or RenderAccel. -- 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/20140503/4cb6aaa4/attachment.html>
[Bug 75401] New: vgaswtitcheroo doesn't work for AMD Radeon 8870m (possibly due to "wrong" PCI class)
https://bugzilla.kernel.org/show_bug.cgi?id=75401 Bug ID: 75401 Summary: vgaswtitcheroo doesn't work for AMD Radeon 8870m (possibly due to "wrong" PCI class) Product: Drivers Version: 2.5 Kernel Version: 3.11.10 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: low Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: drill87 at gmail.com Regression: No I've got Samsung 870Z5E notebook equipped with AMD Radeon 8870m video card (and Intel HD 4000 graphics). I always failed to use vgaswitcheroo to disable the discrete card -- there wasn't even its entry in debugfs. After a little investigetion of radeon module's source code I found, that the problem happens, possibly, due to "unusual" PCI class of my Radeon 8870m. According to command "lspci -nn" Radeon 8870m has PCI class id 0380, which is corresponds to PCI_CLASS_DISPLAY_OTHER (in pci_ids.h). On the other hand, when radeon module check number of videocards, it excepts them to have class PCI_CLASS_DISPLAY_VGA (0300). Thus module concludes that I have only 1 videocard (Intel HD, which has 0300 class id) and decides, that there's no need for vgaswitcheroo to be initialized. I tried to edit radeon kernel module by adding additional checks for PCI_CLASS_DISPLAY_OTHER class id (in 2 places). After that vgaswitcheroo started to work -- the entry appeared in debugfs and I could disable the discrete graphics card. Though I'm not sure if everything went right because I failed to use radeon card for actual rendering through DRI PRIME even in the newest kernel stable version (3.14.2) -- X server crashes even if I try to issues glxinfo command. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 75401] vgaswtitcheroo doesn't work for AMD Radeon 8870m (possibly due to "wrong" PCI class)
https://bugzilla.kernel.org/show_bug.cgi?id=75401 --- Comment #1 from drill87 at gmail.com --- Created attachment 134941 --> https://bugzilla.kernel.org/attachment.cgi?id=134941&action=edit Output of "lspci -nn" command This log has wring revision number for radeon 8870m (rev ff), because right now I'm shutting it out through acpi_call command. Everything else is right. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 73320] [radeonsi] LLVM runs out of registers during register allocation in Painkiller Hell & Damnation
https://bugs.freedesktop.org/show_bug.cgi?id=73320 --- Comment #40 from Damian Nowak --- I confirm this bug is a case for me on Radeon 7870 and Xonotic with highest details only. High details run fine. Using Arch Linux (mesa 10.1.1, llvm 3.4). @filipp.andjelo at gmail.com Since you are using Arch too, would you mind writing a PKGBUILD that would include all the patches that we need to test? I'd love to help and test the patches out, but I'd rather stay away from digging into how to compile these things. ;-) -- 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/20140503/33c91fd7/attachment.html>
[PATCH 0/2] Add support for sii9234 chip
On Fri, Apr 11, 2014 at 01:48:28PM +0200, Tomasz Stanislawski wrote: > Hi everyone, > This patchset adds support for sii9234 HD Mobile Link Bridge. The chip is > used > to convert HDMI signal into MHL. The driver enables HDMI output on Trats and > Trats2 boards. > > The code is based on the driver [1] developed by: >Adam Hampson >Erik Gilling > with additional contributions from: >Shankar Bandal >Dharam Kumar > > The drivers architecture was greatly simplified and transformed into a form > accepted (hopefully) by opensource community. The main differences from > original code are: > * using single I2C client instead of 4 subclients > * remove all logic non-related to establishing HDMI link > * simplify error handling > * rewrite state machine in interrupt handler > * wakeup and discovery triggered by an extcon event > * integrate with Device Tree > > For now, the driver is added to drivers/misc/ directory because it has neigher > userspace nor kernel interface. The chip is capable of receiving and > processing CEC events, so the driver may export an input device in /dev/ in > the > future. However CEC could be also handled by HDMI driver. > > I kindly ask for suggestions about the best location for this driver. It really is an extcon driver, so why not put it in drivers/extcon? And that might solve any build issues you have if you don't select extcon in your .config file and try to build this code :) thanks, greg k-h
[PATCH 1/2] misc: add sii9234 driver
On Fri, Apr 11, 2014 at 01:48:29PM +0200, Tomasz Stanislawski wrote: > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig > index 1cb7408..3b7f266 100644 > --- a/drivers/misc/Kconfig > +++ b/drivers/misc/Kconfig > @@ -515,6 +515,14 @@ config SRAM > the genalloc API. It is supposed to be used for small on-chip SRAM > areas found on many SoCs. > > +config SII9234 > + tristate "Silicon Image SII9234 Driver" > + depends on I2C I doubt this is the only dependency, right? thanks, greg k-h
[PATCH TRIVIAL] drm/tilcdc: Fix clock retrieval error handling
Check the validity of the immediately returned display clock, instead of
the functional clock already verified previously.
Signed-off-by: Nikolai Kondrashov
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 171a820..f10bc56 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -200,7 +200,7 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
}
priv->disp_clk = clk_get(dev->dev, "dpll_disp_ck");
- if (IS_ERR(priv->clk)) {
+ if (IS_ERR(priv->disp_clk)) {
dev_err(dev->dev, "failed to get display clock\n");
ret = -ENODEV;
goto fail;
--
1.9.2
