<wens>
JohnDoe_71Rus: as I said, the SDM code only has parameters for certain rates. you need to add one for 49.152
<wens>
Jookia: ^
<Jookia>
i'll have a try tomorrow
<Jookia>
but the rates aren't exact in the clock tree summary so it's upsetting the i2s driver
<Jookia>
at least, that's what i think is happening
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
<fraolt>
Jookia: Have you tried enabling clk tracing, e.g. by using boot parameter trace_event=clk:*? You'd get detailed tracing of what the CCF is doing.
<Jookia>
i'll give that a shot. i didn't want to break out my serial cable to deal with u-boot, but oh well
<jernej>
I could easily test NV12 linear output, but I don't have setup for tiled NV12
machinehum has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
KREYREN__ has quit []
KREYREN_oftc has joined #linux-sunxi
<KREYREN_oftc>
https://dpaste.com/B6WQL6PYA.txt does anyone know what kernel configuration is needed to get the display to work on OLIMEX Teres-I or AllWinner A64 in general?
<KREYREN_oftc>
gamiee, working on tiny kernel bcs the distro kernels are huge and pain to develop on top of
<f_>
Hi gamiee
<gamiee>
Hi f_
<gamiee>
KREYREN_oftc : Be sure that for e.g. CONFIG_FB is enabled
<gamiee>
Also assure ANX6345 driver to be also enabled (if there is any, I don't know)
<KREYREN_oftc>
gamiee, these are enabled already but no display in u-boot phase
<gamiee>
you asked about kernel, not about u-boot
rzr has quit [Quit: WeeChat 3.8]
<KREYREN_oftc>
the u-boot phase is a framebuffer and there is no display in userland and initrd either
<KREYREN_oftc>
so the working theory -> Fix u-boot frame buffer -> fix everything else
<gamiee>
nope
dsimic is now known as Guest14059
dsimic has joined #linux-sunxi
<gamiee>
(as far as I know)
<gamiee>
From what I know/remember, both u-boot and kernel are initializing the DPI core separately. so if you get display output working on u-boot, it might not work on Linux. (unless there is some pass to the Linux, but I am not aware)
Guest14059 has quit [Ping timeout: 480 seconds]
<KREYREN_oftc>
yes but the display has an initialization sequence and even that those are initialized separtely they both use the same calls so it's still a valid approach afaik
<KREYREN_oftc>
and even then i need the display work in both cases eventually
<gamiee>
yeaah, that's what I said. It will needed to be properly configured on both sides.
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
<apritzel>
on the A64 we support simple framebuffer, which allows to pass on an enabled display from U-Boot to the kernel
<apritzel>
but this was somewhat of a kludge we used in the beginning, until we got proper DRM support for the A64 DE
<apritzel>
and conceptually both U-Boot and the kernel should be independent in terms of display enablement
<apritzel>
so you don't need a working U-Boot display for kernel graphics
<apritzel>
that's actually the reality for R40, H6, and later, where we don't have U-Boot graphics support at all
<apritzel>
KREYREN_oftc: do you have CONFIG_DRM_ANALOGIX_ANX6345?
<MoeIcenowy>
gamiee: if the kernel's reset of the graphics hardware is not full, thus it's a bug worth reporting.
<apritzel>
gamiee: V85x mainlining: not that I would be aware of, there is little going on in terms of SoC upstreaming
<MoeIcenowy>
oops my V853 board has been dusted
<MoeIcenowy>
for years
<MoeIcenowy>
I got it before I moved to current apartment, which is @ 2022-7
<MoeIcenowy>
apritzel: I think this should be included in mainline Linux T113 DT
<MoeIcenowy>
not only U-Boot
<apritzel>
according to smaeul that's not the plan
<apritzel>
firmware decides which WDT to use, and that's what U-Boot does
warpme has joined #linux-sunxi
<MoeIcenowy>
well I don't think adding it to T113 dt do not affect RISC-V
<MoeIcenowy>
s/don't/do/
<apritzel>
I don't see what this has to do with RISC-V vs ARM?
<apritzel>
and it's another reason to ditch that idea of loading a DTB alongside the kernel
<apritzel>
smaeul had some good rationale back then to not put that into the mainline T113s3 .dtsi
Hypfer is now known as Guest14068
Hypfer has joined #linux-sunxi
Guest14068 has quit [Ping timeout: 480 seconds]
<apritzel>
gamiee: Do you have an interest or good reasons for v85x mainlining?
<apritzel>
I mean it's quite some work, and requires some persistence, so doing that "just because" is typically not going to work
machinehum has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
machinehum has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
<wens>
Jookia: you can also enable tracing at runtime through tracefs, no need for U-boot
machinehum has quit [Ping timeout: 480 seconds]
<gamiee>
apritzel: nothing exact yet, I was just curious if there was anything done for it yet, since I remember MoeIcenowy did some stuff for V5 some time ago.
apritzel has joined #linux-sunxi
<Jookia>
wens: but wouldn't the clocks get set up too early for me to set it?
<wens>
IIRC asoc only requests the clock rate when you setup the play or capture formats
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
<paulk>
jernej: neat! I'll take a look yep
<paulk>
(about the jpeg dec work)
ftg has joined #linux-sunxi
<jernej>
paulk: I think I discover one subtle issue in Cedrus driver. When multiple codecs are supported in one engine, like MPEG2 and JPEG in this case, very first thing you need to do after enabling engine is to select which subengine you'll use.
<jernej>
I suspect that is the issue I see when switching between VP8 and H264
<jernej>
and another thing, there is more advanced JPEG decoding support in Cedrus, it has engine number 6
<paulk>
jernej: honestly I'm considering whether we should just issue a VE reset (not reset line but internal reset)
<paulk>
I do it on h264, the blob does it too and it doesn't take time
machinehum has quit [Ping timeout: 480 seconds]
<paulk>
(h264 enc)
<paulk>
very good to know about jpeg!
<jernej>
ah, no, that won't work, jpeg decoding didn't work until I select subengine first and only then filled registers
<jernej>
some registers are shared, so it might trigger wrong path if correct subengine is not selected
<paulk>
mhh I see
linkmauve has joined #linux-sunxi
warpme has quit []
warpme has joined #linux-sunxi
<jernej>
paulk: what is the plan with your refactoring? I would like to see Cedrus destaged
wigyori has quit [Remote host closed the connection]
<linkmauve>
jernej, it works even with ST12!!!
<linkmauve>
I just tested outputting to DRM. :)
<linkmauve>
The chroma plane is twice as high as it should when the input JPEG is 4:4:4 though.
<linkmauve>
But with a 4:2:0 JPEG it renders perfectly. :)
<linkmauve>
Probably some missing register telling the engine to also force 420 for the chroma plane.
machinehum has joined #linux-sunxi
<linkmauve>
I’ve tested on A10 atm, will test on A20 and A64 in a bit.
<linkmauve>
So this secondary output is for the chroma plane? Why do other engines not use it?
<jernej>
linkmauve: I'm glad it works for you
<linkmauve>
Does that mean we could eventually support NM12, or is it still limited to very close physical addresses?
<jernej>
I tried to write de-tiler in python, but it didn't work for chroma. however, grayscale was perfect, so I assumed it works
<linkmauve>
jernej, I’ll finish to wire it up properly in onix, and will push an updated branch so you can test it too.
<linkmauve>
I’d rather use DRM, then I know (or at least hope that) it’s implemented properly. :)
<jernej>
secondary output is for scaling and rotating video, or in HEVC case, for transforming from internal 10-bit format to P010
<linkmauve>
Ah, so for instance for JPEG with metadata saying it should be rotated?
<jernej>
JPEG is exception - for some reason it always outputs to secondary output
<linkmauve>
How does that mix with actual scaling and rotating?
<jernej>
scaling is set to 1 and rotating to 0 deg
<linkmauve>
What are the constraints of said scaling btw, can it be used for generating thumbnails at lower cost?
machinehum has quit [Ping timeout: 480 seconds]
<jernej>
that's the idea, yes, but only for 1/1, 1/2, 1/4 and 1/8 sizes. Rotation is in 90 deg steps
<linkmauve>
Build it with --example=jpeg-drm, otherwise same command as last time.
vagrantc has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
<linkmauve>
Ah, we also don’t support grayscale JPEGs at all currently.
<linkmauve>
Those have only one component.
<jernej>
I think I saw somewhere special handling of output for tiled NV12 when JPEG is 4:4:4, but I can't find it ATM
<jernej>
you can easily add it to that switch, but I have no idea what the result will be
<linkmauve>
Ah, that would be useful!
<apritzel>
what's the purpose of hardware JPEG decoding? Is it for MJPEG only, or are there other use cases? These days it does not sound worth to jump through a lot of hoops when you can do software decoding more easily?
<linkmauve>
In onix I specialise in image formats, currently WebP and JPEG, and soon AVIF as well.
<linkmauve>
All three are decoded in hardware, so that the CPU can do other things in the meantime.
<jernej>
apritzel: for me, it was just a challenge :) and I learned some quirks of Cedrus in the process
<linkmauve>
On a single core CPU like the A10, it makes sense to offload as much as possible to the hardware.
<linkmauve>
On more powerful SoCs, I would expect hardware decoding to be either faster or more energy efficient or both.
<linkmauve>
At least for VP8 it is the case even on the A64 of my phone.
<apritzel>
well, I see that, and for video I totally understand, but I wonder how useful it is for just a single image
<apritzel>
especially if that won't be available everywhere
<apritzel>
but "just for the challenge of it" is a good enough explanation
<linkmauve>
On my phone, generating a gallery for all of the JPEGs in my Pictures directory is very slow, as well as displaying a single image in eog or in loupe.
<linkmauve>
It can take as long as two seconds to switch between images.
<apritzel>
ah, OK, thumbnailing hundreds of pictures, that makes sense
<linkmauve>
That time isn’t spent only decoding the pictures, but also converting from YUV to RGB, scaling, and stuff, but still.
warpme has quit []
<jernej>
apritzel: based on documentation, it seems that it was meant for MJPEG, e.g. streams where each frame is composed of JPEG image. So it will still be more efficient than by using CPU.
<linkmauve>
The main issue atm is when images are in different resolutions, userspace needs to tear down and restart the whole decoding process due to how the V4L2 API works atm.
<jernej>
yeah, everything is optimized towards video decoding, not still pictures
<apritzel>
that's what I was thinking: if you just want to display a single picture, then relying on some kernel driver and creating the right environment for the driver and everything might not be worth it, if you can just use libjpeg-turbo
<linkmauve>
It’s never just one still picture, you will usually encounter more of them later on.
<linkmauve>
And again on my phone, the camera application always saves the pictures at the same resolution, so at least in that case it will only be an issue when images have been rotated.
<apritzel>
yeah, on a phone it makes sense: here you have tons of pictures that you cycle through, and you care about battery
<linkmauve>
I’ve been thinking about grayscale decoding, V4L2_PIX_FMT_GREY would probably be the wanted capture format, but I don’t know if the buffers would still have to be allocated for the hardware to write undefined chroma data or not.
<jernej>
yeah, so I'm not sure if it's supported at all
<jernej>
but I'm sure grayscale is supported on separate engine, AW named that jpegplus
<jernej>
oh, maybe that's copy & paste issue from there
<jernej>
some code is shared
<linkmauve>
Do you already have some ideas of what that other engine supports?
<linkmauve>
Is it shared with the encoding engine?
<jernej>
no, it's separate, standalone engine for jpeg decoding
machinehum has joined #linux-sunxi
<jernej>
there is no sharing between encoding and decoding engines
<jernej>
only thing that poped out for me was grayscale and tiling support
<jernej>
not sure what tiles are in JPEG context
<linkmauve>
Tiling as in… yeah I was gonna ask. ^^'
<jernej>
linkmauve: btw, I think V4L2 will get support for switching sizes on the fly relatively soon. It's needed for VP9 and other codecs.
<linkmauve>
Yeah, I remember ndufresne talking about it. :)
machinehum has quit [Ping timeout: 480 seconds]
warpme has quit []
<jernej>
linkmauve: maybe it's jpeg2000? it supports tiles
<linkmauve>
Oh wow, I wouldn’t expect that codec, but you never know!
<jernej>
it would make sense also because instead of DCT it uses wavelets, so it can't share MPEG engine
<linkmauve>
Yeah.
machinehum has joined #linux-sunxi
warpme has joined #linux-sunxi
KREYREN_oftc has quit [Remote host closed the connection]
KREYREN_oftc has joined #linux-sunxi
wigyori has joined #linux-sunxi
<jernej>
linkmauve: can you try without setting force 420 bit with tiled NV12 and 4:4:4 jpeg on older soc?
<jernej>
that bit isn't present in older sources
<linkmauve>
jernej, it has the exact same rendering.
<linkmauve>
So that’s probably why it gets “ignored”.
<linkmauve>
Although that doesn’t explain everything, I would expect the chroma plane to have a twice larger width as well as a twice higher height.
<linkmauve>
Since that’s the difference between 4:4:4 and 4:2:0.
<jernej>
I guess you have to play with different variants and find out how it works
machinehum has quit [Ping timeout: 480 seconds]
warpme has quit []
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]
ftg has joined #linux-sunxi
Hypfer is now known as Guest14108
Guest14108 has quit [Read error: No route to host]
Hypfer has joined #linux-sunxi
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
<KREYREN_oftc>
<apritzel> KREYREN_oftc: do you have CONFIG_DRM_ANALOGIX_ANX6345? -- Yes
<KREYREN_oftc>
<MoeIcenowy> gamiee: if the kernel's reset of the graphics hardware is not full, thus it's a bug worth reporting. -- it's on tiny kernel configuration
<KREYREN_oftc>
well set in .config the linux kernel will add some things
<KREYREN_oftc>
bcs i want basically bare minimum linux kernel config for the device that only gives me display wifi BLE, terminal, UART and Battery drivers
apritzel has joined #linux-sunxi
machinehum has joined #linux-sunxi
aperezdc has quit [Ping timeout: 480 seconds]
machinehum has quit [Ping timeout: 480 seconds]
aperezdc has joined #linux-sunxi
aperezdc is now known as Guest14117
ftg has quit [Read error: Connection reset by peer]