<Ely>
I'm not 100% sure but by the looks of it, they added MMUs for the vdecs starting with GXL
<Ely>
yikes
tingoose has joined #linux-amlogic
<tingoose>
Hello
<tingoose>
Is it possible to reliably run USB port in OTG mode with mainline kernels for odroid-c2 (meson-gxbb) ?
<tingoose>
g_ether/g_multi module was either failing to initialize, or failing to connect properly to the host
Xogium has joined #linux-amlogic
lp0-on-fire has quit [Read error: Connection reset by peer]
<narmstrong>
tingoose: no
<gab>
tingoose: do you have this working with amlogic kernel ?
<tingoose>
I haven't tested it with amlogic kernel. I do use old yocto kernel recipes (from meta-odroid). It was using old kernel from hardkernel, and worked fine for us.
<narmstrong>
hardkernel kernel is a hacked amlogic kernel
<tingoose>
I've tried several times to run it on 4.14 kernel, but with no good success
<gab>
ok, so 3.14 or 4.9 ?
<narmstrong>
tingoose: USB support is severely weird, it needs some hacking to support device mode
<gab>
I've been trying to make it work with 4.9 but couldn't yet
<tingoose>
Live was good with 3.14. Now I realy want to move to mainline stuff
<gab>
also documentation about that is a bit sparse :p
<tingoose>
But that USB issue completely blocks this upgrade
<gab>
(I'm not on c2, but khadas vim2, which I guess should work more or less the same)
<narmstrong>
gab: ha ha, no...
<gab>
oh ?
<narmstrong>
gab: they changed it in a different weird stuff
<narmstrong>
gab: but it could work on mainline
<tingoose>
Do you know, how much work should there be done to make it work for specific kernel branch?
<gab>
narmstrong: by any chance would you have a pointer to some documentation about that ? my basis currently is just a khadas android nougat rom based on amlogic 3.14 that happens to have adb working, but I can't figure exactly what makes it work
<gab>
been fiddling with configfs to no avail...
<tingoose>
For example if I wanted to pay this strong guy to finally fix this stuff
<narmstrong>
gab: to resume : they left a Device-Only USB2 controller connected to the first port, and added an USB3 controller configure to do only USB2 Host controlling all the ports, and an USB3 PHY (!!!) get the OTG switch info who will need to switch the first USB2 PHY to get Device working
<narmstrong>
gab: @xdarklight did a very good work finding all this
Xogium has quit [Read error: Connection reset by peer]
<gab>
ok
<narmstrong>
but no docs at all
<gab>
well I'm not on mainline yet :)
<gab>
currently I'm on a amlogic 4.9.76 (forked from 150balbes's github repo)
<gab>
but ultimately when xdarklight's patches get mainlined I'll definitely try it
<gab>
so basically, what you're saying is OTG will only work with amlogic's 3.14, not 4.9 ?
<gab>
(or am I misunderstanding ?)
<narmstrong>
it should work on amlogic kernels
Xogium has joined #linux-amlogic
<gab>
ok
<gab>
so my configfs black voodoo script is wrong
<gab>
that stuff is so cryptic
<tingoose>
narmstrong: do you know anyone, who could make it work for mainline? Even through durtiest hackiest hacks?
<gab>
and I'm getting tired of grepping android rc scripts :D
<narmstrong>
tingoose: yes, but time is lacking !
<tingoose>
how much could it cost?
<narmstrong>
tingoose: it's for a commercial project ?
<tingoose>
yep, we have a bunch of odroid-based stuff here
<gab>
hm... it seems the configfs and /sys/ stuff to enable device mode are quite different between 3.14 and 4.9
<gab>
on the 3.14 android ROM there's /sys/class/android_usb/android0/enable (and other props) + /sys/class/dual_role/, while they're missing from 4.9
<gab>
(at least with my kernel config)
<gab>
oh
<gab>
missing CONFIG_DUAL_ROLE_USB_INTF :p
<gab>
something else's missing :/
<gab>
not dual_role thing, but /sys/class/android_usb/android0/enable definitely makes it work on 3.14
<narmstrong>
gab: because it's an android overpatched kernel !
<gab>
guess so
<gab>
but I guess the khadas-4.9 is too
brujah has quit [Ping timeout: 248 seconds]
brujah has joined #linux-amlogic
Elpaulo_m has joined #linux-amlogic
<gab>
yes, found it
<gab>
needed controller-type = <2> in dwc2_a section of the dtb
Elpaulo_m2 has quit [Ping timeout: 248 seconds]
Elpaulo_m2 has joined #linux-amlogic
Elpaulo_m has quit [Ping timeout: 248 seconds]
dsd_ has joined #linux-amlogic
<narmstrong>
xdarklight: I pushed s set of patches to support USB Host on GXL on U-boot, could you have a try and R-b/T-b the patches if you find some time ?
sputnik_ has quit [Remote host closed the connection]
chewitt has joined #linux-amlogic
tingoose has quit [Ping timeout: 276 seconds]
Elpaulo_m has quit [Ping timeout: 260 seconds]
Elpaulo_m has joined #linux-amlogic
Elpaulo_m2 has joined #linux-amlogic
Elpaulo_m has quit [Ping timeout: 264 seconds]
Elpaulo_m2 has quit [Ping timeout: 248 seconds]
Elpaulo_m has joined #linux-amlogic
<Ely>
got h.264 on gxl!
<Ely>
ndufresne: With your commands, kmssink will overwrite the screen over hdmi or something ? How does this work ?
<ndufresne>
Ely, kmssink is a bit ancient already, it's implement legacy drm, it will look for an overlay at first, on a configured CRTC
<ndufresne>
If not found, it will look at the configure primary, ortherwise it will try and configure the first primary plane it finds on the first CRTC / Encoder
<ndufresne>
like any drm/kms thing, it's a bit of a trial and error process, but it's super fast
<Ely>
So worst case it overwrites the primary plane that usually displays X11 ?
<Ely>
or should I not run X11 ?
<ndufresne>
if X11 runs, then it will fail, because there is only 1 master
<Ely>
I see
<Ely>
so I have to disable X11 and then I should be able to output video via kmssink then with meson drm
<ndufresne>
kind of, the video is in NV21-ish, and we don't yet have overlay support with this format
<ndufresne>
so I'd add, v4l2h264dec ! videoconvert n-threads=4 ! kmssink
<ndufresne>
narmstrong, does the drm driver scales or not ?
Elpaulo_m has quit [Ping timeout: 248 seconds]
Elpaulo_m2 has joined #linux-amlogic
<ndufresne>
Ely, meanwhile, if you are in X11, you can just do ! videoconvert ! videoscale ! ximagesink
<Ely>
Alright thanks. I'll setup gstreamer and see what comes out.. :D
<narmstrong>
ndufresne: not yet
<narmstrong>
Ely: great !
<narmstrong>
! videoconvert ! videoscale ! kmssink would work no ?
<ndufresne>
yes, for FHD though add n-threads=4, so the color conversion is multi-threaded
<ndufresne>
ideally if no scaling is needed, it will be smoother
<ndufresne>
narmstrong, I've only tested videotestsrc ! kmssink so far, but it should work
<ndufresne>
narmstrong, does the driver supports sub regions, e.g. displaying 720p on 1080p display ?
<ndufresne>
Ely, all this is just to say that you might need force-modesetting=1 and can-scale=0
<ndufresne>
when kmssink get ported to atomic APIs, we will be able to figure things out better
<narmstrong>
ndufresne: not yet !
<ndufresne>
ok, then force-modesettings will be needed
vagrantc has joined #linux-amlogic
<Ely>
ndufresne: okay thanks. Where do these variables go ?
<Ely>
narmstrong: the meson-drm layer freezes for a long time at boot, and then I get those:
<Ely>
[ 32.025443] ------------[ cut here ]------------
<Ely>
[ 31.969447] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:32:meson_primary_plane] flip_done timed out
<Ely>
[ 21.729447] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:28:Composite-1] flip_done timed out
<Ely>
11.489452] [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:33:meson_crtc] flip_done timed out
<Ely>
[ 32.025445] [CRTC:33:meson_crtc] vblank wait timed out
<Ely>
is this expected ?
<narmstrong>
Ely: you have an hdmi monitor connected ?
<Ely>
yup
<narmstrong>
Ely: which kernel did you take ?
<Ely>
4.16-rc7 so not bleeding edge
<narmstrong>
It should be ok
<Ely>
I'm fairly certain the monitor is 1366 x 768 and I saw some commits of yours adding some resolutions a few days ago
<Ely>
can this be an issue ?
<narmstrong>
Sure, this patch will be for 4.17, apply it
<narmstrong>
But composite should still work...
brujah has quit [Ping timeout: 256 seconds]
<Ely>
nevermind, seems to be me adding the vdec that messes things up
<Ely>
most likely the pwrc also accessing AO_RTI_GEN_PWR_SLEEP0 or smthing
<narmstrong>
Maybe, when you’ll push your code I’ll have a look
tingoose has joined #linux-amlogic
<Ely>
the probes don't happen simulteanously so I don't know what's happening :<
<Ely>
I'll tidy up and push this evening
brujah has joined #linux-amlogic
<ndufresne>
Ely, they go onto kmssink, gst-inspect-1.0 kmssink for more details ;-P
brujah has quit [Ping timeout: 264 seconds]
<ndufresne>
narmstrong, is there USB OTG on Le Potato ?
<narmstrong>
ndufresne: no
<ndufresne>
ok, nommage ;-P
<narmstrong>
But the otg capable port is hooked to a type A port and by forcing device mode and using a a-to-a cable you could do it
<narmstrong>
At your own risks !
mchappellier has quit []
<ndufresne>
hmm ...
<narmstrong>
Amlogic uses this to flash devices in fab
<ndufresne>
I think i'll just go by myself a network switch
<ndufresne>
* buy
<narmstrong>
May be simpler yes :-)
<ndufresne>
the FXI Cotton Candy was like this too iirc
<ndufresne>
my dev setup was a single USB cable to my laptop
<ndufresne>
for now I just want to be able to access it remotly, for quick tests as needed
<ndufresne>
it's hook to an HDMI capture device, so I can even see what's going no
<ndufresne>
I'm also interested in turning off the flashing blue led
<Ely>
you mean all of them right ? They're so bright..
Elpaulo_m2 has quit [Read error: Connection reset by peer]
Elpaulo_m has joined #linux-amlogic
TobiasTh1Viking has joined #linux-amlogic
<TobiasTh1Viking>
herro, is there anyone here who can help with making meson6 pinctrl work? i have partly made unworking patches. should just need a few pointers.
<TobiasTh1Viking>
i have a pinctrl-meson6.c with obviously missing/wrong stuff. but done everything in it i could figure out how to do.
<xdarklight>
TobiasTh1Viking: "don't ask to ask, just ask" - is there a github repo with your patches somewhere?
<TobiasTh1Viking>
i posted it to pastebin, if that's acceptable. i
<TobiasTh1Viking>
i posted it to pastebin, if that's acceptable. i'll set up a github for future.
<TobiasTh1Viking>
bah, pastebins got deleted. have to repaste them. is ok on pastebin? (5 files)
Elpaulo_m2 has joined #linux-amlogic
<xdarklight>
can you do "git diff HEAD > meson6-pinctrl.patch" and post the whole patch (should make it easier)
afaerber has quit [Quit: Leaving]
Elpaulo_m has quit [Ping timeout: 276 seconds]
<TobiasTh1Viking>
bah, not experienced with git.. i think i have to add my files first. just a mo.
<TobiasTh1Viking>
there is a lot of comments (mine, code i didn't know how to convert from meson8 properly, from meson6 documentation. )
<TobiasTh1Viking>
pinctrl-meson6.c <- static struct meson_bank meson6_cbus_banks[] is incomplete, multiple banks missing.(not sure how to add them).
<TobiasTh1Viking>
searching for "TODO" should give good indicator of what i know is not done.
<TobiasTh1Viking>
i'll rebase of head for every new iteration of patches i do.
Elpaulo_m has joined #linux-amlogic
<TobiasTh1Viking>
Oh, bank b. has fec<->phy link i don't know how to setup, but getting that done might make network working well on the aml8726-mx.
Elpaulo_m2 has quit [Ping timeout: 276 seconds]
<TobiasTh1Viking>
xdarklight: any pointers?
<xdarklight>
TobiasTh1Viking: let me have a look now
<Ely>
narmstrong: It's pushed, when you get a minute to try it out :). There's still the "vdec kills vpu" bug at boot though, haven't figured it out.
<xdarklight>
TobiasTh1Viking: I would start small with only the ao-bank code. first thing I notice: meson6_aobus_groups seems to be missing GPIOAO_8, 9 and 10
<xdarklight>
you converted uart_tx_ao_a and uart_rx_ao_a correctly based on the 3.10 kernel data - however there is a hack in the 3.10 kernel which maps register "10" to AO register 0. instead of GROUP(uart_tx_ao_a,10,12), you should use register 0 here (the mainline drivers don't need the 3.10 kernel hack): GROUP(uart_tx_ao_a,0,12),
<TobiasTh1Viking>
does that go for all "10, " in meson6_aobus_groups?
<TobiasTh1Viking>
honestly, i can't even confirm that my pinctrl gets loaded in the kernel. not sure where to add a debug statement to check.
<narmstrong>
Ely: thx I’ll look at it !
<xdarklight>
TobiasTh1Viking: yep, replace all "10, " in meson6_aobus_groups with "0, "
<TobiasTh1Viking>
done.
<xdarklight>
TobiasTh1Viking: ok, let me look up the io regions now so your driver gets loaded (we need to add it to meson6.dtsi)
<TobiasTh1Viking>
oh, so it never loaded. heh. great.
<TobiasTh1Viking>
looking at arch/arm/boot/dts/meson8b.dtsi didn't make me wiser in regard to loading that. some magic numbers i don't understand. why @84. and are gpio ranges correct from that file?
<TobiasTh1Viking>
i can just try with that copied.
<xdarklight>
see the TODOs, you still need to set the correct number of GPIOs
<TobiasTh1Viking>
yeah, didn't know how (hence why i made the todo).
<xdarklight>
TobiasTh1Viking: in the .dts file you set the number of pads (GPIOs), not the number of pinmux functions. assuming GPIOAO goes from 0 to 11 plus TEST_N then you'll set "13" (0..11 = 12 + TEST_N = 13) for the gpioao controller node
Xogium has left #linux-amlogic ["leaving channel"]
<TobiasTh1Viking>
so, updated dts. is next step recompile and try?
<xdarklight>
by 4, then you'll get the numbers in that header file. for example (from cbus): 0x8030 / 4 = 0x200c -> this is PREG_PAD_GPIO0_EN_N for both, Meson8 and Meson6
<xdarklight>
TobiasTh1Viking: yeah, go ahead and try it
<TobiasTh1Viking>
dmesg | grep pinctrl should give me something if it loads at all, yes?
<xdarklight>
at least /sys/kernel/debug/pinctrl should show it
Barada has joined #linux-amlogic
* TobiasTh1Viking
is trying to parse the last few sentences.
<TobiasTh1Viking>
i get 173 cbus pins
<TobiasTh1Viking>
10 for aobus, assuming i have test. though it goes to 11. 0-7,11 are the ao pins.
<xdarklight>
TobiasTh1Viking: for cbus I get 175: 36 pins in GPIOX, 28 in GPIOA, 24 in GPIOB, 16 in GPIOC, 10 in GPIOD, 9 in GPIOE, 15 in GPIOY, 13 in GPIOZ, 6 in CARD and 18 in BOOT
<xdarklight>
TobiasTh1Viking: warning: your definitions are missing GPIOC_14 ;)
<xdarklight>
(your code has MESON_PIN(GPIOC_13) and right after that MESON_PIN(GPIOC_15))
<TobiasTh1Viking>
so i should change 120 to 175 in your patch?
<xdarklight>
yep
<xdarklight>
(and please add a line with MESON_PIN(GPIOC_14) to the driver)
<TobiasTh1Viking>
just a mo, not sure it was in 3.10 code.
<TobiasTh1Viking>
it is, i missed it
sputnik_ has joined #linux-amlogic
<xdarklight>
ok
<xdarklight>
TobiasTh1Viking: back to the aobus pinctrl: similar question there: are you sure GPIOAO_8, 9 and 10 are missing?
<TobiasTh1Viking>
was doing a lot of grep'ing. i will double check holes (there are probably more)
<xdarklight>
TobiasTh1Viking: ok, with the pin numbers updated - what do you get during boot? :)
<TobiasTh1Viking>
question, in meson6-gpio.h, how much does it matter that the number is counting correctly? ( i will obviously make it very nice for final patch
<TobiasTh1Viking>
)
<xdarklight>
it's important that all GPIOs within a group are consecutive (you can't have GPIOX_0 = 0, GPIOY_0 = 1, GPIOX_1 = 2, ...)
<xdarklight>
as these map to the struct meson_bank (which only supports consecutive numbering by default)
<TobiasTh1Viking>
oki. will need to fix that then.
<xdarklight>
also there shouldn't be any gaps in the numbering
<TobiasTh1Viking>
i saw gaps in original (due to faulty greping)
<TobiasTh1Viking>
fixing now
Barada has quit [Quit: Barada]
<TobiasTh1Viking>
a bit much work. i'll report back once it is fixed and based on linux-next isntead of 4.15, hopefully tomorrow
<TobiasTh1Viking>
thanks
sputnik_ has quit [Remote host closed the connection]