narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki - ml - Publicly Logged on
<ndufresne> haha, btw, I've build your work from today, works for me too
<ndufresne> Ely, interesting, if I add a queue after the decoder, then it hangs ...
cthugha has joined #linux-amlogic
ldevulder has quit [Ping timeout: 260 seconds]
<ndufresne> Ely, you know what's often annoying with these decoder ...
<ndufresne> Until we get a zero-copy path working, avdec_h264 will likely stay faster, because it does not prevent using the memory cache ...
<ndufresne> * cpu cache
sputnik_ has quit [Remote host closed the connection]
sputnik_ has joined #linux-amlogic
trem has joined #linux-amlogic
yann has joined #linux-amlogic
[TheBug] has quit [Ping timeout: 240 seconds]
[TheBug] has joined #linux-amlogic
indy has quit [Read error: Connection reset by peer]
indy has joined #linux-amlogic
yann has quit [Ping timeout: 256 seconds]
fedux has joined #linux-amlogic
<Ely> ndufresne: can you expand on " if I add a queue after the decoder" ? Not really sure when you queue it.
<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
Elpaulo has quit [Read error: Connection reset by peer]
Elpaulo has joined #linux-amlogic
<Ely> And great, thanks for testing as well. The more testers the merrier.
fedux has quit []
fedux has joined #linux-amlogic
fedux has quit [Client Quit]
yann has joined #linux-amlogic
<TobiasTh1Viking> xdarklight: joy!
<TobiasTh1Viking> got these "c1109880.pinctrl-pinctrl-mesonc8100084.pinctrl-pinctrl-mesonpinctrl-devices pinctrl-handles pinctrl-maps
<xdarklight> TobiasTh1Viking: yay!
<ndufresne> Ely, it hangs quickly if I do something like v4l2video0dec ! queue ! kmssink
<TobiasTh1Viking> network seems stable, to early to tell
<TobiasTh1Viking> xdarklight: <- dmesg
<ndufresne> Ely, in which case downstream of the decoder will hold more buffers, and also that buffers will be returned from a different thread
<ndufresne> thread protection should be guarantied by the videobuf2 though, so that's not an issue
<xdarklight> TobiasTh1Viking: that's without CONFIG_SMSC_PHY right?
<TobiasTh1Viking> i.. don't know.
<TobiasTh1Viking> # CONFIG_SMSC_PHY is not set
<TobiasTh1Viking> yup. not set.
<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
<TobiasTh1Viking> but have addded your patch to dts. can just enable and recompile. had more git stupidness, but it should be painless now.
<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
<TobiasTh1Viking> and network is definetly still unstable. i'll try with CONFIG_SMSC_PHY
<TobiasTh1Viking> wait, it got usb?
<xdarklight> TobiasTh1Viking: can't see USB in your dmesg
<xdarklight> (there would be a dwc2 controller)
<TobiasTh1Viking> ah. oki. i just sawa few usb messages.
<xdarklight> TobiasTh1Viking: can you show me your current .patch?
<TobiasTh1Viking> just a mo
<xdarklight> ok
<xdarklight> are you still working on something or are you ready for the next step? ;)
<TobiasTh1Viking> just a mo
<TobiasTh1Viking> got distracted by wife
<TobiasTh1Viking> well, i intended to try with CONFIG_SMSC_PHY enabled. but apparently it still isn't
<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).
<TobiasTh1Viking> alternatively, finish off pinctrl so it can be merged.
<TobiasTh1Viking> usb would nice, but network seems closer.
<TobiasTh1Viking> xdarklight: what do you say next step is?
<xdarklight> USB requires a clock controller implementation I believe and changes to the PHY driver
<xdarklight> pinctrl sounds good as it will give you SD card support (instead of USB)
<TobiasTh1Viking> oh, i'm an idiot, compiled but, but didn't install it, with smsc_phy
<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
<TobiasTh1Viking> i think there are two required interfaces in pinctrl. for network.
<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.
<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.
<xdarklight> TobiasTh1Viking: yep, the pinctrl driver help a lot. imaging: blinking LEDs ;)
<Ely> ndufresne: The CPU cache with dmabuf, is it by default, or is there a config for it ?
<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
<TobiasTh1Viking> <- partial dmesg with CONFIG_SMSC_PHY enabled. pretty sure miibus is not done in pinctrl.
<TobiasTh1Viking> "replace meson6_pmx_ops with meson8_pmx_ops" not the other way around?
<xdarklight> .pmx_ops = &meson6_pmx_ops, replace that with .pmx_ops = &meson8_pmx_ops,
<xdarklight> this is what I meant
<TobiasTh1Viking> both in aobus and cbus yes?
<xdarklight> yep
<TobiasTh1Viking> making
<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’?
<TobiasTh1Viking> clearly i haven't done something obvious.
* TobiasTh1Viking updates include
<xdarklight> ah, and you need to update the Kconfig statement which selects the PMX_OPS
<TobiasTh1Viking> config PINCTRL_MESON6 -> select PINCTRL_MESON8_PMX in kconfig is fine?
<xdarklight> yep
<xdarklight> it looks weird, if everything works we can rename the whole meson8_pmx... to meson8_pmx... - but let's get it working first :)
<TobiasTh1Viking> for stupid reasons it's recompiling everything.
<TobiasTh1Viking> how hard would the clock driver be? is it tabula rasa, or minor changes from meson8?
<xdarklight> I believe the clock controller is different from Meson8
<xdarklight> so it'll be quite some work
<TobiasTh1Viking> k.
yann has quit [Ping timeout: 256 seconds]
<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)
<TobiasTh1Viking> Generic Droid-TV MX (G18REF) / Gbox Midnight MX2 (MX2REF) / IPTV 18 Pro/GBOX MX2 / Matricom G-Box MX2 Dual Core / Generic E-M6
<TobiasTh1Viking> i have the "IPTV 18 Pro". gbox midnight rip off.
<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 ;)
<TobiasTh1Viking> "Generic E-M6" is nice and.. generic.. Gbox Midnight is what many people would search for.
<TobiasTh1Viking> so, meson-iptv18pro.dts ?
<xdarklight> add a 6 at the end of meson (= meson6) and you're good
<TobiasTh1Viking> k
<TobiasTh1Viking> and disk i was compiling on died. great. :/ oh veal, i'll report back once i have it running
trem has quit [Remote host closed the connection]
yann has joined #linux-amlogic
trem has joined #linux-amlogic
<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_
<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)
Elpaulo has quit [Remote host closed the connection]
Elpaulo has joined #linux-amlogic
<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) :)
Barada has joined #linux-amlogic
Barada has quit [Read error: Connection reset by peer]
commavir has quit [Ping timeout: 256 seconds]
commavir has joined #linux-amlogic
commavir has quit [Ping timeout: 276 seconds]
commavir has joined #linux-amlogic
fedux has joined #linux-amlogic
commavir has quit [Ping timeout: 276 seconds]
fedux has quit []
commavir has joined #linux-amlogic
indy has quit [Quit: ZNC -]
indy has joined #linux-amlogic
trem has quit [Quit: Leaving]
yann has quit [Remote host closed the connection]
<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 :)
<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).
<TobiasTh1Viking> just post dmesg and it will show there (success or failure)?
<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)
<xdarklight> then you just add these two lines inside the uart_AO node and it should work again:
<xdarklight> pinctrl-0 = <&uart_ao_a_pins>;
<xdarklight> pinctrl-names = "default";
vagrantc has joined #linux-amlogic