16:27 <marex> I still wonder why some of the video pipelines in kernel use this component_add stuff

16:27 <marex> is that legacy ?

16:28 <marex> sravn: ^

16:30 <lynxeye> marex: Mostly legacy from before device-links were a thing.

16:31 <marex> lynxeye: and so, NXP would use it for their fancy new LCDIF driver, of course

16:35 <lynxeye> marex: They've found a bit too much inspiration in imx-drm for all the i.MX8 graphics stuff they did...

16:36 <marex> lynxeye: so ptx is to blame for that ? :-)

16:36 <marex> lynxeye: mxsfb doesnt use that API :-)

16:38 <lynxeye> Yep, we are taking the blame. To be fair the component framework was specifically added by Russell to keep the bits in imx-drm together. device-links were nowhere to be seen at that time.

16:39 <marex> lynxeye: so shifting it to russel, heh

16:39 <marex> lynxeye: with a complex pipeline like the ipuv3, I can see how that might've been needed back then

16:39 <marex> lynxeye: but with super-standard linear pipeline like the mxsfb on mx8mm ... why oh why

16:40 <lynxeye> marex: even with the imx8mm you need a way to tear down the DRM device when one of the invloved drivers (mxsfs, bridges, panel) goes away

16:41 <marex> lynxeye: isnt that what hte device links are for ?

16:41 <lynxeye> that's the fundamental issue solved by the component framework. But now you can achieve the same thing with device links.

16:41 <marex> so yeah :)

16:45 <lynxeye> Yea, at this point it's all history. The component framework just happend to solve this issue 2.5 years before device links existed and even then device links still needed to learn a few tricks to be able to replace components.

16:50 <marex> lynxeye: so while I still have you here

16:50 <marex> lynxeye: why dont we switch SMP GPCv2 handling to the GPCv2 driver too ?

16:51 <marex> lynxeye: I can kinda answer that in two ways myself, but what is your take on it ?

16:53 <lynxeye> PSCI is kind of useful when thinking about virtualisation, so I'm not really opposed to the ARM dictated de-faco standard of all new SoCs in the Linux kernel handling SMP that way.

16:54 <marex> lynxeye: except that means we do like x86 does with ACPI -- all the bad stuff is buried in firmware

16:54 <marex> lynxeye: and then, bugs start to surface

16:54 <marex> lynxeye: and we had that both with x86 and acpi and TFA GPCv2

16:57 <lynxeye> marex: True. But then on i.MX8M you can at least fix the firmware. The difference (at least to me) between the power domain and SMP handling, is that PSCI is a very well-defined interface between firmware and kernel, while the power domain stuff requires a pretty ad-hoc interface with implicit assumptions between both parts.

16:57 <agx_> marex: no, i'm leaving wifi aside atm so if you have a look that would be cool

16:58 <marex> lynxeye: it still doesn't solve burying the bugs and hacks into the firmware part though

16:58 <marex> lynxeye: also, how is SCFW on MX8Q ? seems like the "you can fix firmware" part isn't such a certainty anymore

16:58 <marex> lynxeye: esp. with BSD-licensed TFA, it definitelly is not

16:59 <lynxeye> that's why we decided to avoid all i.MX8 parts with a SCU like the plague

17:00 <marex> lynxeye: those chips arent going away though

17:00 <lynxeye> fortunately the i.MX8MP has most of the features that our industrial customers are looking for, so we can recommend this on instead

17:00 <marex> lynxeye: its still obsolete CA53, the update to A55 at least would've done it well

17:01 <marex> lynxeye: and all those MX8M chips are ripe for CPU core refresh

17:01 <lynxeye> Oh, I think those chips will go away. At least from my little world-view.

17:01 <marex> lynxeye: so I would be rather worried what is the next industrial/embedded SoC gonna be like

17:01 <marex> lynxeye: but your world-view doesnt matter to big NXP customers I'm afraid :(

17:01 <marex> lynxeye: if they say SCFW is OK, it is here to stay

17:02 <lynxeye> Can you even buy the i.MX8QM if you aren't going to buy like 100k pcs of them?

17:02 <marex> lynxeye: nowadays you already can afaik

17:03 <lynxeye> From what I've heard "okay" was not exactly the feedback they got from their customers on the SCFW ;)

17:03 <marex> I still dont get it with the SCFW though, what is it that they feel they need to hide in there ?

17:03 <marex> lynxeye: was it on the management level or engineering level ?

17:04 <marex> lynxeye: I suspect on the engineering level, the "SCFW is not OK" is pretty unanimous agreement

17:04 <lynxeye> What they need to hide? All the horrors of the actual implementation... Just take a look at the interface "definition" and you know it's just going down from there...

17:04 <marex> lynxeye: and now, remember, TFA is BSD-licensed :-)

17:05 <lynxeye> You can always fork the already open-source parts of the TF-A, nobody is forcing you to use NXPs implementation.

17:06 <marex> lynxeye: for existing SoCs, yes

17:06 <marex> lynxeye: and still, not everything is documented

17:06 <marex> lynxeye: even in existing SoCs

17:06 <lynxeye> ever met a hardware company where everything is documented?

17:07 <marex> lynxeye: yes, I know of a couple

17:07 <lynxeye> In public documentation? Or in NDA stuff you don't get if you tell them that you are going to write GPL software?

17:09 <marex> lynxeye: that was not your original question

17:09 <marex> lynxeye: you did put a highly different spin on that question

17:10 <marex> lynxeye: but I suspect a lot of open hardware companies would have decent documentation and be OK with giving it out ?

17:11 <lynxeye> marex: I would regard the i.MX8Mx reference manuals as "decent", and yet they still lack some crucial parts... ;)

17:12 <marex> lynxeye: I guess that is one way to put it

17:14 <lynxeye> Need to run now. Lets continue this on another occasion. :)

17:28 <DPA> I've 3 problems I've trouble to figure out the cause of. Both only happen with glamor.

17:28 <DPA> 1) With etnaviv+xorg+glamor (and with non-compositing WM), some parts of the screen don't update when they should: https://dpa.li/temp/etna-xorg-glamor.mp4

17:28 <DPA> 3) A prime shared output will stay black.

17:28 <DPA> 2) Rotating the screen will result in a black screen, even if rotating it back, and even if turning the output off and back on with xrandr.

17:28 <DPA> Does anyone know what could cause these thing? Or can anyone give me a hint what I should check / look for?

17:37 <marex> which linux and mesa versions ?

17:38 <DPA> mesa and xorg compiled from git master

17:39 <marex> DPA: in which case, commit ID would help :)

17:40 <DPA> I'll check that one after dinner. But I last updated yesterday.

17:41 <marex> so that should at least contain all the current fixes

18:41 <DPA> I just updated it once more, I'm on 8dc8922af257e454f4460bbc5993df5647968146 now. It didn't change anything though.

18:41 <DPA> Another thing that may be important, to make xorg+glamor to work at all, I have to set ETNA_MESA_DEBUG=nir

21:54 <DPA> There's a very specific configuration in which 1 and 2 seam to mostly work. That is if I enable atomic 2 in xorg on dcss (the external monitor).

21:54 <DPA> The same thing doesn't seam to work on mxsfb, and without atomic v2, I see the same issues on dcss as well.