Danct12 has quit [Remote host closed the connection]
junari has joined #linux-sunxi
warpme has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
warpme has quit []
mps has quit [Quit: leaving]
warpme has joined #linux-sunxi
warpme has quit []
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
mps has joined #linux-sunxi
apritzel has joined #linux-sunxi
warpme has joined #linux-sunxi
junari_ has joined #linux-sunxi
junari has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
kuba2k2 has joined #linux-sunxi
Jookia has joined #linux-sunxi
<Jookia>
can someone explain the reset process for linux?
<Jookia>
i'm finding that mainline does not reset the t113 but a random kernel i have does (maybe the tina one?) but i can't determine why
Danct12 has joined #linux-sunxi
<jernej>
Jookia: reset failure can have different reasons. For example, check that voltage regulator for SD, eMMC or whatever you have, has "regulator-always-on;", otherwise kernel will disable it and BROM won't be able to load SPL.
<Jookia>
no i mean on reboot, the kernel literally says rebooting failed
<Jookia>
i think something's up with the watchdog reset functionality in mainline
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-sunxi
<Jookia>
also mainline doesn't bring up both t113 cpus :(
<jernej>
oh, so you have to update U-Boot, since Linux for AW nowadays relies on PSCI to manage cores
<Jookia>
i don't have u-boot
<Jookia>
only awboot
<jernej>
well, U-Boot installs PSCI service
<Jookia>
on the t113?
<jernej>
for most 32-bit AW SoCs
<jernej>
and surely for all new ones
JohnDoe_71Rus has quit []
<Jookia>
i don't see any psci references in the device tree for this chip
<Jookia>
there's also no official u-boot port for it yet
<Jookia>
so a little doubt :)
kuba2k2 has quit [Ping timeout: 480 seconds]
Danct12 has quit [Read error: Connection reset by peer]
<Jookia>
ah! the board dts i'm using enables the watchdog. problem solved
<jernej>
be aware that bootloaders can and often do modify DT on the fly
<jernej>
and if you don't see anything in Linux tree DT source, doesn't mean it's not used
kuba2k2 has joined #linux-sunxi
<Jookia>
oh yes i know :) this was my bad porting a board to mainline
<jernej>
you still probably have only single core, right?
<Jookia>
yes, i need to port across the code to set the cores up
Danct12 has quit [Remote host closed the connection]
<apritzel>
Jookia: hope that helps, if you have any questions or comments, feel free to respond on the mailing list
apritzel has quit [Ping timeout: 480 seconds]
junari_ has quit [Ping timeout: 480 seconds]
<Jookia>
the kernel doesn't use psci afaik so it won't work for me
<Jookia>
i wish i did but i don't have the patience to glue together patches that aren't even in someone's git tree
<Jookia>
it's a lot easier to just handle it in the kernel for this
<Jookia>
i'm just a bit salty here over people not sharing their code :)
Danct12 has joined #linux-sunxi
<jernej>
Jookia: why kernel wouldn't use PSCI?
<Jookia>
jernej: it needs a device tree node or something doesn't it?
<jernej>
U-Boot injects DT with "enable-method = "psci"" to each core
<Jookia>
ah
<jernej>
that's why I make that comment before
<jernej>
*made
<Jookia>
i reaaally don't want to use psci though
<jernej>
your call, but you'll have to patch kernel forever then
<Jookia>
it's either patch kernel or patch u-boot :\
<jernej>
for now
<Jookia>
i would be much more open to using a fork or something of u-boot that just works as a base
<jernej>
what is your beef with U-Boot?
<Jookia>
there's no support for this soc or variant that has support
<jernej>
apritzel pointed you to the branch which will eventually land
<Jookia>
it doesn't have psci
<jernej>
yeah, add the patch that you find it on the ML
<Jookia>
i'll pass on that for now
<jernej>
you won't avoid patching either way
<Jookia>
i know, but i would rather patch something in a way i understand and can debug
<Jookia>
if i'm going through the pain of patching and debugging software i might as well do it the easiest way
<jernej>
I'm actually surprised that someone bothered with arch/arm/mach-sunxi/platsmp.c
<Jookia>
i think it's the linux tina code from allwinner that does it
<jernej>
yeah, but that probably doesn't translate directly to mainline
<Jookia>
yeah i will probably have to work on it a bit :\
<Jookia>
either that or try running an allwinner kernel on u-boot, but that's a nightmare
<jernej>
why would be a nightmare? do you have some special dev setup?
<jernej>
it's genuine question, because I didn't yet found any big issue with it and I develop U-Boot and Linux drivers
<Jookia>
basically no software or patch i've ever used has worked first try and i've had to debug it or ask for help, and in this case the help/issue tracker is a single email thread on a website
<Jookia>
(this assumes people will help you)
<Jookia>
i assume the allwinner kernel is going to try and access something privileged and then crash
<Jookia>
AFAIK nobody has ever published a full working image of u-boot+linux on the t113, just patches, not even git trees
wasutton3 has quit []
wasutton3 has joined #linux-sunxi
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
<Jookia>
... Though the patches aren't magically going to fix themselves unless someone reports them not working. Which would be me
<Jookia>
and prolonging testing the patches won't make them better anyway, especially if they're merged broken
apritzel has joined #linux-sunxi
<Jookia>
I guess if I'm going to be troubleshooting patches I might as well troubleshoot patches that other people are going to use :|
kuba2k2 has quit [Ping timeout: 480 seconds]
wasutton3 has quit [Ping timeout: 480 seconds]
DarkNeutrino has quit [Ping timeout: 480 seconds]
DarkNeutrino has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<apritzel>
Jookia: yes, and those other patches have no future
<apritzel>
the neat thing about using PSCI is that you don't need kernel patches, because that's generic and already built in for ages
<Jookia>
apritzel: is this semi-finalized and planned for merge soonish?
<apritzel>
Jookia: yes, exactly. The U-Boot merge window opens in about a month, and unless someone screams, it should go in then
<Jookia>
given my luck i'll be screaming then :)
sunshavi_ has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
kuba2k2 has joined #linux-sunxi
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-sunxi
warpme has quit []
junari_ has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
warpme has quit []
vagrantc has joined #linux-sunxi
warpme has joined #linux-sunxi
mps has quit [Quit: leaving]
ftg has joined #linux-sunxi
warpme has quit []
apritzel has joined #linux-sunxi
<linkmauve>
Hi, I’m on an A64, and I’m wondering why there is no ALLWINNER_TILED modifier support in any of the DRM planes on this SoC.
<linkmauve>
On an A10 I do have this modifier available for all of the NV* formats.
<linkmauve>
The video decoder is able to emit a ST12 buffer from a VP8 frame, so I assume the display controller must be able to take it.
warpme has joined #linux-sunxi
<linkmauve>
This is a PinePhone I’m testing on, if this is any useful.
<linkmauve>
Also when I try to import one such NV12 buffers having been exported from V4L2, I get this error as a result of DRM_IOCTL_MODE_SETPLANE:
<jernej>
linkmauve: tiled formats are supported only on DE1, while A64 has DE2
<jernej>
AW removed support for tiled formats in DE2 and newer, but also introduced support for linear formats in Cedrus
<jernej>
latest Cedrus should prefer linear formats over tiled, but you can change this at any time
junari__ has joined #linux-sunxi
<linkmauve>
Thanks for the info. :)
<linkmauve>
I already support both formats, but I didn’t know about the preference.
<linkmauve>
In which case does ST12 still make sense, for EGL import?
<jernej>
ST12 is tiled format, I presume?
<linkmauve>
Yes, it’s NV12 + ALLWINNER_TILED.
<linkmauve>
At least that’s what I translate it to on the A10.
<jernej>
it makes sense only on DE1 SoCs when rendering directly using DRM planes
<linkmauve>
(Possibly the A20 as well, but I haven’t tested yet.)
<jernej>
afaik mesa doesn't know about this format
<linkmauve>
Ok, so it being still exposed is a legacy artifact on A64 and newer.
<linkmauve>
(In V4L2.)
<linkmauve>
jernej, in Mesa I would import it as one R8 image and one GR88 image.
<linkmauve>
And do the render to RGB in the shader.
<jernej>
it's exposed because HW supports it, but it's not of much use on A64
<jernej>
I meat native import, without need for custom shaders
<linkmauve>
Makes sense, thanks. :)
<linkmauve>
Do you have any clue why a normal linear NV12 buffer would fail to DRM_IOCTL_MODE_SETPLANE on A64?
<linkmauve>
The V4L2 decode went fine, so did the ADDFB2.
junari_ has quit [Ping timeout: 480 seconds]
<jernej>
did you set it to the right plane? only one supports that format
<linkmauve>
D’uh, that was it. I was trying to display on the primary plane.
<linkmauve>
Do I then need to stop the primary plane from displaying?
<linkmauve>
Unsetting the fb is enough to achieve that?
<jernej>
depends how it's set up
<linkmauve>
Or perhaps just making it get a zpos above the primary plane.
<linkmauve>
-it+the overlay plane
<jernej>
in Kodi GBM mode, primary plane is either hidden or has format with alpha channel, so overlay can be made
<linkmauve>
Yay, I have a garbled blinking image! \o/
<linkmauve>
Totally unrecognizable! \o/
<linkmauve>
Doesn’t matter which image I decoded, it still renders badly.
<jernej>
in any case, I suggest that you leave VI plane (VI planes support RGB and YUV formats) at the bottom and just manage primary plane (which is UI plane and support RGB only)
mps has joined #linux-sunxi
<linkmauve>
Heh, disabling the primary plane led to a kernel oops about [CRTC:49:crtc-0] vblank wait timed out
<jernej>
which kernel are you using?
<jernej>
recent kernels should have fix for decoupling primary planes from mode sets
<linkmauve>
It still looks like that, as if the pitch was completely wrong somehow.
<jernej>
first, are you sure v4l2 correctly decodes video? second, are you sure you properly export dmabuf from v4l2 and import it to drm?
<linkmauve>
It returns the right image when I mmap() it and then write() to a file, and then display it on my laptop with mpv --demuxer=rawvideo --demuxer-rawvideo-w=1920 --demuxer-rawvideo-h=1088 --demuxer-rawvideo-mp-format=nv12 output.nv12
<linkmauve>
As for the export, I use VIDIOC_EXPBUF and then DRM_IOCTL_PRIME_FD_TO_HANDLE and then split it into two planes for ADDFB2.
<jernej>
that seems fine
<jernej>
btw, note that Cedrus may adjust output size, to be multiple of 16 or something, due to HW restrictions
<jernej>
so make sure you report right dimensions to DRM
evgeny_boger has joined #linux-sunxi
<linkmauve>
Yup, hence the --demuxer-rawvideo-h=1088 in mpv, but the proper offset in the planes.
<linkmauve>
But if I didn’t compute it correctly it would still be a different artifact I think, such as the colour looking off.
<linkmauve>
For a 720×1440 image it shouldn’t be padded at all.
evgeny_boger1 has joined #linux-sunxi
<jernej>
what's your parameters?
<jernej>
I can double check
evgeny_boger has quit [Ping timeout: 480 seconds]
evgeny_boger1 has quit [Ping timeout: 480 seconds]
Danct12 has quit [Remote host closed the connection]
<jernej>
looks fine
Danct12 has joined #linux-sunxi
<linkmauve>
It’s fine to set the same handle twice right? To only extract the GEM handle from the fd once and pass it twice.
kuba2k2 has quit [Ping timeout: 480 seconds]
<linkmauve>
“18:11:08 jernej> in Kodi GBM mode, primary plane is either hidden or has format with alpha channel, so overlay can be made”, how do you hide it? Passing None as its fb disables vsync handling and seems to cause a mess: https://linkmauve.fr/files/sun4i-drm-2.txt
<linkmauve>
Would it be better to put the overlay on top, and leave whatever the fbdev emulation left in the primary plane behind?
<jernej>
I think fbdev uses XR24
kuba2k2 has joined #linux-sunxi
<jernej>
oh, did you preset VI plane size, location and scaling?
<linkmauve>
How do I do that?
<linkmauve>
The one fbdev leaves me should already be set to their correct values I think.