narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki http://linux-meson.com/ - ml linux-amlogic@lists.infradead.org - Publicly Logged on https://irclog.whitequark.org/linux-amlogic
steamport is now known as steamport|sleep
cthugha has joined #linux-amlogic
ldevulder has quit [Ping timeout: 260 seconds]
nashpa has quit [Ping timeout: 276 seconds]
nashpa has joined #linux-amlogic
dlan has quit [Ping timeout: 248 seconds]
dlan has joined #linux-amlogic
dlan has joined #linux-amlogic
dlan has quit [Changing host]
Elpaulo_m2 has joined #linux-amlogic
Elpaulo_m has quit [Ping timeout: 276 seconds]
Elpaulo_m has joined #linux-amlogic
Elpaulo_m2 has quit [Ping timeout: 240 seconds]
Barada has joined #linux-amlogic
cthugha is now known as ldevulder
a5m has joined #linux-amlogic
brujah has quit [Ping timeout: 276 seconds]
brujah has joined #linux-amlogic
fedux has joined #linux-amlogic
fedux has quit []
Elpaulo_m2 has joined #linux-amlogic
Elpaulo_m has quit [Ping timeout: 264 seconds]
afaerber has joined #linux-amlogic
Barada has quit [Ping timeout: 248 seconds]
mchappellier has joined #linux-amlogic
Barada has joined #linux-amlogic
<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 ?
<narmstrong> I will need more unmerged patches to work, but you can take this tree https://github.com/superna9999/u-boot/tree/u-boot/topic/gxl-usb-merge
Elpaulo_m has joined #linux-amlogic
Elpaulo_m2 has quit [Ping timeout: 276 seconds]
Elpaulo_m2 has joined #linux-amlogic
Elpaulo_m has quit [Ping timeout: 245 seconds]
Elpaulo_m has joined #linux-amlogic
Elpaulo_m2 has quit [Ping timeout: 264 seconds]
Elpaulo_m2 has joined #linux-amlogic
Elpaulo_m has quit [Ping timeout: 256 seconds]
Elpaulo_m has joined #linux-amlogic
Elpaulo_m2 has quit [Ping timeout: 268 seconds]
Elpaulo_m2 has joined #linux-amlogic
a5m has quit [Remote host closed the connection]
Elpaulo_m has quit [Ping timeout: 240 seconds]
Elpaulo_m2 has quit [Ping timeout: 246 seconds]
Elpaulo_m has joined #linux-amlogic
shadeslayer has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
Barada has quit [Quit: Barada]
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..
<ndufresne> all of them would be even better
<Ely> blue one you can do
<Ely> echo 0 > /sys/class/leds/librecomputer:blue/brightness
<Ely> green one is /sys/class/leds/librecomputer:system-status
<Ely> red one I don't think you can
tingoose has quit [Ping timeout: 256 seconds]
<Ely> most likely hardwired to the power
<Ely> (at least on mainline, no idea with amlogic kernels)
Xogium has left #linux-amlogic ["leaving channel"]
brujah has joined #linux-amlogic
Xogium has joined #linux-amlogic
<ndufresne> thanks !
<chewitt> ndufresne: find the heartbeat entry for the LED and remove the line, set to " default-state = "off"; "
<ndufresne> thanks
tingoose has joined #linux-amlogic
trem has joined #linux-amlogic
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> https://pastebin.com/xd2CN0q2 <- should be it
<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> TobiasTh1Viking: (I'll use this as reference from now on: https://github.com/endlessm/linux-meson/blob/master/arch/arm/mach-meson6/gpio_data.c )
<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> TobiasTh1Viking: https://pastebin.com/9V0Td12D can you add that to meson6.dtsi
<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?
<TobiasTh1Viking> or more we should try first?
<xdarklight> TobiasTh1Viking: regarding the "reg" numbers: I compared https://github.com/endlessm/linux-meson/blob/c173f4653186870f08dc9131b5d82ef4ab4151e1/arch/arm/mach-meson6/include/mach/register.h vs https://github.com/endlessm/linux-meson/blob/c173f4653186870f08dc9131b5d82ef4ab4151e1/arch/arm/mach-meson8b/include/mach/register.h - unfortunately these numbers are different than in the .dts file: take the number from the .dts file and divide it
<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]
fedux has joined #linux-amlogic
sputnik_ has joined #linux-amlogic
dsd_ has quit [Quit: Lost terminal]
trem has quit [Quit: Leaving]
tingoose has quit [Ping timeout: 260 seconds]
mag has quit [Quit: Bye]
fedux has quit []
mag has joined #linux-amlogic
vagrantc has quit [Quit: leaving]