<beeno>
Can anyone tell me please, does uboot use or activate either the hdmi display or the mali gpu? Or does that only happen from the kernel?
matthias_bgg has quit [Ping timeout: 264 seconds]
matthias_bgg has joined #linux-rockchip
bbelos has quit [Ping timeout: 264 seconds]
bbelos has joined #linux-rockchip
akaizen has quit [Ping timeout: 264 seconds]
andoma has quit [Ping timeout: 264 seconds]
andoma has joined #linux-rockchip
cnxsoft1 has joined #linux-rockchip
cnxsoft has quit [Ping timeout: 240 seconds]
cnxsoft1 is now known as cnxsoft
<wzyy2>
To render 4K frame smoothly, we can only use vop overlay in rk3288 ( In rk3399, RGA can also do it well)
<wzyy2>
Android has HWComposer, where we can handle dmabuf with vop overlay(drm plane) , but there is no such thing on Linux, so currently we render 4k frame in a trick way.
<beeno>
is it possible to play vp8?
<wzyy2>
It have support h264 h265 and vp8
mac-l1 has quit [Ping timeout: 260 seconds]
<wzyy2>
There are many IP in chip can do color conversion and sclae, but rga is certainly the strongest.
<wzyy2>
e.g: If a 4k frame is send to vop to display in 1080p, it will flicker becasue of vop's limition.
<wzyy2>
4k frame should be scaled by RGA to 1080p first.
<rperier>
(when I stress my system with the stress cmdline and I try to play sound with vlc+pulseaudio, sometimes I get this backtrace)
<rperier>
mmind00: I saw that you updated your branch tmp/rk3188-2 for uboot, does the spl start or it's preferable to use the old rockchip spl blob instead? (same technic as described on the barebox website)
cnxsoft has quit [Quit: cnxsoft]
paulk-blaze has joined #linux-rockchip
<wzyy2>
3188 u-boot support? It looks cool.
<wzyy2>
I saw sdram_rk3188.c, so I guess it might use the u-boot spl.
<LongWork>
wzyy2: morning ;à
<LongWork>
would you know what the buffer format is like for the MPP_FMT_YUV420SP_10BIT frame format ?
<LongWork>
i am getting some wierd results when i query teh buffer size and the strides
<LongWork>
so it's unclear what the actual format is
<LongWork>
on a 3840x2160 decoded frame, I am getting a frame which buffer size is 18911232 bytes
<LongWork>
for the following strides : Hstride=4864, Vstride=2160
<LongWork>
the orizontal stride makes me wonder
<LongWork>
usually 10 bits components are stored on 2 bytes
paulk-blaze has quit [Ping timeout: 260 seconds]
BenG83 has quit [Ping timeout: 256 seconds]
<mmind00>
rperier: tpl+spl do start, yet so far the bootrom doesn't want to jump to the full uboot ... one Rockchip guy was able to make this work using some ancient tool, yet we haven't figured out what's causing the hickup
<mmind00>
rperier: so that will still take a bit
cnxsoft has joined #linux-rockchip
<wzyy2>
I think MPP_FMT_YUV420SP_10BIT is NV12_10. I don't know why it's not stored on 2 bytes.
<wzyy2>
There may be a bug here.
<rperier>
mmind00: np, it should still work with the old technic ? (rockchip ddr blob + u-boot mainline)
<mmind00>
rperier: yep, if you look at the mkuboot script in my branch, it actually has commented code for that
paulk-blaze has joined #linux-rockchip
sunxi_fan has quit [Remote host closed the connection]
sunxi_fan has joined #linux-rockchip
lkcl has joined #linux-rockchip
<rperier>
mmind00: super thanks
Klojum has joined #linux-rockchip
<LongWork>
wzyy2: that is what i would have expected, but that looks off
<LongWork>
wzyy2: could you check this with someone who knows ? :)
<phh>
wzyy2 what about vpu's scaling? That way scaling is pipelined and doesn't eat any ram bandwidth
nighty has quit [Quit: Disappears in a puff of smoke]
paulk-blaze has quit [Remote host closed the connection]
paulk-blaze has joined #linux-rockchip
<wzyy2>
phh, VPU scaling look nice, but as far as I know, we didn't use it, perhaps RGA are fast enough to meet demand.
<phh>
weird, perhaps it is too slow or it is buggy
mrjay has joined #linux-rockchip
<wzyy2>
I am also curious, let me ask some colleagues.
<wzyy2>
I think the main reason might be api compatible. You can't find a place for vpu scaling in android framework.
<phh>
oh, makes sense
Klojum has left #linux-rockchip ["Leaving"]
<LongWork>
wzyy2: would your colleagues know about the 10 bits NV12 format thing ? :p
<phh>
LongWork: vcodec and rga2 trm doesn't mention anything 10 bits, vop barely mentions it... the only information I can get is that somewhere somehow there is 128-bit alignments
<LongWork>
usually 10 bits formats refered as P010LE are basically same thing than NV12 but using words for each component
mrjay has quit [Quit: Page closed]
<LongWork>
that is 16 bits per Y, U,V
<wzyy2>
LongWork, you can ask randy, he is familiar with that.
<LongWork>
but that doesn't match the buffer sizes that are in the MppFrames
<LongWork>
wzyy2: yeah i'll send him a mail, even if he's on vaccations :)
<phh>
just for him to come back here
<phh>
+wait
<phh>
LongWork: what's the size you get? w*h*3/2*16?
<phh>
or closer to? w*h*3/2*10?
<phh>
LongWork: I can see that on mali-side it's called MALI_YUV_BT601_WIDE or MALI_YUV_BT709_WIDE, but google doesn't really help
mrjay has joined #linux-rockchip
nighty has joined #linux-rockchip
mrjay has quit [Quit: Page closed]
<LongChair>
@phh , here is some info i can get on the frame :
<LongChair>
- The frame width height which is being set in the frame is 3840x2160 and this looks correct.
<LongChair>
- Regarding the strides what i am getting is Hstride=4864, Vstride=2160
<LongChair>
- buffer size looks strange it is set to 18911232 bytes
<LongChair>
- The frame format is MPP_FMT_YUV420SP_10BIT which is correct
<phh>
ah, sp, ok
<LongChair>
this is what i get when decoding a HEVC Main 10 4K video
<LongChair>
so Hstrides looks like width * 10 / 8
<LongChair>
but it doesnt make real sense
<LongChair>
as no hardware could really use 10 bits data sequences without byte padding
<phh>
well it's not 10, it's 10.3
<LongChair>
10.3 ?
<LongChair>
i assume it's 10 and then some alignement
<phh>
4864*8/3840 = 10.13
<phh>
yes, so there is byte padding :P
<LongChair>
yeah, but on the row size, not on each component size
<phh>
that makes a padding every 7.5 pixel, or every 15 pixels
<LongChair>
usually for a 10 bit Y value, you get that stored in a 16 bits word
<phh>
SP is supposed to stand for single plane?
<LongChair>
yeah
<phh>
the stride and side makes sense only if you get Y
<LongChair>
but doesn't make any diff in terms of data storage :)
<phh>
you're sure you get only one buffer?
<LongChair>
what do you mean ?
<phh>
I mean that U,V could be in other buffers
<phh>
I mean, the Hstride and buffer size is coherent with 10-bits Y, and one padding pixel every 15 pixels, making 160-bits alignment
<LongChair>
that looks pretty wierd in term of standards
<LongChair>
this is usually not how P010LE will be stored
<phh>
how is it usually aligned?
<LongChair>
you'd basically get 3840x2160 * 2 bytes for Y
<LongChair>
and then 3840x2160 /4 * 2 for UV
<phh>
you mean usually?
<LongChair>
that is bsically the same as NV12 , but 16 bits for each component instead of 8
<LongChair>
yeah usually
<phh>
sorry, but we're talking about an embedded systems... with "real life" constraints
<phh>
doing 2 bytes per y does +75% of memory bandwidth
<LongChair>
i mean storing 10 bits components in a row (without 2 bytes alignement per component) looks like a very tricky thing to work with in terms of hw
<phh>
it's much less tricky than being able of doing +75% of memory bandwidth...
<phh>
well it's not really tricky, it just costs a lot
<phh>
(+50% actually)
<LongChair>
I doubt it works like this even on embedded :)
<LongChair>
i think something is wrong in the strides / sizes that are returned by MPP for main 10
<LongChair>
because either ways, then the buffer size is not consistent with the stride :)
<phh>
it is if it's multi-planed
<phh>
so I agree at least one information is wrong
<LongChair>
yeah ... i just need to find out which format is the one actually used :)
<LongChair>
also MPP_FMT_YUV420SP_10BIT is supposed to be single planar ... but who knows :)
<phh>
that's what I meant when I said "at least one information is wrong"
<LongChair>
this is what i'm getting when telling ffmpeg that this is an NV12 (8 bits per component) image and when the buffer is MPP_FMT_YUV420SP_10BIT
<phh>
and you give it the hstride?
<LongChair>
yeah
<phh>
ok, so that's why there is no offsetting, I bet it is missing some part on the right
wzyy2 has quit [Ping timeout: 256 seconds]
<phh>
you can see vertical lines, I'd bet every 16 pixels
<LongChair>
but Hstride * Vstride + width * height would mean that only Y is 10 bits ...
<LongChair>
main 10 is supposed to be 10 bits on each component
<phh>
I agree there is something fishy here
<phh>
LongWork: can you give ffmpeg the offset of the uv plane?
<LongChair>
you can setup all the planes manually if you need
<phh>
that would be the easiest to be sure of the UV 8bits
<LongChair>
each plane start @ can be set in frame->data[i], i being the plane, and each plane stride can be set in frame->linesize[i]
<phh>
I'm not sure what would be the benefit of having U/V only as 8-bits... perhaps time to production
<LongChair>
i have no clue, but there are so many possible combinations .. i'll try to get an official data format from Randy :)
<phh>
LongWork: trying 8-bit uv plane is quite easy
paulk-blaze has quit [Quit: Leaving]
afaerber has joined #linux-rockchip
muvlon_ has joined #linux-rockchip
wzyy2 has joined #linux-rockchip
paulk-collins has joined #linux-rockchip
<LongWork>
wzyy2: do you know if RK3288 supports HDMI-CEC ?
<wzyy2>
According to TRM, it supports HDMI-CEC.
<wzyy2>
But we haven't test it in drm hdmi driver before.
<phh>
wzyy2: do you think you'll be able to check whether asus tinker and asus c201 are properly wired for hdmi cec?
<LongWork>
wzyy2: we have a few dudes at LE atht would be happy to investigate / implement the driver for Tinker
<phh>
LongWork: as I've already said, there is already a driver posted on lkml
<wzyy2>
neither, i think. HDMI driver's owner sites behind me, it seems he haven't do work about CEC.
<wzyy2>
It's no easy to support it by yourself.
<wzyy2>
The HDMI block manual is not allowed to open.
<phh>
wzyy2: it's using the synopsis DesignWave IP right?
<LongWork>
Ofc without support it's hard to do anything :)
<wzyy2>
Yes
<LongWork>
same dudes made the CECE driver for Amlogic S905 chips
<phh>
LongWork: you can look at rockchip 3.10 (3.18? i don't remember) kernel, it does have cec support
<wzyy2>
You'd better ask ASUS if there can let rockchip support it.
<LongWork>
I'll let them handle that :) i have enough with my decoding suff for now :p
<wzyy2>
they can
<LongWork>
ok we'll check that with them then i suppose
<phh>
possibly you'll need to add a reference from hdmi block to clk32k
<phh>
there are two gpios possible for hdmi cec, either gpio7_c0 or gpio7_c7, on tinker gpio7_c7 is busy, so if we assume they did wire hdmi-cec, it would be wired on gpio7_c0, which is standard rockchip configuration
<LongWork>
ok
<LongWork>
i'll forward that info
<phh>
LongWork: fwiw, every time I tried to enable it (either on 3.10 rockchip kernel or on 4.9 mainline + lkml patches), I got memory fault when accessing CEC registers. some guy at rockchip told me at the time it might be linked to clk32k
<phh>
(I didn't investigate further at that time)
cnxsoft has quit [Quit: cnxsoft]
<wzyy2>
sclk_hdmi_cec?
<wzyy2>
phh, could you add it to rk3288_critical_clocks and try lkml patches again?..
<wzyy2>
If it works, I am going to pick those patches on 4.4. :D
mrjay has joined #linux-rockchip
<mrjay>
wzyy2: hi
<mrjay>
i have a question
<mrjay>
do you work for rockchip?
<wzyy2>
mrjay, yes, anything i can help for you?
<mrjay>
i was jut curious :)
muvlon_ has quit [Quit: Leaving]
JohnDoe_71Rus has joined #linux-rockchip
beeno has quit [Ping timeout: 260 seconds]
mrjay has quit [Quit: Page closed]
<rperier>
mmind00: and you're supposed to dd this rock-uboot.bin at seek=64 on your sdcard and that's it? FlashData is not started here :/
<mmind00>
rperier: correct ... did you drop the RK31 from the FlashData before building?
<mmind00>
rperier: uboot adds its own RK31 header of course
<rperier>
mhhh
<rperier>
no I used FlashData directly (extracted from the rockchip spl via rk-split)
<rperier>
that could explain my issue :)
<rperier>
FlashData is started
lkcl has quit [Ping timeout: 258 seconds]
<phh>
wzyy2: that's a no-go on c201, sclk_hdmi_cec's clk_enable_count is 1; the error is "Unhandled fault: impressive external abort (0xac06) at 0xbf000000"
matthias_bgg has quit [Remote host closed the connection]
lkcl has joined #linux-rockchip
lkcl has quit [Ping timeout: 240 seconds]
Omegamoon has left #linux-rockchip [#linux-rockchip]