ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
ynezz has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
montjoie has joined #linux-sunxi
montjoie_ has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
vagrantc has quit [Quit: leaving]
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
KREYREN__ has quit [Remote host closed the connection]
KREYREN__ has joined #linux-sunxi
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
machinehum has joined #linux-sunxi
JohnDoe_71Rus has quit []
JohnDoe_71Rus has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has quit []
JohnDoe_71Rus has joined #linux-sunxi
Net147_ has quit []
Net147 has joined #linux-sunxi
JohnDoe_71Rus has quit []
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit []
JohnDoe_71Rus has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.1.3 Quasar http://www.kvirc.net/]
JohnDoe_71Rus has joined #linux-sunxi
<JohnDoe_71Rus> hi
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
<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
ftg has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
warpme has joined #linux-sunxi
apritzel has joined #linux-sunxi
machinehum has joined #linux-sunxi
<jernej> paulk, linkmauve: please test this code for JPEG decoding: https://github.com/jernejsk/linux-1/commits/jpeg/
<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> the system has the A64 connected to the ANX6345 bridge that handles the eDP https://i.imgur.com/j73aaJd.png
<KREYREN_oftc> powerup sequence https://i.imgur.com/yatOW8w.png
machinehum has joined #linux-sunxi
* KREYREN_oftc found
<KREYREN_oftc> which doesn't have A64 hmm
machinehum has quit [Ping timeout: 480 seconds]
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
<gamiee> huh kreyren<
<gamiee> ?
<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.
<MoeIcenowy> apritzel: btw ping for the status = "okay" for t113 wdt mentioned at https://oftc.irclog.whitequark.org/linux-sunxi/2023-06-16
<MoeIcenowy> one of my friend asked me about this when doing sth for t113
<gamiee> MoeIcenowy: I did not encountered this, but good to know, thanks.
<gamiee> MoeIcenowy (and others): Is there any ongoing effort about V85X mainlining?
<apritzel> MoeIcenowy: we fix this up in U-Boot, and that's mainline already: https://source.denx.de/u-boot/u-boot/-/commit/95168d77d391b1464af9f99ca44a2e46f309c32e
warpme has quit []
<apritzel> if it's that what you mean?
<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
<jernej> and flips
<linkmauve> Ok, makes sense.
<linkmauve> If you want a 4:4:4 picture for testing, I’ve been using this one: https://linkmauve.fr/files/1920×1080.jpeg
<jernej> ok, let's see
<jernej> linkmauve: with NV12, it decodes perfectly to 4:2:0 format
<linkmauve> Hmm, so maybe that’s a bug in the A10 that has been fixed on newer SoCs which support NV12 in addition to ST12?
<jernej> I have no setup currently to test NV12_32L32
<jernej> let me check something
<linkmauve> I’ve pushed a new version of https://git.linkmauve.fr/onix.git branch jpeg-decoder which adds the jpeg-drm example.
machinehum has joined #linux-sunxi
<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> can you give me some grayscale jpeg?
<linkmauve> % jpegtran -grayscale 1920×1080.jpeg > grayscale.jpeg
apritzel has quit [Ping timeout: 480 seconds]
<jernej> quick hack didn't work
<jernej> not sure if it's supported or not. old AW code has support for it in code, but it doesn't seem to work
<linkmauve> Hmm…
<jernej> although you can try http://sprunge.us/O474Il on older socs
<jernej> second chunk may or may not be needed
machinehum has joined #linux-sunxi
<linkmauve> Is that supposed to leave undefined data in the chroma parts of the buffer?
<jernej> I have no idea
<jernej> I mean, it shouldn't be undefined
warpme has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]
<linkmauve> No, the output is fully zero-green.
<jernej> so same as on A64
<jernej> eh, sorry, on H6
<jernej> but A64 should behave the same
JohnDoe_71Rus has quit [Quit: KVIrc 5.1.3 Quasar http://www.kvirc.net/]
<linkmauve> This is still on A10.
<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> this is all that is set https://dpaste.com/FVNYN6G3F.txt
<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]
machinehum has joined #linux-sunxi
machinehum has quit [Ping timeout: 480 seconds]