06:34 airlied: danvet: hey so tip is screwed, but it's intel CI topic branch
06:34 airlied: which seems to have some not upstream iommu patches in it
06:35 airlied: which I guess translates, to danvet save drm-tip, you're our only hope
06:40 ccr:blinks his eyes at the fuzzy airlied -hologram projected by a droid
07:32 danvet: airlied, I'll look, but first dentist appointment, yay
07:34 pq: ajax, I always thought of pbuffers as the solution to "I need an EGLSsurface, but I don't have a winsys to talk to." :-)
07:35 airlied: danvet: not sure which is more pain
07:36 danvet: maybe should take laptop along and do them both?
07:36 danvet: at the same time
07:36 danvet: so one pain numbs the other :-)
07:38 pq: ..where, I can agree on this, "I need an EGLSurface" is quite a self-inflicted pain.
10:06 dschuermann: haasn: do you mind having a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/10651 ? it seems some compositor is not robust against non resized swapchains
10:06 gitbot: Mesa issue (Merge request) 10651 in mesa "Revert "vulkan/wsi/x11: lower resize events to VK_SUBOPTIMAL_KHR"" [Vulkan, Opened]
11:38 cmburnett: Alright, I told myself I'd stay awake until I figured this out and it's going about how you'd expect- is there any particular reason that a Vega20 gpu would have issues with something being in the kernel message buffer? This is with OpenBSD so I apologize if I'm off topic here, but I'm trying to fix our driver, so I'd really appreciate any pointers I could get!!
11:46 raster: daniels: one question with your (collabora's) perfetto work... a quick look at the perfetto examples don't lend me to believe that it'd be the right thing for a massif-like tracing of mesa memory usage... like getting bt's on allocs and info like texture vs fbo vs backbuffer vs shader prog etc, along with perhaps miniature thumbnails of those resources? it seems more geared to "wide" rather than "deep" profiling?
11:57 tomeu: I think that's right
11:59 raster: tomeu: ok. cool. wanted to just know if my quick 1000ft view was right or not as i'd love a massif-style deep details profiling
11:59 raster: and i was mulling throwing some start of code for that in somewhere to see how well it works out - i thought it might be orthogonal to pefetto work but wasn't sure
12:00 tomeu: raster: you could always ask in https://discord.com/channels/629013440635207702/629013441096450058 to get a more authoritative answer
12:16 daniels: dschuermann: we need VK_EXTREMELY_SUBOPTIMAL_KHR :P
12:16 daniels: raster: yeah, massif is the massif-like tool ;)
12:17 raster: which doesn't exist as best i can tell..
12:17 raster: like every danged gl tracer is broken, unmaintained or only does opengl (not gles)
12:18 raster: ... i was thinking.. maybe just bury some logs of everyalloc (and free) of a mem resource that is gpu-side (mmaped - not malloced)
12:18 raster: and then env var to dump the log to a file and some tooling to trawl it
12:19 dschuermann: daniels: or we could keep track why something is suboptimal and react later that not some application keeps rendering into that buffer
12:19 dschuermann: the previous commit stated that it's supposed to smooth transitions by allowing ~a couple of additional frames
12:20 daniels: dschuermann: yeah, that's a pretty good idea
12:27 tomeu: btw, there was a power outage in the lab hosting collabora's devices, as used in Mesa CI
12:27 tomeu: machines are coming back up again
13:53 alyssa: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4759
13:53 gitbot: Mesa issue 4759 in mesa "glmark2-es2 -b terrain crashes since Bifrost FP16" [Panfrost, Opened]
13:53 alyssa: More GLSL bugs weeee.
14:16 alyssa:thinks she found the actual bug.. maybe
14:16 alyssa: ("Does it start with G and end with LSL IR?")
14:19 alyssa: mareko: I think something goes wrong in lower_variables_visitor::fix_types_in_deref_chain
16:35 robclark: mareko, Kayden, zmike: btw, I'm kinda thinking there is enough interest in TC for it to have it's own label in gitlab.. any objections if I add one?
16:35 zmike: 👍
16:35 zmike: though we have to make sure to also tag gallium in those issues/MRs or mareko will never see them :)
16:36 robclark: hopefully mareko would turn on notifications for TC label?
16:40 ccr:admires airlied
16:42 Kayden: sounds good to me..
16:47 robclark: ok, done
17:01 Lyude: danvet: any chance you've seen https://patchwork.freedesktop.org/patch/432036/?series=89188&rev=4#comment_775814 btw ?
17:01 Lyude: am not really sure of a good way of solving this problem without just letting drm drivers register their i2c adapters earlier
17:07 danvet: Lyude, uh
17:08 danvet: this makes everything rather nasty
17:08 danvet: but also wtf why do we need a panel driver for a edp panel?
17:08 danvet: that /should/ all autodetect
17:09 danvet: edp shouldn't need a panel really, ever
17:09 danvet: pinchartl, ^^ what's going on here
17:11 danvet: mripard, pick up the entire set of redundant error printing removals?
17:16 mripard: I missed the other ones, sorry
17:16 mripard: it looks like there's a v2 incoming with all of them squashed though
17:17 jenatali: zmike: IIRC mareko said he pays attention to titles, not labels?
17:17 jenatali: Maybe I'm misremembering though
17:19 robclark: danvet: we need a panel driver because we need somewhere to figure out power on/off delays
17:21 robclark: danvet: ie. otherwise you have a chicken/egg issue before you can even read the EDID..
17:22 danvet: robclark, oh man
17:22 danvet: this ... sucks
17:22 danvet: robclark, do we really need a full blown panel driver for this?
17:22 danvet: or is a simple quirk table for edp panels the better option?
17:23 robclark: I believe the approach is panel-simple, with power related delays coming from dt
17:23 robclark: so not sure I'd call that a "full blown" driver
17:24 robclark: danvet: basically the goal is to not require devices to lie about which panel is used and put in bogus timings in simple-panel to cover the worst case of all possible panels when you have a device that could have one of N different panels (or get panel replaced by a different one in repair, etc)
17:25 robclark: afaiu the current state of the art for things like chromebooks that have this issue is just to lie in the dts ;-)
17:26 danvet: doesn't the simple panel dt also include stuff like the mode?
17:26 danvet: robclark, I was thinking of something that's even simpler, like only the panel power timings
17:26 danvet: but I guess then people freak out about the 10ms it takes to read the edid at boot
17:28 robclark: danvet: the display timings only come from EDID.. it's possible that it won't be simple-panel, or that it would ignore the timings from simple-panel.. I'm not too sure about the implementation details (but I followed along with how it should look in dt)
17:29 kisak: robclark: possibly a dumb question, is TC better than having the label be human readable? I'm guessing that TC is threaded context
17:29 hikiko: hello, I'd like to checkout/build dri2 and dri3 to debug something, are those the correct repositories: https://github.com/freedesktop/dri3proto and https://github.com/freedesktop/dri2proto?
17:31 kisak: robclark: nevermind, I missed that it's the common naming convention in the code
17:31 robclark: kisak: TC is threaded context.. I guess that should be at least recognizable to developers who are using TC in their driver (and I wouldn't really expect a user filing a bug to know whether the issue they are having is TC related or not)
17:40 pinchartl: danvet: there's always been eDP panels, hasn't there ?
17:40 pinchartl: you may be able to do some autodetection of models
17:40 pinchartl: but the integration has to be specified in DT
17:40 pinchartl: how to control power supplies for instance
17:40 pinchartl: and that's panel-specific
17:40 pinchartl: the number of supplies and their names, and how they need to be sequenced
17:47 Lyude: danvet: how are panel drivers like this usually handled? I'm not really familiar with simple-panel but it seems like having an i2c adapter is an expectation: https://cgit.freedesktop.org/drm-tip/tree/drivers/gpu/drm/panel/panel-simple.c#n187
17:51 danvet: Lyude, pinchartl robclark figure this out pls, I don't feel like I have much clue to bring to this tbh ...
17:51 danvet: except maybe if we hack around simple-panel being used where it doesn't make much sense (aka for edp maybe, but maybe reality is disappointing and edp panels also need to be hardcoded fully9
17:57 robclark: they need to be hard-coded partially but not fully ;-)
17:57 robclark: I think pinchartl and dianders and others are sorting thru that
17:57 Lyude: danvet: gotcha-I have a feeling this might come down to us just exposing ddc early on devices where things are decoupled like this, but I'll try taking a look to see if there's a better way
18:00 danvet: Lyude, like if we expose it early only because simple-panel needs that instead of something that just hardcodes enough, then that would be a bit sub-optimal
18:00 danvet: but also maybe not the worst
18:00 danvet: but if we do have a need for full simple-panel because edp isn't actually auto-discoverable then *shrug* and lets just expose the i2c channel early and move ont
18:00 danvet: or whatever is needed
18:00 Lyude: yeah if we go that route I'm probably going to go with the solution in that patch series where you have to handle telling the aux core to register i2c early
18:02 Lyude: robclark: you explained this to me back at RH but it's been a while, what's the purpose of panel drivers again?
18:03 robclark: Lyude: it's a bit varied.. some things like dsi panels need panel specific sequences of dsi commands to power on/off (and sometimes control backlight, transition between video/cmd mode, etc).. other panels (most of what simple-panel covers) just need some way so we can know display timings and power sequences, etc
18:08 Lyude: robclark: makes sense
18:14 dianders: Sorry, was in a meeting and just got to this. Not sure there's too much I can bring to the table at this point, but yell if I can help. :-)
18:15 dianders: ...right now I'm just waiting for opinions of others and my v6 patch series is my best guess for how to make this all work, but if there's some better way (hopefully that doesn't involve rewriting the world) I can adjust things. :-)
18:17 Lyude: dianders: do you have any idea why having a partially initialized i2c adapter isn't good enough for simple-panel's EDID reads? like, is the panel device that we're getting in ti_sn_bridge_probe() reading the panel mode even earlier then when we probe the bridge's drm driver?
18:19 dianders: Lyude: No, simple-panel should just be getting a handle to the i2c bus and holding onto it. At the moment it won't actually try to read the EDID until later when someone tries to get the modes.
18:19 dianders: ...but the i2c bus has to be _findable_ in the panel probe function.
18:20 dianders: See the call to of_find_i2c_adapter_by_node() in panel_simple_probe(). That has to be able to return the bus.
18:22 Lyude: wonder if we could delay the panel probing then, hm...
18:22 Lyude: i've gotta go afk so I'll bbiab
18:23 dianders: The bridge chip wants a reference to the panel in _it's_ probe. That's why you get into loops.
18:23 dianders: Yeah, I have a meeting and then lunch too, but I'll be online later too.
18:30 pinchartl: Lyude: we have a big issue with exposing resources needed by other devices. it's a bit of an elephant in the room, and it plagues the whole kernel really. try to unbind a GPIO or clock or regulator driver while the resource is in use... :-)
18:31 pinchartl: the issue here is partly related to the fact that we have a multi-hierarchical hardware setup, with dependencies on the control side (DDC needed to control the panel) and dependencies on the data side (the panel needs a video source, and sometimes needs the clock from its video source to be on in order to access the control interface)
18:32 pinchartl: it's even worse in the DSI case, and we really haven't designed this carefully, it's a bunch of hacks piled on top of each other
18:32 pinchartl: sorting it out correctly is beyond the time I can invest at the moment :-S
19:02 tertl3: #install gentoo
20:09 anholt: tomeu, daniels: I've had some issues with xonotic trace downloads today: https://mesa.pages.freedesktop.org/-/mesa/-/jobs/9664594/artifacts/results/summary/problems.html
20:09 anholt: not every time, so far only on the intel boards (not a630).
20:10 daniels: anholt: hm, I wonder if this is just Intel net/USB issues, or if it correlates with kusma's issues pulling artifacts (not from MinIO but may point to Packet net flake)
20:12 anholt: intel net/usb seems suspicious as a reason given that I can deqp on these boards and the whole rootfs is located on nfs.
20:23 daniels: that was my first thought, but otoh the performance characteristics of termination ~5.5m away vs. ~5500km away are enough to give me pause
20:23 daniels: I don't trust the apl machines because this is their baptism of fire, but I also don't trust our Packet-hosted services right now given the reports of runners not being able to pull complete artifacts
20:25 anholt: computers: still the worst.
20:26 daniels: keeps us from being bored of a Tuesday evening
20:27 daniels: I don't have access to the cbg core, but I could ask them to grab pcaps from the apls <-> minio-packet
20:27 daniels: then stare at those and try to figure out who's (most) in the wrong?
20:28 anholt: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/9666994 uh what. seems really unlikely that they have a board with BM_SERIAL unset
20:28 anholt: (v3d ci's been kind of unstable today, too, I've got some poe fails again)
20:29 daniels: anholt: I get the feeling it would be useful to have Marge drop the link to every job which failed on any of her pipelines into an IRC channel
20:29 daniels: (I say this with some regret, but it's less painful than SMTP at this point, somehow)
20:30 anholt: my inbox would appreciate it if someone else was carrying the load of marge sanity checking
20:30 anholt: it would also be nice if the other driver folks would agree to watch ci irc channels so we could send them flake reports that they could handle
20:31 mattst88: heh, if anyone feel better: some gentoo infra went down and people didn't notice because part of what went down was the bit that's supposed to email and notify people that stuff's down
20:31 daniels: sorry, implicit in that was 'a channel that hardware CI people sat on and watched' rather than PM to you
20:31 mattst88: s/if/if it makes/
20:31 daniels: mattst88: please tell me you implemented the obvious solution of a third layer
20:32 mattst88: naturally we need a carrier pigeon in a cage on top of the computer rack that is automatically released when the watchdog timer triggers
20:44 daniels: /m mattst88 please just name your price, we need your lateral-thinking genius at Collabora
20:44 daniels: uhh oops
20:45 robclark: enterprise pigeons!
20:46 imirkin: just have to make sure the watchdog barks loud enough to scare the pigeons...
20:46 robclark: anholt: I wouldn't be against reporting freedreno ci fails to #freedreno-ci, btw (since a fail could be a flake)
20:47 daniels: robclark: tbh I'd be all for everyone seeing both
20:48 mattst88: daniels: lol
20:48 bl4ckb0ne: mattst88: what if the infrastructure that takes care of feeding the pigeon also goes down
20:49 mattst88: bl4ckb0ne: another pigeon to warn us if the feeder breaks!
20:49 mattst88: it'll be pigeons all the way down
20:49 bl4ckb0ne: redundant pigeon, i like it
20:50 bl4ckb0ne: on another note, is somebody already taking care of bumping the vulkan spec to 1.2.178? it came out yesterday
20:51 bl4ckb0ne: and it seems nvidia changed a lot of stuff, I tried to do it in a patch yesterday
21:05 dianders: Lyude: I'm curious if you have any opinions on how Rajeev ought to handle getting access to the DDC AUX bus? See <https://lore.kernel.org/r/c867b2e59e90899e6c1648e06f5f9cd2@codeaurora.org/>. Should he be sticking calls to the new helpers directly in the sn65dsi86 bridge driver? It felt like it belonged elsewhere, like the panel driver, but there's no way to "export" the AUX bus, right?
21:43 Lyude: dianders: you still around btw? i'm thinking about your question and honestly I'm becoming somewhat more convinced that maybe we should make it so that you can export an aux bus
21:44 dianders: Lyude I'm still here!
21:51 Lyude: dianders: so - I guess one of my first questions is do you know if there's already display panels out there that are exposing their i2c bus in the DT, specifically outside of the eDP case?
21:51 dianders: Lyude Well, the simple-panel code predates me. I found at least a few places that seemed to use it. Let me find the references for you.
21:53 dianders: You'r talking about builtin panels, right? So anything with a physical connector (HDMI / DP port) doesn't count?
21:53 Lyude: dianders: I guess I'm really just curious if there's already DT properties for plain i2c adapters out there
21:53 dianders: Lyude: I think that would leave you with just eDP, wouldn't it?
21:54 dianders: Lyude: try this (rough) search: `git grep -C5 ddc-i2c-bus | grep -C5 panel`
21:54 robclark: (anything w/ hdmi/dp/etc connector would not have panel node in dt or use panel driver, fwiw)
21:55 dianders: Looks like "arch/arm/boot/dts/tegra20-paz00.dts" has an i2c bus for a LVDS panel
21:56 Lyude: robclark: gotcha
21:57 dianders: ...and `arch/arm64/boot/dts/mediatek/mt8183-kukui-jacuzzi.dtsi` (which is a Chrome OS device, but not one I worked on) seems to be for an eDP panel...
21:58 Lyude: robclark: would you have any preference for who uses the DT node then? looking through there's actually quite a number of drivers using ddc-i2c-bus in their DT, so adding an option for ddc-aux-bus seems pretty reasonable
21:59 Lyude: i'm realizing there might be other hellish reasons we'd want this as well, with the possibility of input devices on DP aux on the horizon
22:00 robclark: so, I'm probably not the best one to ask for opinions of how things should look in dt.. but I would point out that it isn't completely uncommon for devices with (for ex) an hdmi port to use a generic i2c for ddc
22:00 Lyude: robclark: yeah-that's kinda the reasoning I'm following here as well
22:00 robclark: rather than have a separate i2c inside the display controller block
22:02 Lyude: I guess that just leaves the question of if the code for looking up the dt node should be in simple-panel, or ti-sn65dsi86
22:04 dianders: Just because my brain always gets twisted around, I want to confirm. You can always do i2c _over_ DP-AUX but there could be things that could be done over DP-AUX that wouldn't be exposed over a normal DDC-I2C bus, right?
22:04 Lyude: dianders: correct
22:07 Lyude:is currently looking to see how other drivers do this kind of probing
22:25 Lyude: dianders: something I'm confused on I guess is why this (I don't think?) doesn't appear to be a problem for anyone other then tegra or ti-sn65dsi86. Unless I'm misunderstanding something (and with my limited ARM experience that's totally possible), it seems like drivers such as tc358767 (creative naming...) don't even seem to create their own connectors until bridge attach
22:27 Lyude: dianders: or could it just be that other drivers in the tree are just putting up with not having an EDID during init?
22:31 Lyude: eh, screw it it, if I've spent this much time at my desk trying to think of a different solution I think that's a sign that we just need to bite the bullet and allow drivers to separate this kind of functionality
22:31 Lyude:goes to respond to rajeevny
22:32 dianders: Lyude: Do you want the long story, or the long story? Good choice.
22:32 dianders: a) Really long ago ARM boards just weren't supported very will with upstream.
22:32 dianders: b) Early ARM support upstream took the "we'll just hardcode the mode". This is why panel-simple is _filled_ with tables of modes. For the most part, those modes are created by reading the EDID manually and then copying the mode to panel-simple. Whee! We want to get _away_ from doing this.
22:32 dianders: c) Some device "solve" the problem by just driving the EDID reading from the bridge chip and not exposing to the panel. This is how some of my earlier patches did it, but I moved to trying to do it in the panel specifically because I want the panel to be able to make decisions based on the EDID to optimize timings. Existing solutions which do the EDID from the bridge chip solve the panel problem via to "white lie"
22:32 dianders: approach. They pretend that only one panel will be connected and put delays that will accommodate all possible panels in that one panel.
22:32 dianders: d) All ARM devices that I'm aware of upstream use a PWM for backlight control. The one Rajeev is trying to support is a first as far as I'm aware.
22:32 Lyude: oooooooooh
22:32 Lyude: ok. that explains a LOT
22:33 dianders: (Sorry, took me a while to write all that up)
22:33 airlied: lots of cheap panels forego the 5c eeprom
22:33 airlied: the stores the EDID
22:33 Lyude: nah it's ok - that was definitely context I needed to understand the whole issue here
22:33 dianders: Ah. For the most part panels I've been involved in have had the EDID but we haven't read it.
22:33 dianders: One argument was that it wasn't worth reading it because we had to hardcode the delays / power sequencing anyway.
22:34 airlied: yeah the delays / power are the fun bits anyways
22:34 airlied: like in theory eDP can give you that info over AUX, but AUX needs powering up
22:34 ajax: there's been two or three attempts at encoding power sequencing in edid too
22:35 ajax: not that i've ever seen them used, but i have seen the pdfs!
22:35 pinchartl: dianders: to be fair to panel-simple, there's lots of non-eDP panels there, that have no support for any kind of dynamic probing, so that's why lots of panels have to hardcode modes
22:35 dianders: pinchartl: yes, there are also lots of eDP panels too. ;-)
22:35 pinchartl: (I was advocating for specifying mode information in DT in that case, but didn't win)
22:35 dianders: For power sequencing, my current plan is here: https://lore.kernel.org/dri-devel/CAD=FV=VZYOMPwQZzWdhJGh5cjJWw_EcM-wQVEivZ-bdGXjPrEQ@mail.gmail.com/
22:36 Lyude: i definitely can see a future where edid/displayid gets used more for info like this as well
22:36 emersion: bl4ckb0ne: isn't the vk update just copypasta for xml and header?
22:36 dianders: If that works out (and Rob H seems to have agreed to it) we migrate a few timings to DT and the rest are looked up based on EDID and a table in the kernel.
22:37 pinchartl: see Documentation/devicetree/bindings/display/panel/lvds.yaml for bindings that specify timings in DT
22:38 pinchartl: and aa121td01.yaml in the same directory for one particular panel using those bindings
22:38 Lyude: dianders: I think i'm sold on the DT node for AUX then, and I think having it in simple-panel imho would be fine.
22:38 pinchartl: ajax: there's been an attempt to encode power sequences in DT too, it was shot down
22:38 Lyude: thanks again for the explanations btw :)
22:39 Lyude: erm, s/having it in simple-panel/using the new helpers in simple-panel/
22:39 pinchartl: Lyude: by "DT node for AUX", do you mean an aux property in the panel node that points to the node of the DP encoder ?
22:39 dianders: Lyude: OK, that's great. Glad to help. I don't lurk here too much but if you say "dianders" I'll notice it eventually.
22:40 Lyude: pinchartl: to whatever has the DP AUX channel (I presume that's the encoder but I hesistate to make such assumptions now), yeah.
22:40 dianders: We still need to figure out how to solve the circular dependency problems, though. Would you be OK w/ my solution for that (early registration of the aux?)
22:41 pinchartl: I assume it will be the previous bridge in the chain in the vast majority of cases, and I don't know if I'll live long enough to see an exception :-)
22:41 pinchartl: dianders: early registration of the AUX bus is fine with me. what bothers me is the lifetime issues, we probably need to refcount it
22:41 pinchartl: think about module unload
22:41 Lyude: dianders: yeah I think I'm alright with that. one thing that might be nice would be to see if you could decouple exposing the /dev nodes for aux until late connector registration
22:42 Lyude: which shouldn't really be an issue for the panel driver/drm driver I'm pretty sure
22:42 dianders: pinchartl: Oh boy. robclark's favorite topic!
22:42 pinchartl: DRM doesn't do well in this area. the bridges are mostly broken, they should be reference-counted too
22:42 ajax: pinchartl: i mean, good, it should definitely not be in dt. in edid it makes sense except for people who are too cheap for an edid eeprom.
22:43 pinchartl: ajax: if it's technically feasible to express it in a generic way in EDID, why shouldn't it be in DT for panels that have no EDID (LVDS or DBI panels with no control bus) ?
22:44 ajax: pinchartl: only because i think the second set should be empty, i suppose
22:44 dianders: pinchartl: I think if there's a standards body that says "here are the lines to control and where you are allowed to require delays" then it would be no problem having it in DT.
22:44 dianders: Generic power sequencing in DT always gets shot down because people want to put the kitchen sink in it and make a full turing complete scripting language.
22:44 pinchartl: ajax: tell that to panel manufacturers :-)
22:44 Lyude: pinchartl: hm-so we already know what device the aux lives on in the dt tree then (assuming the previous bridge in the chain owns it), is there a reason we couldn't just setup the aux adapter on that device and then reference that from simple-panel and the drm driver?
22:45 pinchartl: Lyude: the only reason I can see is if a system would provide the AUX bus in a different device than the previous bridge. unlikely, theoretically possible I suppose
22:46 pinchartl: we could possibly default to that and add an optional DT property to point to the non-default device later if the need arises
22:46 dianders: pinchartl: At the moment from panel-simple we can't find the previous bridge, but that feels like it's a "simple matter of code" to solve...
22:47 pinchartl: dianders: Im' not sure I would make the API bridge-based. it may be better for the AUX adapter lookup function to be given a fwnode pointer
22:48 robclark: module unload for drm w/ bridge/panel/etc is pretty yolo
22:48 pinchartl: another option would be to have the panel DT node as a child of the device providing the AUX bus
22:48 pinchartl: the DT hierarchy is based on control buses, with data buses modelled with OF graph bindings
22:48 pinchartl: so making the panel a child of the sn65dsi86 would make sense
22:49 pinchartl: and then you'd have a new bus type for AUX devices
22:49 Lyude: pinchartl: I like this solution the most so far :)
22:49 pinchartl: the same way an I2C device is a child of the I2C controller
22:49 robclark: dianders, pinchartl: btw as far as timings in dt, qcom takes this to new heights in their windows laptops.. they have an xml file, embedded in an ACPI table, which has fields for the various display timing params, plus sequences of raw dsi/i2c commands that should be sent to power-on / power-of / etc..
22:49 Lyude: yours I mean
22:49 pinchartl: it however starts getting "interesting" when devices have multiple control buses
22:50 pinchartl: for instance a DSI panel that also has an I2C interface, and that requires configuration commands on both I2C and DSI
22:50 dianders: robclark: this is power sequencing, right? Not timings like vblank, hblank, etc.
22:50 pinchartl: we have no good solution to model such devices correctly in DT today
22:50 pinchartl: (or in ACPI for that matter, it's also based on the control hierarchy)
22:51 robclark: both, the display timings needed for the OS.. and sequences of commands and delays for programming.. they don't really have a bridge driver, it is all just xml
22:51 Lyude: xml is a choice
22:51 robclark: (ofc the raw i2c cmds embed the configuration for display timings the bridge needs)
22:51 Lyude: kinda surprised they didn't just go with something like yaml
22:51 robclark: yeah
22:51 pinchartl: robclark: I'd share my thoughts about this interesting qcom design, but I think they can only be voiced in a way that infringes all CoCs at once
22:52 robclark: heheh
22:52 Lyude: lol
22:52 robclark: it certainly is.. "inovative"
22:52 pinchartl: xml is a choice, and telling them to shove it the sun doesn't shine is also a choice we can make :-)
22:53 pinchartl: I've seen similar things, with a USB class that conveyed information from the device to the host in XML format over USB
22:53 pinchartl: the spec was published
22:53 pinchartl: I'm not sure it ever got implemented
22:53 Lyude: dianders: btw, do you think pinchartl's solution would be workable as well?
22:53 pinchartl: robclark: to support those windows laptop, we need board files
22:54 dianders: OK, so my brain is feeble and I'm not sure I followed all of the above of what people liked and didn't like. Sometimes the interweaving made it hard to tell what someone was agreeing with.
22:54 pinchartl: they don't have to be in arch/arm64/ though, somewhere in drivers/ is fine
22:54 pinchartl: there are windows-based intel laptops that have a similar issue on the camera side, where the ACPI "bindings" (is there a standard term for this ?) are completely messed up
22:54 robclark: pinchartl: we are doing dt for those.. newer things don't need a bridge and just have enough dp's out of the chip.. I don't think we'll be doing anything acpi boot (other than efifb) until those newer things
22:55 pinchartl: the windows driver hardcodes model-specific information
22:55 Lyude: dianders: I guess my takeaway is - pinchartl's idea with making the panel device a child seems workable, so I'd try that but if that isn't workable I'm fine with the DT node solution you proposed
22:55 Lyude: and in the latter case - early aux registration would be fine
22:55 pinchartl: dianders: sorry for throwing random proposals, I didn't know one of them would be considered interesting and fall on your plate :-)
22:55 dianders: Lyude: so the panel is a child device of ti-sn65dsi86. That could avoid any bindings changes, but it won't help the circular dependency problem?
22:56 daniels: robclark: so what you're saying is that we need an XSLT interpreter in the kernel to extract the information we need
22:57 dianders: bridge chip still wants panel to be probed when its probe starts and panel probe would still want to get a pointer to its ddc bus at its probe time. We could I suppose re-check if perhaps our parent DT node provided us an aux/i2c bus "later" (after probe). Is that better?
22:57 pinchartl: daniels: I'd rather use yaml. maybe we could use xslt in the kernel to convert the xml data to yaml first ?
22:57 robclark: daniels: heh, well if we wanted to support acpi boot on those things, yeah.. but I think we probably end up sticking to dt for those and wait until more sane devices
22:58 Lyude: dianders: wouldn't it though? the issue is that simple-panel needs the ddc bus of the aux channel before it finishes probing, but if it's a cxhild of the sn65dsi86 bridge then you can call drm_dp_aux_init(), and then initialize the panel with the minimally initialized dp aux adapter
22:58 bnieuwenhuizen: pinchartl: I thought parsing yaml was generally worse than most XML?
22:58 pinchartl: robclark: is there any effort being done to ensure that the people responsible for that peculiar design will not be allowed within 1km of a computer ever again ?
22:58 robclark: we just need a javascript interpreter in the kernel, I'm sure we can find a javascript xml parser
22:59 pinchartl: bnieuwenhuizen: we can propose both to Linus and see what he will reply ;-)
22:59 robclark: pinchartl: no idea, I guess ask microsoft, maybe jenatali knows some folks who can yell about qcom about their acpi
22:59 dianders: Lyude: That would get the panel the AUX bus. I guess then it would know that it could later find the i2c-of-aux from that?
22:59 bnieuwenhuizen: robclark: sandbox it through eBPF? /me runs
23:00 dianders: s/i2c-of-aux/i2c-over-aux/
23:00 Lyude: dianders: well you wouldn't really need the device for the i2c-of-aux at that point. if you're just grabbing the edid, drm_dp_aux_init() is enough for the driver to use the i2c bus for edid probing
23:00 daniels: pinchartl: only if it also involves JSONx
23:01 jenatali: I'm sure if I asked our display folks, they could commiserate with you, but I tend to stay far away from that kind of thing
23:01 Lyude: and then you just call drm_dp_aux_register() later when you have a connector registered
23:01 ajax: i like how the dri2 code in libEGL calls a vtable slot that's filled with "assert on non-swrast loader"
23:01 ajax: this code has definitely been tested
23:05 dianders: Lyude: OK, I can try to code that up. I guess it would look like this:
23:05 dianders: 1. sn65dsi-86 probe starts. Calls drm_dp_aux_init().
23:05 dianders: 2. sn65dsi-86 causes a probe of its child (a panel).
23:05 dianders: 3. The panel code looks to see if the parent provided an aux bus and stashes it away.
23:05 dianders: 4. Later in "attach", the sn65dsi-86 fully registers the aux bus.
23:05 dianders: 5. When the panel is asked for a mode, it somehow figure out how do i2c-over-aux transactions of the aux bus it stashed
23:06 bl4ckb0ne: emersion: maybe i missed a thing
23:07 pinchartl: dianders: for 3., I think you should create a new AUX bus type
23:07 pinchartl: similar to the I2C bus type
23:07 Lyude: ^ (I am fine with this btw)
23:07 pinchartl: with aux adapters, aux drivers and aux devices
23:08 dianders: pinchartl: OK, will have to look at that.
23:08 pinchartl: for 4., if "fully registers" means "exposes it to userspace", sounds good to me
23:08 dianders: pinchartl: I guess before coding any of this up, it would be worth it to confirm that you're OK w/ panel-simple actually being in charge of dealing with the EDID
23:08 dianders: It wouldn't be much fun to try to do all that and then throw it away.
23:10 pinchartl: as long as we can also support operation where the SN65DSI86 output is routed to a real DP connector, I think I'm fine
23:11 pinchartl: the sn65dsi86 driver would need to be in charge of the EDID in that case, as there would be no eDP panel driver involved
23:12 pinchartl: the driver could possibly check if there's a child panel in DT, and expose the bridge .get_edid() operation only if there's none
23:14 dianders: pinchartl / Lyude: OK, thanks. I'll point Rajeev at this conversation and try to find some time to prototype this up...
23:15 Lyude: awesome, thanks!
23:21 mdnavare: bnieuwenhuizen: airlied:emersion: Does Bumble bee rely on DRI_PRIME to render on Nvidia card?
23:21 mdnavare: anyone used the Bumblebee tool and how is it same or different than DRI_PRIME?
23:21 bnieuwenhuizen: IIRC bumble bee is a legacy solution that uses a secondary X server and copies the contents over the CPU
23:22 bnieuwenhuizen: I may be wrong there, my memory is kinda vague on that
23:22 airlied: nope bumblebee doesn't use DRI_PRIME
23:23 bnieuwenhuizen: https://wiki.archlinux.org/title/bumblebee is a pretty good intro from an user perspective
23:23 mdnavare: airlied: So how does Bumblebee do the render on dGPU and display on Intel's integrated?
23:23 airlied: mdnavare: virtualgl
23:24 bnieuwenhuizen: mdnavare: set up a secondary X server on the nvidia GPU with a virtual display, direct the app to render that, capture the buffer on the CPU and copy it to the primary Xserver (which uses the intel iGPU)
23:25 airlied: they have a few different methods from reading that, but yeah it's all a secondary X server
23:25 airlied: since for a long time the nvidia binary driver didn't work with DRI_PRIME at all
23:27 mdnavare: so in general does that still have an advantage over DRI_PRIME in terms of say better power management etc?
23:27 airlied: mdnavare: shouldn't have, but it's a binary driver I've no insight
23:28 bnieuwenhuizen: I guess the nice thing is that outside of when you use it you were pretty sure the nvidia GPU was as off as ACPI allowed it to be. With the binary driver there is no insight into that with DRI_PRIME
23:29 bnieuwenhuizen: (well and broken ACPI stuff all around of course)
23:31 mdnavare: what do you mean by Bumblee being a binary driver?
23:31 bnieuwenhuizen: I mean nvidia being a binary driver
23:31 bnieuwenhuizen: "With the binary driver there is no insight into that with DRI_PRIME" <- non-bumblebee case
23:32 airlied: you'
23:32 airlied: you'd never use bumblebee with nouveau
23:32 bnieuwenhuizen: I think bumblebee unloads the nvidia driver and then used some stuff with ACPI to turn the GPU off though?
23:32 mdnavare: oh Bumblebee doesnt work with Nouveau? So only with Nvidia closed source driveR?
23:33 bnieuwenhuizen: with nouveau you'd just use DRI_PRIME
23:33 airlied: it's purely designed around the problems the nvidia driver presents
23:33 ajax: you could probably make the thing bumblebee does work with nouveau, but it only tries to use nvidia
23:33 mdnavare: oh got it
23:35 mdnavare: And Bumblebee uses some other config file mechanism to use DGPU for render somehow as well as some intelligent ways to avoid lmem to smem copies and also some intelligentw ay of power management that DRI_PRIME doesnt do because with DRI PRIME there s always lmemt o smem copy etc
23:35 mdnavare: ?
23:37 airlied: not sure it avoids lmem to smem copies, more just ties to do them as fast as possible with the APIs it can access
23:37 airlied: since it has to work via the NVIDIA binary driver which really just expose GL
23:38 mdnavare: okay
23:39 mdnavare: And it also tries to do some automatic PM for dGPU?
23:39 mdnavare: after its done rendering
23:39 airlied: I think it's pretty much manual PM
23:39 airlied: once the app closes it unloads the nvidia driver and uses acpi to turn off the gpu
23:40 iive: isn't there an issue with gpl-only api calls for the memory transfer? since nvidia driver is proprietary that would be a problem?
23:41 airlied: it's all done in userspace
23:42 airlied: the nvidia driver has access to the prime transfer functions
23:42 mdnavare: airlied: With DRI_PRIME is that the same case with PM - after say the glxgears finishes rendering on dGPU, and now its only displaying with iGPU, do we expect by default the dGPU to go to low power state?
23:42 mdnavare: or is that something that the kernel needs to do
23:44 airlied: mdnavare: we expect the driver to do whatever the drivers does when nothing is using the gpu
23:44 airlied: the kernel driver should use runtime pm to power itself down via ACPI
23:44 mdnavare: okay got it
23:45 mdnavare: so nothing special for the hybrid graphics case i guess
23:45 airlied: well the drivers have code to do that stuff, at least amdgpu and nouveau have
23:46 airlied: they either use ACPI, D3cold or maybe on newer GPUs they just have a really lower power state
23:47 mdnavare: airlied: I will double check on Intel but should be there
23:47 mdnavare: just with what we had with Integrated
23:47 airlied: I think for discrete you might need some more
23:48 airlied: since we never use ACPI to power off integrated
23:48 ajax: nor could you, really
23:48 airlied: exactly :-P
23:48 airlied: I think on most modern systems putting the device into D3cold can make it all happen
23:49 airlied: mdnavare: it's mostly only found on laptops
23:49 airlied: you can't normally power down a discrete GPU you've plugged into a standard motherboard