[REGRESSION] i915: No HDMI output with 4.4
On Fri, Feb 12, 2016 at 09:52:03AM +0200, Oleksandr Natalenko wrote: > Ville, > > I've applied patch you've provided and did couple of replugging with > intel_reg in between. Here are the results. > > I used additional VGA cable to see what actually I type in console :). > My life would have been a bit easier if you had included the reg dumps in the mail. Copy paste manually this time. > Both HDMI and VGA cables plugged: [1] (0x000c4000): 0x0008 (0x000c4004): 0xf1b5 (0x000c4008): 0x (0x000c400c): 0x (0x000c4030): 0x00101010 > Both HDMI and VGA cables unplugged: [2] (0x000c4000): 0x (0x000c4004): 0xf1b5 (0x000c4008): 0x (0x000c400c): 0x (0x000c4030): 0x00101010 > Only HDMI cable plugged: [3] (0x000c4000): 0x (0x000c4004): 0xf1b5 (0x000c4008): 0x (0x000c400c): 0x (0x000c4030): 0x00101010 > Only VGA cable plugged: [4] (0x000c4000): 0x0008 (0x000c4004): 0xf1b4 (0x000c4008): 0x (0x000c400c): 0x (0x000c4030): 0x00101010 What these show is that the live status for the digital ports never goes to 1, which is rather wtf. VGA gets reported correctly. Everything else looks normal to me. > And here goes dmesg with all the stuff logged: [5] лÑÑ 12 09:37:01 pfactum.lanet kernel: port C live status __ __ __ __ __ Same deal here. The live status never indicates anything being present during the 250ms that we poll it. Few other ideas: - Was the monitor sleeping when you tried this? Can you maybe push some button on it and then immediately run the intel_reg read command again? - Do you have another monitor to try? - Do you have another cable to try? - Maybe the pullup/down on the hpd line is misconfigured or something. Any chance of updating the BIOS on the machine? - What does 'intel_reg read 0xc2000 0xc2004 0xc2020' say? - The spec claims the TMDS vs. SDVO select has something to do with hpd generation. I can't see any difference on my IVB though, so not sure it's really true. What does 'intel_reg read 0xe1140 0xe1150 0xe1160' tell us? Let's try these anyway (with the cable plugged in): intel_reg write 0xe1140 0x0 intel_reg write 0xe1150 0x0 intel_reg write 0xe1160 0x0 sleep 1 intel_reg read 0xc4000 intel_reg write 0xe1140 0x800 intel_reg write 0xe1150 0x800 intel_reg write 0xe1160 0x800 sleep 1 intel_reg read 0xc4000 intel_reg write 0xe1140 0x800800 intel_reg write 0xe1150 0x800800 intel_reg write 0xe1160 0x800800 sleep 1 intel_reg read 0xc4000 intel_reg write 0xe1140 0x80 intel_reg write 0xe1150 0x80 intel_reg write 0xe1160 0x80 sleep 1 intel_reg read 0xc4000 > > Hope this helps. > > [1] https://gist.github.com/58a0eb50dcf84e104555 > [2] https://gist.github.com/7e8749a3e2cc58ea8aac > [3] https://gist.github.com/9d76930da7380634b845 > [4] https://gist.github.com/c0d2e2f64242ad4f01f2 > [5] https://gist.github.com/fda3b9fed3ca4d31cd20 > > 11.02.2016 16:01, Ville Syrjälä wrote: > > OK, so the hpd interrupt does happen, and yet the live status > > supposedly > > claims that nothing is there. Port C live status definitely works here > > on my IVB, so not sure what the deal is. > > > > Can you grab intel-gpu-tools and run > > intel_reg read 0xc4000 0xc4004 0xc4008 0xc400c 0xc4030 > > a couple of times after plugging the monitor in, and also run it when > > nothing is plugged in. > > > > Also you could try something like the following patch so we might > > observe the live status with a bit more detail. Though the fact that it > > doesn't seem to work for you even when the monitor was already plugged > > in is somewhat troubling: > > > > --- a/drivers/gpu/drm/i915/intel_hdmi.c > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c > > @@ -1392,12 +1392,17 @@ intel_hdmi_detect(struct drm_con
[Bug 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)
https://bugs.freedesktop.org/show_bug.cgi?id=66067 --- Comment #34 from Daniel Scharrer --- Came across another game that does this wrong: Never Alone (http://store.steampowered.com/app/295790) However this one does need shadow comparison in other shaders. I've contacted the developers about this (as I have for the other affected games) but I fear that this problem will just keep coming up - especially with the NVIDIA driver ignoring the shadow sampler from the shader and Catalyst also having a workaround (at least the Trine games rendered correctly with it the last time I tried). Additionally at one of the developers I have contacted suggested they are unlikely to release another patch so this will likely remain broken. Would it be possible to - instead of branching in the shader - create shader variants if the TEXTURE_COMPARE_MODE does not match up with the use in the shader? Again, would be good to know how the blob handles this. -- 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/20160213/7dd97c88/attachment.html>
[Bug 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)
https://bugs.freedesktop.org/show_bug.cgi?id=66067 --- Comment #35 from Roland Scheidegger --- (In reply to Daniel Scharrer from comment #34) > Came across another game that does this wrong: Never Alone > (http://store.steampowered.com/app/295790) However this one does need shadow > comparison in other shaders. > > I've contacted the developers about this (as I have for the other affected > games) but I fear that this problem will just keep coming up - especially > with the NVIDIA driver ignoring the shadow sampler from the shader and > Catalyst also having a workaround (at least the Trine games rendered > correctly with it the last time I tried). Additionally at one of the > developers I have contacted suggested they are unlikely to release another > patch so this will likely remain broken. > > Would it be possible to - instead of branching in the shader - create shader > variants if the TEXTURE_COMPARE_MODE does not match up with the use in the > shader? Possible, sure. Essentially you'd have to put a mask into the shader key indicating which texture units have the PIPE_TEX_COMPARE_R_TO_TEXTURE bit set in the sampler (well, for used units and only those which actually have shadow targets). But then you'd have a dependency on sampler changes so you'd need to recheck that on changes there and recompile (well, recompilation shouldn't be an issue, as you'd only ever have to do it for those totally broken shaders, and only once for each shader). I blame cg - makes it super easy to mistakenly use the shadow variant of a texture instruction. At least I haven't seen anyone mistakenly using shadow variant with glsl... I'm wondering though why anyone is still using that stuff. > Again, would be good to know how the blob handles this. It would be possible to recognize this bug only on ARB_program shaders, so you only have some extra cost there - that is make some shader key there and recompile if it doesn't match currently bound samplers. This actually should be easier - core gl requires depth_compare_mode being ignored for non-depth textures (which is why the sampler code in mesa/st checks the base format and only sets depth compare mode with depth textures) but there is no such requirement in ARB_fp_shadow as this needs to match (well, just as it needs to match the target in the shader... just don't tell me the apps don't get this right neither...). This means you don't have a dependency on the bound textures, only samplers. I suppose it could be done in the mesa state tracker that way outside of drivers but I'm not sure if anyone is really thrilled... Those shaders are really simply terribly broken, broken, broken (and people are probably less interested in trying to come up with some quite hacky, creative workarounds if it's really clearly the fault of others...) - there's very good reasons behavior is undefined for such shaders. -- 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/20160213/99eb9e96/attachment-0001.html>
[Bug 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)
https://bugs.freedesktop.org/show_bug.cgi?id=66067 --- Comment #36 from Roland Scheidegger --- (In reply to Roland Scheidegger from comment #35) Actually don't you get some comment in the ARB_fp_program it was compiled from cg? You could just take that as a hint you're going to see that bug and invoke the additional checks only then (as I don't think you'd ever see that bug outside of cg generated programs). -- 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/20160213/9dd7fb8b/attachment.html>
[Bug 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)
https://bugs.freedesktop.org/show_bug.cgi?id=66067 --- Comment #37 from Nicholas Miell --- You could look for "# cgc version" near the beginning of the program source (almost certainly the second line), but that assumes the shaders weren't post-processed to strip out all the comments. Alternately, you could just disable it entirely by default and include a driconf option. The fact remains that the games work correctly on other OpenGL implementations and are ancient enough that they're no longer supported and will never be fixed. -- 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/20160213/607fe9ed/attachment.html>
[Bug 94133] relatevly low performance rv740
https://bugs.freedesktop.org/show_bug.cgi?id=94133 Bug ID: 94133 Summary: relatevly low performance rv740 Product: Mesa Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: roman.elshin at gmail.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 121737 --> https://bugs.freedesktop.org/attachment.cgi?id=121737&action=edit Xorg.log I just installed ubuntu 15.10 (with oibaf and commendsarnex ppa to see how good is my radeon hd4770 (rv740) works with fresh graphics stack). Unigine Valley-1.0 (native) and MafiaII Game (wine with Gallium Nine) was used to see video performance differences against windows7. Linux Unigine Valley Benchmark 1.0: FPS:8.5 Score:356 Min FPS:4.2 Max FPS:13.8 Windows7 Unigine Valley Benchmark 1.0 (dx11 render, as opengl wasn`t able to run): FPS:15.9 Score:666 Min FPS:9.2 Max FPS:29.5 Linux Mafia2 Game (internal benchmark) under wine with Gallium Nine, dri3): 22.2fps Windows7 Mafia2 Game(internal benchmark) under wine with Gallium Nine, dri3): 42.4fps It works (without visible artifacts) and it is great!, but it is almost twice as slow against windows. There are some benchmarks on phoronix (http://www.phoronix.com/scan.php?page=article&item=radeon_1404_win81&num=3) for more recent and powerfull r600g hw, and there was no such big differences there. So is it r700 classs hw works slow with gallium in general, or it something wrong with just rv740 support? (or something else ...?) -- 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/20160213/e75d5a8e/attachment.html>
[Bug 94133] relatevly low performance rv740
https://bugs.freedesktop.org/show_bug.cgi?id=94133 --- Comment #1 from Roman Elshin --- Created attachment 121738 --> https://bugs.freedesktop.org/attachment.cgi?id=121738&action=edit dmesg -- 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/20160213/364ed95e/attachment.html>
[Bug 94133] relatevly low performance rv740
https://bugs.freedesktop.org/show_bug.cgi?id=94133 Alex Deucher changed: What|Removed |Added Severity|normal |enhancement --- Comment #2 from Alex Deucher --- The open source Linux driver has not been as optimized as the windows driver. -- 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/20160213/b7a1e566/attachment.html>
[Bug 71789] [r300g] Visuals not found in (default) depth = 24
https://bugs.freedesktop.org/show_bug.cgi?id=71789 Max May changed: What|Removed |Added Version|11.0|11.1 --- Comment #10 from Max May --- With Ubuntu Mate 16.04a2 on a G4 PowerBook5,8 I have to confirm, that this bug is still present with Mesa 11.1.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/20160213/d2c6fc42/attachment.html>
[Bug 94133] relatevly low performance rv740
https://bugs.freedesktop.org/show_bug.cgi?id=94133 --- Comment #3 from Roman Elshin --- yes, but my quastion: is it optimized for rv740 not less than for other chips supported by r600g (for some reasons, bugs, etc..)? performance difference at first sight seems too big. -- 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/20160213/c537598e/attachment-0001.html>
[Bug 66067] Trine 2's fragment normal buffer is mixtextured on Radeon HD 6770 (Juniper)
https://bugs.freedesktop.org/show_bug.cgi?id=66067 --- Comment #38 from Roland Scheidegger --- (In reply to Nicholas Miell from comment #37) > You could look for "# cgc version" near the beginning of the program source > (almost certainly the second line), but that assumes the shaders weren't > post-processed to strip out all the comments. > > Alternately, you could just disable it entirely by default and include a > driconf option. Actually I suppose in theory it would be possible to do this in the state tracker with relatively little overhead. You'd just have to validate the shadow targets the first time you draw for arb_fp shaders iff they have shadow sampler dcls and change them to non-shadow if the samplers don't have compare mode set (it would have to be conditional on a driconf variable though that way, because if you only validate the first time it would break conformant apps which happen to have the samplers wrong the first time they draw which could for instance happen if they try to force early compilation). Afterwards no further validation should be required. Not sure it's all that feasible though, for instance shader validation happens before texture/sampler validation so you'd need to be careful, probably would make the code somewhat ugly just for fixing broken shaders... -- 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/20160213/8d0353cc/attachment.html>
[PATCH 2/2] dt-bindings: Add TPO TPG110 binding
On Tue, Feb 2, 2016 at 5:28 PM, Thierry Reding wrote: > On Mon, Feb 01, 2016 at 09:50:43AM +0100, Linus Walleij wrote: >> +This binding builds on the DPI bindings, adding a few properties >> +as a superset of a DPI. See panel-dpi.txt for the required DPI >> +bindings. > > It is unfortunate that we have these two types of bindings, one used by > some of the legacy fbdev drivers and the other by DRM/KMS drivers. There > isn't really much we can do about it, though, as far as I can see. I wasn't aware that they were any different. Where is the equivalent binding for DRM/KMS panels? I guess one must have been merged first and the second one screwed up by not reusing the first one :( > This panel is used with an fbdev driver, right? Yes. I don't know if I will be able to convert the AMBA CLCD driver from fbdev to DRM/KMS but I was hoping I would not have to change the DT to redescribe the same hardware for that, but now it sounds like that is a consequence... Yours, Linus Walleij
[PATCH 00/29] Enabling new DAL display driver for amdgpu on Carrizo and Tonga
've put a lot of work into this, but I think you are going > > to > > get a lot of review pushback in the next few days and without knowing the > > reasons this path was chosen it is going to be hard to take. > > Yeah agreed, we need to figure out the why/how first. Assembling a > de-staging TODO is imo a second step. And the problem with that is > that before we can do a full TODO we need to remove all the os and drm > abstractions. I found delayed_work, timer, memory handling, pixel > formats (in multiple copies), the i2c stuff Rob noticed and there's > more I'm sure. With all that I just can't even see how the main DAL > structures connect and how that would sensibly map to drm concepts. > Which is most likely needed to make DAL properly atomic. More stuff plain duplicated I spotted: - some edid handling (probably because of the duplicated i2c, but probably also because dal). - has it's own infoframe encoding it seems - home-grown logging. Yes, DRM_DEBUG isn't the most awesome, but dynamic prinkt is pretty neat from what I understand and we should just move DRM_DEBUG over to that if you need more flexibility. Cheers, Daniel > So de-staging DAL (if we decided this is the right approach) would be > multi-stage, with removal of the abstractions not needed first, then > taking a 2nd look and figuring out how to untangle the actual > concepts. > > Aside: If all this abstraction is to make dal run in userspace for > testing or whatever - nouveau does this, we (Intel) want to do this > too for unit-testing, so there's definitely room for sharing the > tools. But the right approach imo is to just implement kernel services > (like timers) in userspace. > > Another thing is that some of the features in here (hdmi 2.0, improved > dongle support) really should be in shared helpers. If we have that > hidden behind the dal abstraction it'll be pretty much impossible > (with major work, which is unreasonable to ask of other people trying > to get their own driver in) to extract&share it. And for sink handling > having multiple copies of the same code just doesn't make sense. > > Anyway that's my quick thoughts from 2h of reading this. One wishlist: > Some design overview or diagram how dal structures connect would be > awesome as a reading aid. -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- next part -- A non-text attachment was scrubbed... Name: DC.png Type: image/png Size: 169043 bytes Desc: DC.png URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160213/fecd0cd4/attachment-0001.png>
[PATCH 3/3] drm: panel-simple: implement URT UMSH-8596MD-xT panel support
Hi Thierry, On 08.10.2015 10:24, Thierry Reding wrote: > On Wed, Oct 07, 2015 at 11:02:20PM +0200, Maciej S. Szmigiero wrote: >> This patch implements support for United Radiant Technology >> UMSH-8596MD-xT 7.0" WVGA TFT LCD panels in DRM panel-simple >> driver. >> >> Signed-off-by: Maciej Szmigiero >> --- >> This replaces "drm: panel-simple: add URT UMSH-8596MD-xT panel support" >> submission. >> >> drivers/gpu/drm/panel/panel-simple.c | 54 >> >> 1 file changed, 54 insertions(+) > > Looks good to me. I'll wait for Rob or anyone else to ack the vendor > prefix before merging this. Now the vendor prefix has been acked, but because some files have moved since these patches were originally submitted I will update and resubmit them. > Thierry Maciej
[PATCH 1/2] dt-bindings: Add URT UMSH-8596MD-xT panel bindings
Add DT bindings for United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panels. Signed-off-by: Maciej S. Szmigiero --- This replaces "of: add URT UMSH-8596MD-xT panel DT bindings" submission. .../bindings/display/panel/urt,umsh-8596md.txt | 16 1 file changed, 16 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/urt,umsh-8596md.txt diff --git a/Documentation/devicetree/bindings/display/panel/urt,umsh-8596md.txt b/Documentation/devicetree/bindings/display/panel/urt,umsh-8596md.txt new file mode 100644 index ..088a6cea5015 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/urt,umsh-8596md.txt @@ -0,0 +1,16 @@ +United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel + +Supported are LVDS versions (-11T, -19T) and parallel ones +(-T, -1T, -7T, -20T). + +Required properties: +- compatible: should be one of: + "urt,umsh-8596md-t", + "urt,umsh-8596md-1t", + "urt,umsh-8596md-7t", + "urt,umsh-8596md-11t", + "urt,umsh-8596md-19t", + "urt,umsh-8596md-20t". + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory.
[PATCH 2/2] drm/panel: simple: Add URT UMSH-8596MD-xT panels support
Add support for United Radiant Technology UMSH-8596MD-xT
7.0" WVGA TFT LCD panels in DRM panel-simple driver.
Signed-off-by: Maciej S. Szmigiero
---
This replaces "drm: panel-simple: implement URT UMSH-8596MD-xT panel support"
submission.
drivers/gpu/drm/panel/panel-simple.c | 54
1 file changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index f88a631c43ab..6530c1ffca2c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1176,6 +1176,42 @@ static const struct panel_desc shelly_sca07010_bfn_lnn =
{
.bus_format = MEDIA_BUS_FMT_RGB666_1X18,
};
+static const struct display_timing urt_umsh_8596md_timing = {
+ .pixelclock = { 3326, 3326, 3326 },
+ .hactive = { 800, 800, 800 },
+ .hfront_porch = { 41, 41, 41 },
+ .hback_porch = { 216 - 128, 216 - 128, 216 - 128 },
+ .hsync_len = { 71, 128, 128 },
+ .vactive = { 480, 480, 480 },
+ .vfront_porch = { 10, 10, 10 },
+ .vback_porch = { 35 - 2, 35 - 2, 35 - 2 },
+ .vsync_len = { 2, 2, 2 },
+ .flags = DISPLAY_FLAGS_DE_HIGH | DISPLAY_FLAGS_PIXDATA_NEGEDGE |
+ DISPLAY_FLAGS_HSYNC_LOW | DISPLAY_FLAGS_VSYNC_LOW,
+};
+
+static const struct panel_desc urt_umsh_8596md_lvds = {
+ .timings = &urt_umsh_8596md_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
+};
+
+static const struct panel_desc urt_umsh_8596md_parallel = {
+ .timings = &urt_umsh_8596md_timing,
+ .num_timings = 1,
+ .bpc = 6,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+};
+
static const struct of_device_id platform_of_match[] = {
{
.compatible = "ampire,am800480r3tmqwa1h",
@@ -1280,6 +1316,24 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "shelly,sca07010-bfn-lnn",
.data = &shelly_sca07010_bfn_lnn,
}, {
+ .compatible = "urt,umsh-8596md-t",
+ .data = &urt_umsh_8596md_parallel,
+ }, {
+ .compatible = "urt,umsh-8596md-1t",
+ .data = &urt_umsh_8596md_parallel,
+ }, {
+ .compatible = "urt,umsh-8596md-7t",
+ .data = &urt_umsh_8596md_parallel,
+ }, {
+ .compatible = "urt,umsh-8596md-11t",
+ .data = &urt_umsh_8596md_lvds,
+ }, {
+ .compatible = "urt,umsh-8596md-19t",
+ .data = &urt_umsh_8596md_lvds,
+ }, {
+ .compatible = "urt,umsh-8596md-20t",
+ .data = &urt_umsh_8596md_parallel,
+ }, {
/* sentinel */
}
};
