03:01nyef: What's the significance of "mxm: unmatched output device 00003ef9fed22920"?
03:35nyef: ... It's an MXM ODS that doesn't correspond with anything known to the driver?
03:56nyef: Hrm. _DOD returns one of two sets of five words, depending on some value. There are six ODS records.
03:58nyef: One CRT, two HDMI, two DisplayPort, and one LVDS. That looks right.
04:01nyef: Okay, the unmatched output device is one of the HDMIs. That seems plausible because there's only one physical HDMI output on this box (though there's also an HDMI input?).
05:05Jeansf: worry has been a temporarily running out of resources for me personally, prgrammatically there does not appear to be worry of where the open source drivers are heading
05:08Jeansf: so if i get involved in some projects i am willing to upload piles of code and fixes to the stacks as well, as i personally have loved open operating systems, i thought what heck this is where i at least should partly work too
05:10Jeansf: searhing work in my country, most of the jobs in sw field are crosslined by me with me being uninterested to work on propriatary software in our infrastrucures in even a smaller degree
05:16Jeansf: to be more accurate any microsoft user allready for 15-years or even more propriatary solutions user who is not that rich to waste money, i would lock up to mental institution
05:18Jeansf: dunno how's it with others, but here's an army of those, i hate this with passion as one of our famous exneighbor would say
05:30Jeansf: just conflict of interests, a poor country as it is , i am not willing to build models of insfrustructures up using propr. sw, have not really bothered to work with such pigs and dumbasses
05:37nyef: Hrm. In "disp: outp 08:0006:0344: type 06 loc 0 or 4 link 1 con 8 edid b bus 3 head 3", what's the significance of a different value for head? And in the immediately following "bios dp" line, what's the significance of the values there changing?
05:41nyef: Ah, different cards, nevermind.
05:41Jeansf: nyef: no clue, lonely holidays, what is the problem though, are you trying to attach HDMI receiver at all?
05:41nyef: One of these logs was from before I played musical panels with my two test systems.
05:42nyef: No, I'm trying to get the eDP panel on my laptop to resume properly after suspend.
05:42Jeansf: nyef; never met any troubles there, but does it come up again embedded displayport that is?
05:43nyef: Post-suspend, nouveau can't find a sink on the output.
05:43Jeansf: ahah ok, so it really is some trouble
05:44nyef: If I'm using a LVDS panel it comes up no problem, but the LVDS panel can't do what I want.
05:45nyef: Also, the proprietary driver works fine, so I can in theory just keep using that.
05:46nyef: Except that it doesn't work with massively-new kernels in gentoo, so it keeps me at a kernel version cap.
05:47Jeansf: nyef: allrighty , so it's a bug, yeah of course you need to attach some bigger display output where as not having HDMI, as i gather
05:49Jeansf: yeah it's called suspend to disk or ram, maybe try both of those though, used to be some s1 or s2-3 methods
05:49Jeansf: i am not sure what they do exactly i never inspected the code, but prolly putting the buses to sleep and such, and saving the state to disk/ram
05:50nyef: The previous symptoms (before I was directed to the drm-next tree) kicked in when doing the suspend part of a suspend-to-disk.
05:50nyef: Haven't tried that since.
05:51nyef: Might try mucking about with some of the suspend debug options, or trying to force the monitor to DPMS sleep and trying to resume it.
05:51nyef: Just to see what happens.
05:54nyef: But not tonight. Almost certainly going to crash soon.
05:55Jeansf: nyef: yeah try to use any workwround you can, and also work on nouveau is possible, but almost looks as if it is indeed a bug of this open source driver
05:56Jeansf: i do not have displayport on nvidia card
05:57Jeansf: but i could try to fix the old multithreading issue for the driver based of the documentation at some stage
06:00Jeansf: nouveau is theoretically superior to closed source driver, at least once some minor bugs have been fixed, i would not reccoment to give up on this, as the solution is probably quite easy in code
06:01Jeansf: allthough the bug is has annoying symptoms, the fix is prolly easy, testing is annoying though
06:04nyef: Overall, I'd rather run nouveau. But for most of the systems I've tried, the blob has been the only thing that works properly. The couple of exceptions have been cases where the blob won't run at all, and nouveau is the only game in town... And even there, I've tended to have to hunt bugs.
06:07Jeansf: yeah :) overall i am on meds, and pretty much everything has allready been done to me, i feel myself as calm knowing that bugs happen, and generally do not mind hunting bugs, it's just i do not have any card by other vendors either which have dp port
06:11Jeansf: just the strategy is, that do not mind or get pissed off cause of the bug, just fix it if no immediate workaround is there
06:13Jeansf: i had once a similar trouble, but that it did not work out, hibernate or suspend to ram/disk, but it was like year 2005, with nforce motherboard chipset needing a minor agp line
06:15Jeansf: after a single line was added to chipset was functioning properly, so you'r devices are pcie probably this time around and with new specs, that i have read, but can't remember offhand
06:16Jeansf: but as the LVDS comes up, it's more likely some eDP issue indded
06:18Jeansf: the predictable bug is either in kernel or in ddx though
06:20Jeansf: it should be quite easy to look, if console or something comes up instead of X, and you'd likely know where the bug is
06:21nyef: Pretty much every bug I've run into with nouveau and been able to diagnose has been a kernel bug.
06:23nyef: Wrong endianness, broken defaults on openfirmware systems, things like that.
06:25Jeansf: yeah , ok but does not hurt to try, but this eDP connects to cpu via pcie bus or what io/pin?
06:27Jeansf: prolly more like graphics card has certain bus for it right
06:29nyef: There's some connector in the middle of the mainboard that the panel cable screws into. IIUC, the CPU and the GPU connect to the mainboard through some sort of edge connectors.
06:30nyef: There's actually two connectors on the mainboard, right next to each other. One is for an eDP panel, the other for an LVDS panel.
06:31nyef: The SSDT with the MXM stuff has a few places where it dispatches on something or other (I think it's part of the EC) to change a few things to match either the LVDS or eDP configuration.
06:31Jeansf: yeah but how are they controlled over some mmio or via pcie?
06:31Jeansf: aaah MXM?
06:31Jeansf: as of nvidia's pcie bus right?
06:32nyef: I have no clue. I haven't really understood anything post-PCI. I barely have a grasp on PCI64.
06:33Jeansf: MXM is graphics card bus, i remember developed by NVIDIA but also used with some other vendors as i remember
06:34Jeansf: do you see LVDS and eDP routing into that bus with some lines appearing on mobo leading to that bus?
06:35nyef: Honestly, I'm hoping not to have to take the case apart again on one of these systems for a good long while.
06:35Jeansf: it is quite oftenly so though, so that could be pcie bug as well in kernel
06:36Jeansf: do you have multiple graphics cards in that system?
06:37nyef: I think that it's just the one card, but I'm not entirely sure. There might be a second video system on the mainboard that only comes out of hiding if an LVDS panel is connected rather than an eDP panel.
06:38nyef: Almost certainly an MXM v3.0 connector.
06:40Jeansf: then i am not sure, if that is possible that some pcie lanes function after resume where as some would not, cause of a bug
06:47nyef: Ooh. Another table to figure out.
06:55nyef: Okay, there's no way I'm going to dig through this tonight. But I now have a suspicion for what might be going wrong to dig into tomorrow. Thank you, Jeansf!
06:56Jeansf: nyef: you're welcome , absolutely my pleasure, i take minor nap too
14:58Jeansf: nyef: i personally think, if you have no sink for dp, that this issue is rather somewhere in this file. http://lxr.free-electrons.com/source/drivers/gpu/drm/nouveau/nvkm/engine/disp/dport.c
15:05Jeansf: presumably you need to retrain the link, using some terminalogy i have no clue about
15:06nyef: Yes, the link needs retraining, but in order to do that we have to have a sink, and the sink isn't showing up.
15:08nyef: I'm currently thinking that the panel might be partly powered off, or something like that, and thus not showing up as a sink.
15:09Jeansf: yes, well that would indeed lead to some of the dcb procedures, that i yestirday was looking into
15:38Jeansf: https://patchwork.kernel.org/patch/7000791/ the strategy is sort of explained there, it seems to be using i2c but i have not found what is the dpdc data, it uses vga_switcheroo as proxy
15:45Jeansf: could be that you are not loading vga_switcheroo somehow
15:49nyef: I haven't been. My next kernel build will be including it.
15:52Jeansf: does this ddc stand for digital display control or something, i dunno, there is so many abbrevations dpdc
15:54nyef: Display Data Channel, maybe?
15:55nyef: There's a nouveau_connector_ddc_detect() that does interesting things with eDP panels.
15:55nyef: That's in nouveau_connector.c
15:55Jeansf: ahah ok
15:56Jeansf: it's also in dcb docs
15:56nyef: Looks like switcheroo only applies for LVDS panels.
15:59Jeansf: allright, ok, did not yet sniff this out, but then perhaps use the logic to do the same with dp?
16:01nyef: The DCB table defines panel power GPIOs for up to eight panels, but this seems to only be handling one?
16:01Jeansf: nyef: exactly i got pretty lost there too, that how come
16:02nyef: I'm also not at all convinced that this is the only touchpoint for this thing, or that it even IS a touchpoint.
16:04nyef: I think that one of my next steps has to be to find, dump, and manually parse the DCB for this hardware.
16:04nyef: Because it's going to be something simple and unexpected like "oh, it's on LCD1, not LCD0, because LCD0 is the LVDS slot".
16:05nyef: After all, who would make a laptop with both an LVDS and an eDP slot for its panel?
16:05Jeansf: yeah if you have skills, it looks pretty complex...
16:06nyef: Can't be any worse than some of the compiler debugging I've done over the years.
16:06nyef: (Okay, yes it can, but that would be spectacularly unlikely.)
16:08Jeansf: nyef: yeah ok, sounds like you have delt with programming, but try to just make it try to do the eDP reinit too first, before going for complex stuff
16:10nyef: I'm still gathering information at this point, not trying to make any changes yet. And I rather expect that my first few changes will be to try and gather more data or confirm hypotheses rather than to attempt to get things running.
16:12Jeansf: your hypthesis about vga_swictheroo only restoring LVDS seems to be correct
16:13Jeansf: *hypothesis even
16:15nyef: "Hypothesis" based on the explicit checks for connector type of LVDS anywhere I saw a callout to switcheroo. (-:
16:15nyef: At that point, I deemed it not worth doing a kernel build to test it.
16:17nyef: Hunh. fabricate_dcb_encoder_table() is much shorter than I remember it being. I'm going to have to start digging out and setting up my mac hardware to see if it all still works right, aren't I?
16:21Jeansf: nyef: no i would still advise to do a build with vga_switcheroo
16:22nyef: Oh, that'll happen, I've already added it to my build configuration, I'm just not doing another build immediately.
16:25Riastradh: Hi nyef. Teaching a LispM to accelerate graphics with nvidia hardware?
16:25nyef: Found the DCB header...
16:25Jeansf: or maybe check if you are able to quickly from bios disable the integrated gpu...
16:26nyef: Riastradh: No, trying to get nouveau to resume from suspend on my current primary laptop. Preferably without ruining the panel backlight.
16:26nyef: Integrated GPU, if I have one, is supposed to be disabled purely by using the eDP connector instead of the LVDS connector.
16:38Jeansf: CONFIG_DRM_KMS_HELPER enable this one too definitely
16:40nyef: Already done, and CONFIG_DRM_KMS_FB_HELPER.
16:42Jeansf: then by the looks of it , it should resume as said in the patch too, i am not sure what you said about VGA_SWITCHEROO, how was you able to physically test it, if your kernel does not include it?:)
16:44Jeansf: how it should do, is that vga_switcheroo unlocks the ddc ,and drm_rdaux restores the dp
16:44Jeansf: it should wake up the monitor power state via acpi according to comments, that is needed to be done before
16:49Jeansf: i am pretty sure, allthough it's overly too complex for me according to comments in network, console on dp should come up, if there is no ddx bug in addition
16:49Jeansf: so it is likely things like wayland and this stuff, likely will definitely work
16:50nyef: And there can't be a ddx bug in this scenario: I'm just trying to get the kernel-level stuff working at this point, so I don't even have X installed in my test environment.
16:52Jeansf: nyef: i see there have been though they are suspend not resume bugs , or maybe i do not remember
16:52Jeansf: it has to restore you know all the framebuffer objects
16:53Jeansf: defintely there can be , but it is maybe yeah unelikely
16:53Jeansf: cause in the logs it almost seems like it was passed that point allready
17:00Jeansf: you're diagnosis was very accurate in my opinion , but it says you should try to manually push a monitor button, that normally is a button on the keyboard, but it can be sent via acpi as i remember
17:00Jeansf: you have to make sure doing it before the dpcd read
17:07Jeansf: sink is said to be monitor, so the logs tell you infact indeed, that it did not come up, but kms_helper method is said to be working with suspend and resume, at least was at some point as you see
17:09nyef: Was at some point, for some hardware.
17:10nyef: I always entertain the possibility that I have something that nobody cared enough about to make work properly. Because, quite often, I do.
17:11Jeansf: nyef: correct, with some hardware infact indeed, so i would just try to push buttons of the monitor before as said in the code, and use the KMS_HELPER VGA_SWITCHEROO way that was doing it for some hw as you said..
17:11Jeansf: i.e maybe yeah not for you it will work out
17:12nyef: It's a laptop, only one button should be necessary: The one that I already hit to wake the system from suspend. Anyway, guests are here, and lunch should be ready soon, so I should go mingle. I'll be in and out, or just plain out, for a while.
17:14Jeansf: sounds like you have an external monitor that does not respond to that button
17:14Jeansf: you need to sleep , hit the monitor button and then signal with another acpi push that you complexted the wake up, and all
17:14Jeansf: before the mentioned read
17:18Jeansf: some sort of monitor waking up is malfunctioning in nouveaus primary detection code, where it works on nvidia
17:18Jeansf: 's driver
17:20Jeansf: maybe it does not make whole lot of sense, i dunno what circuit in the monitor could detect that there is no traffic, i.e how come it is able to switch itself out, but for instance my TV does that too
17:20Jeansf: i dunno what is the method though
17:25Jeansf: imo it would make more sense to try both ways, not to hardcode the conditional, and try to open the datalines in some cases before the sink comes up, maybe some monotirs will respond to this
17:35Jeansf: http://lxr.free-electrons.com/source/drivers/gpu/drm/drm_dp_helper.c#L355 dp_link_power_up says this is only for dp1.1 and above specification where they have a method for this to work automatically, imo the kms codepath should work
17:37Jeansf: http://lxr.free-electrons.com/source/drivers/gpu/drm/nouveau/nouveau_connector.c#L958 it's indeed in dpms, so you diagnosed the stuff, very accurately nyef
17:41Jeansf: though is it something that they call MST, the panel?
17:54Jeansf: https://www.altera.com/en_US/pdfs/literature/ug/ug_displayport.pdf mst has it in the same 0x0600 , so probably all you need to do to fix the direct code is add a sleep there
18:17Jeansf: add 2000); to the line http://lxr.free-electrons.com/source/drivers/gpu/drm/nouveau/nvkm/engine/disp/dport.c?v=4.6#L364 and shift what is currently there one ahead
18:18Jeansf: usleep_range(1000, 2000);
18:23Jeansf: damn it, add it to the line 365 of course
18:36Jeansf: anyways i head off to bed, it seems first it does bitwise AND in the if conditionthen bitwise AND with bitwise NOT for the if first body instruction, following with bitwise OR as understood, & & ~ | respectively
18:37Jeansf: the result is should be toggling in the DPMS wake up, as nyef allready yestirday thought where the problem was
18:44Jeansf: but it almost appears as this path forgets to sleep, it won't get the monitor up properly
18:45Jeansf: before the dp_link_train_init(dp, outp->dpcd & 0x01); gets called and failes to retrain the links, that was one of the theories, but i kinda need to to seeking job tomorrow, so
20:18nyef: Only hits on DP_SET_POWER in the drm-next tree are in nv50_display.c, nv50_sor_disable(), setting to D3.
20:22nyef: ... Which may be why I got an "improvement" switching to drm-next.
20:26nyef: Yeah, not seeing many hits on drm_dp_link_power_up(), which looks like important logic for this case.
20:28Jeansf: nyef: ok, so it was able to resume with drm-next?
20:29nyef: No, with drm-next it doesn't do the flickery solid-white to black screen thing.
20:30nyef: Which means no more progressive hardware damage to the backlight.
20:32Jeansf: nyef: i did not throughly expect, but seems there are two different paths, which i am guessing because i did not read all of the code..
20:33nyef: Only likely hit is in bridge/analogix-anx78xx.c...
20:34nyef: ... No hit on the discovery message. Looks like we've got a plausible cause.
20:34Jeansf: nyef: but then they went to new macros
20:34Jeansf: DPCD_SC00_SET_POWER , search for this one, and add the sleep as i told you perhaps?
20:34nyef: ... So, also check the include/ tree?
20:35nyef: Okay, that's a one-line change.
20:36nyef: Two if I need to add a header.
20:36Jeansf: nyef: correct
20:38nyef: Okay, now I need to find my USB stick and remember the invocation for building a new kernel.
20:38Jeansf: and try to compile only the needed hunk, i have not really compiled kernel for ages, but it was something like make M=$(pwd) modules
20:40Jeansf: make -C <path_to_kernel_src> M=$PWD
20:41nyef: In this case, I use genkernel.
20:43Jeansf: could probably do the same yeah, if the clock catches mods without scew
20:44Jeansf: i used genkernel too, it automatically builds initramfs or initrd image too, as i understand right, yeah this will do nicely too probably
20:51Jeansf: i saw that hakzsam finally landed the sched codes, anyone knows if the work affected kepler too, or only maxwell and pascal?
20:55nyef: ... Adding that delay doesn't seem to have helped.
20:56nyef: Going to try and get a post-suspend dmesg log.
20:56Jeansf: damn, was too goog to be true, yeah please post it to dpaste.com
20:56Jeansf: goog:) let's make it good
20:59nyef: Still same thing, link not detected.
21:00Jeansf: ok, i am looking into as you said the drm-next tree from github
21:01Jeansf: hold on, there appears to be sleep missing but, damn rest of that looks quite complex, and i need to read more
21:11nyef: include/drm/drm_dp_helper.h and nvkm/engine/disp/dport.h disagree on the D3 power state value.
21:11nyef: Not relevant, but relevant.
21:12Jeansf: one gets one value, and other one something different? so try the vga_siwtcheroo method then
21:12nyef: Why? Trying to LEAVE D3, not enter it.
21:15Jeansf: basically yeah, that was what i thought, no clue what they do, one powers down one wakes up prolly, somewhere it is mixed up what i was trying to say, the states that is
21:18Jeansf: but what does this monitor of your edp actually show, it should be powered on or is it in suspend state, just physically what does the monitor show on it's display?
21:18nyef: There's a brief flicker, and then black.
21:18nyef: Doesn't seem to even bring the backlight up.
21:19nyef: And the nouveau version of the constant is the wrong one.
21:20Jeansf: very careless than
21:20nyef: Mmm. Trying to figure out what the spec actually says vs. what nouveau is doing.
21:23Jeansf: what the heck, but the logs show from your dmesg that eDP is connected
21:23nyef: If it's in a power-down mode, the HPD is required to still register, but the sink (and the i2c generally) doesn't need to respond, per the DP spec.
21:24nyef: It's required to wake within 1ms from a differential signal provided on the i2c channel.
21:24nyef: And... yeah, not seeing anything in a brief scan to support that idea.
21:25Jeansf: depends how long your dmesg is, it changes eDP-1 from connected to disconnected
21:25Jeansf: 73.150270] [drm:drm_helper_hpd_irq_event] [CONNECTOR:46:eDP-1] status updated from connected to disconnected
21:26nyef: Yeah, but that's after the link training failed, isn't it?
21:28nyef: ... And HPD is optional for an embedded link anyway, so I don't really know if it's there or not.
21:32nyef: Hrm. "In case there is no reply to AUX CH request transaction, the Source Device must retry at least three times." -- VESA DisplayPort Standard Version 1.1a, section 9.1, paragraph 5, sentence 2.
21:33Jeansf: but it does not
21:33nyef: What am I looking at here?
21:34Jeansf: this is where it should retry according to your story
21:34nyef: That's not the impression I get, but okay.
21:37Jeansf: AUX_TRACE(&aux->base, "sink not detected");
21:37Jeansf: ret = -ENXIO;
21:37Jeansf: goto out;
21:37Jeansf: the same thing gets retired on aux channel later, but if the sink is not there, then it will quit, maybe retry this one too
21:38nyef: The screen definitely flickers for about a second during resume, then goes black.
21:44nyef: Hypothesis: In dport.c, the invocation of nvkm_rdaux() for DPCD_SC00 fails outright, but wakes the panel temporarily.
21:45nyef: The panel stays awake for half a second to a second and a half, then goes back to sleep, because the power control is still at D3.
21:45nyef: And the place to do the retry is in dport.c.
21:46Jeansf: Hypothesis2: in kms_drm_helper.c and in mentioned drm_rdaux is different codepath , but requires
22:27nyef: Guess that goes on the list to try soonish.
22:57justonequestion: is 'nouveau.blacklist=yes' as a kernel parameter enough to block it from binding to my GPU upon boot and will that pci device just be in a 'driver-less' state after boot? can I then just bind an out-of-tree kernel module after loading it into kernel space (that's compatible)?
23:16Jeansf: i have given up following the history from the web, there is atomic mst branch queued for 4.10 , it occationally barely worked before
23:37Jeansf: nyef: https://email@example.com/msg26366.html
23:48Jeansf: nyef: you're more intelligent in that departement, cause i yet do not know what that hdp is actually, cause i never found displayport full specs:)
23:48Jeansf: nyef: but according to this red hat hacker it ought to fix this thing
23:50Jeansf: cause i looked it wasn't yet available in drm-next tree of airlied's repo
23:54Jeansf: hans de geode , mainly worked for input with peter, dec 19 2016, 8 days ago