00:36 <ndufresne> haha, btw, I've build your work from today, works for me too

00:41 <ndufresne> Ely, interesting, if I add a queue after the decoder, then it hangs ...

02:05 <ndufresne> Ely, you know what's often annoying with these decoder ...

02:06 <ndufresne> Until we get a zero-copy path working, avdec_h264 will likely stay faster, because it does not prevent using the memory cache ...

02:06 <ndufresne> * cpu cache

10:02 <Ely> ndufresne: can you expand on " if I add a queue after the decoder" ? Not really sure when you queue it.

10:03 <Ely> ndufresne: Yeah I remember a long time ago hacking into videobuf2 to specifically enable read cache on my buffers. I wonder if since then maybe some options has made it into it

10:12 <Ely> And great, thanks for testing as well. The more testers the merrier.

13:16 <TobiasTh1Viking> xdarklight: joy!

13:17 <TobiasTh1Viking> got these "c1109880.pinctrl-pinctrl-mesonc8100084.pinctrl-pinctrl-mesonpinctrl-devices pinctrl-handles pinctrl-maps

13:17 <xdarklight> TobiasTh1Viking: yay!

13:17 <ndufresne> Ely, it hangs quickly if I do something like v4l2video0dec ! queue ! kmssink

13:17 <TobiasTh1Viking> network seems stable, to early to tell

13:17 <TobiasTh1Viking> xdarklight: https://pastebin.com/37na1VSW <- dmesg

13:18 <ndufresne> Ely, in which case downstream of the decoder will hold more buffers, and also that buffers will be returned from a different thread

13:18 <ndufresne> thread protection should be guarantied by the videobuf2 though, so that's not an issue

13:18 <xdarklight> TobiasTh1Viking: that's without CONFIG_SMSC_PHY right?

13:19 <TobiasTh1Viking> i.. don't know.

13:19 <TobiasTh1Viking> # CONFIG_SMSC_PHY is not set

13:19 <TobiasTh1Viking> yup. not set.

13:19 <ndufresne> Ely, V4L2 never enables cache on CMA memory, in fact, we could now do that whenever we have DMABuf, since we can use the being/end_cpu_access calls for that

13:20 <TobiasTh1Viking> but have addded your patch to dts. can just enable and recompile. had more git stupidness, but it should be painless now.

13:20 <ndufresne> Ely, though, in 1.12, what you are testing is non-dmabuf, you'd have to enabled it explicitly on the decoder with capture-io-mode=dmabuf, in 1.14, it's always dmabuf being exported

13:21 <TobiasTh1Viking> and network is definetly still unstable. i'll try with CONFIG_SMSC_PHY

13:22 <TobiasTh1Viking> wait, it got usb?

13:22 <xdarklight> TobiasTh1Viking: can't see USB in your dmesg

13:22 <xdarklight> (there would be a dwc2 controller)

13:22 <TobiasTh1Viking> ah. oki. i just sawa few usb messages.

13:27 <xdarklight> TobiasTh1Viking: can you show me your current .patch?

13:29 <TobiasTh1Viking> just a mo

13:33 <TobiasTh1Viking> https://pastebin.com/pXnVuzzf

13:34 <xdarklight> ok

13:34 <xdarklight> are you still working on something or are you ready for the next step? ;)

13:39 <TobiasTh1Viking> just a mo

14:29 <TobiasTh1Viking> got distracted by wife

14:30 <TobiasTh1Viking> well, i intended to try with CONFIG_SMSC_PHY enabled. but apparently it still isn't

14:31 <TobiasTh1Viking> as for working for something, i see two things that make sense. "stable/working network". so it can just run 24/7 on mainline(and default to mainline, using 3.10 for fallback only).

14:31 <TobiasTh1Viking> alternatively, finish off pinctrl so it can be merged.

14:32 <TobiasTh1Viking> usb would nice, but network seems closer.

14:32 <TobiasTh1Viking> xdarklight: what do you say next step is?

14:32 <xdarklight> USB requires a clock controller implementation I believe and changes to the PHY driver

14:32 <xdarklight> pinctrl sounds good as it will give you SD card support (instead of USB)

14:33 <TobiasTh1Viking> oh, i'm an idiot, compiled but, but didn't install it, with smsc_phy

14:33 <xdarklight> I'm not sure how much you need to do for network, but I believe you need both, a pinctrl driver and a clock driver

14:34 <TobiasTh1Viking> i think there are two required interfaces in pinctrl. for network.

14:34 <TobiasTh1Viking> really, i would be fine with just polishing that bit up. to mark it done in matrix. even if it doesn't improve networking in and off itself. it will still be foundation for a lot.

14:34 <Ely> ndufresne: Alright I'll try to replicate and see what's going on. Right now I'm remodeling the driver but I'll get to that next step.

14:35 <xdarklight> TobiasTh1Viking: yep, the pinctrl driver help a lot. imaging: blinking LEDs ;)

14:35 <Ely> ndufresne: The CPU cache with dmabuf, is it by default, or is there a config for it ?

14:36 <xdarklight> TobiasTh1Viking: as next step I suggest you replace meson6_pmx_ops with meson8_pmx_ops (I believe there's no pinmux ops change between Meson6 and Meson8) and see if anything breaks

14:37 <TobiasTh1Viking> https://pastebin.com/y49g895v <- partial dmesg with CONFIG_SMSC_PHY enabled. pretty sure miibus is not done in pinctrl.

14:37 <TobiasTh1Viking> "replace meson6_pmx_ops with meson8_pmx_ops" not the other way around?

14:38 <xdarklight> .pmx_ops = &meson6_pmx_ops, replace that with .pmx_ops = &meson8_pmx_ops,

14:38 <xdarklight> this is what I meant

14:39 <TobiasTh1Viking> both in aobus and cbus yes?

14:39 <xdarklight> yep

14:41 <TobiasTh1Viking> making

14:44 <TobiasTh1Viking> drivers/pinctrl/meson/pinctrl-meson6.c:1299:14: error: ‘meson8_pmx_ops’ undeclared here (not in a function); did you mean ‘meson6_pmx_ops’?

14:44 <TobiasTh1Viking> clearly i haven't done something obvious.

14:45 <xdarklight> ah, and you need to update the Kconfig statement which selects the PMX_OPS

14:46 <TobiasTh1Viking> config PINCTRL_MESON6 -> select PINCTRL_MESON8_PMX in kconfig is fine?

14:47 <xdarklight> yep

14:47 <xdarklight> it looks weird, if everything works we can rename the whole meson8_pmx... to meson8_pmx... - but let's get it working first :)

15:07 <TobiasTh1Viking> for stupid reasons it's recompiling everything.

15:07 <TobiasTh1Viking> how hard would the clock driver be? is it tabula rasa, or minor changes from meson8?

15:08 <xdarklight> I believe the clock controller is different from Meson8

15:08 <xdarklight> so it'll be quite some work

15:09 <TobiasTh1Viking> k.

15:28 <TobiasTh1Viking> xdarklight: what's an appropriate name for my dts file? There are a lot of boards almost exactly like this. in general i see the board called g18ref/mx2ref (or g18mx2)

15:28 <TobiasTh1Viking> Generic Droid-TV MX (G18REF) / Gbox Midnight MX2 (MX2REF) / IPTV 18 Pro/GBOX MX2 / Matricom G-Box MX2 Dual Core / Generic E-M6

15:29 <TobiasTh1Viking> i have the "IPTV 18 Pro". gbox midnight rip off.

15:29 <xdarklight> TobiasTh1Viking: I use the "marketing name" by which I've bought it. similar designs might be similar but not identical, so let's take care of those later ;)

15:29 <TobiasTh1Viking> "Generic E-M6" is nice and.. generic.. Gbox Midnight is what many people would search for.

15:30 <TobiasTh1Viking> so, meson-iptv18pro.dts ?

15:31 <xdarklight> add a 6 at the end of meson (= meson6) and you're good

15:31 <TobiasTh1Viking> k

15:52 <TobiasTh1Viking> and disk i was compiling on died. great. :/ oh veal, i'll report back once i have it running

17:03 <xdarklight> jbrunet: I had another go at the Meson8 / Meson8b CPU frequency scaling issue and I *believe* to have found the cause: the notifier is called right before and right after the SYS PLL clock is changed. the problem here seems to be that there are still changes to the children of SYS PLL afterwards which can cause a lockup. I'm trying to implement this as separate clock (clk_ops) now which changes the parent to XTAL first, then calls clk_

17:03 <xdarklight> set_rate on the actual clock -> seems to work fine for now (although I have no idea if we the clk maintainers will like this)

17:58 <xdarklight> jbrunet: I'll prepare and RFC patch in the next few days and send it. so far CPU frequency scaling works fine on Meson8m2 (will test on Meson8b later) :)

21:28 <xdarklight> jbrunet: I ran "stress -c 4" (which generates 100% CPU load on each core) infinitely in background and a script which cycles through all possible CPU frequencies for ~4 hours. no problems found :)

21:55 <TobiasTh1Viking> about to hit the sack. but compile just finished. any specific way i should expect the ".pmx_ops = &meson6_pmx_ops, replace that with .pmx_ops = &meson8_pmx_ops," rename to fail (if it does fail).

21:55 <TobiasTh1Viking> just post dmesg and it will show there (success or failure)?

21:58 <xdarklight> if the pinctrl framework disables unused pins by default you should see that the serial console stops at some point (or does not even come up)

21:58 <xdarklight> then you just add these two lines inside the uart_AO node and it should work again:

21:58 <xdarklight> pinctrl-0 = <&uart_ao_a_pins>;

21:58 <xdarklight> pinctrl-names = "default";