<ndufresne>
Ely, we'll have to study drivers/amlogic/amports/vmh264.c (the multi-instance variant for H264)
<ndufresne>
I bet this is only on GXL+
<ndufresne>
it seems like with that we can do 12 decoding instances in parallel
<ndufresne>
I doubt it's real-time, but much more flexible for userspace
<ndufresne>
and this one has a lof of if (!mmu_enable)
<ndufresne>
interesting, this is a totally different codec, it can decoder in I420
cthugha has joined #linux-amlogic
default__ has quit [Ping timeout: 248 seconds]
commavir has quit [Remote host closed the connection]
commavir has joined #linux-amlogic
commavir has quit [Remote host closed the connection]
commavir has joined #linux-amlogic
commavir has quit [Remote host closed the connection]
commavir has joined #linux-amlogic
commavir has quit [Remote host closed the connection]
commavir has joined #linux-amlogic
steamport is now known as steamport|sleep
vagrantc has quit [Quit: leaving]
distemper has quit [Quit: bye]
distemper has joined #linux-amlogic
distemper has quit [Quit: bye]
distemper has joined #linux-amlogic
distemper has quit [Client Quit]
distemper has joined #linux-amlogic
Barada has joined #linux-amlogic
Elpaulo_m has joined #linux-amlogic
Barada has quit [Quit: Barada]
Barada has joined #linux-amlogic
<narmstrong>
Beware, they have the same « plenty of alternative paths/registers » but they may not have all HW actually in the silicon, for instance they can have 3 different scalers for vpu primary plane, only one is actually present... having the driver does not mean it’s actually present and working ! The 4.9 branch may be more representative of what is actually in HW
trem has joined #linux-amlogic
tingoose has joined #linux-amlogic
Elpaulo_m2 has joined #linux-amlogic
Elpaulo_m has quit [Ping timeout: 255 seconds]
<Ely>
ndufresne: Yes I studied the multi decoders briefly but I don't have much intel on it.
<Ely>
I can't find any trace of "mmu_enable" in 3.14/4.9 vmh264 driver though
<TobiasTh1Viking>
xdarklight: i have some time :)
<Ely>
ndufresne: for hevc, vh265.c bundles both the single and multi driver (amvdec_h265_driver, ammvdec_h265_driver)
<xdarklight>
TobiasTh1Viking: then let's go :)
<TobiasTh1Viking>
we are hooking up meson6_cbus_banks yes?
<xdarklight>
let's start with the aobus pins
<xdarklight>
(it'll be easier, but cbus follows the same schema)
<xdarklight>
.name is easy, it's the name of the bank (any name you want in theory, we typically go with the letters in the GPIO name, "A", "X", ...)
<TobiasTh1Viking>
is open. i feel like i kinda understand it. (playing a bit with arduino's seem to overlap a bit)
<TobiasTh1Viking>
still, not enough to manage on my own.
<xdarklight>
.first and .last are the first and last GPIO in the bank
<xdarklight>
example from Meson8 so far: BANK("CARD", CARD_0, CARD_6, ...
<xdarklight>
after that there's always a pair of register offset and bit offset in this register for: REG_PULLEN, REG_PULL, REG_DIR, REG_OUT, REG_IN
<TobiasTh1Viking>
specifically that is where i feel like i'm lacking some knowledge.
<xdarklight>
the meanings of these registers (I might be wrong for some, but you'll get the basic idea): REG_DIR = direction of the pin (input or output)
<xdarklight>
REG_OUT = if the pin is an output pin then this defines if it should output HIGH or LOW
<xdarklight>
REG_IN = if the pin is an input pin you can read the value (HIGH or LOW)
<TobiasTh1Viking>
and what about PULLEN/PULL?
<xdarklight>
REG_PULL = defines whether pull up or pull downs are enabled
<xdarklight>
or wait, that might be REG_PULLEN
<Ely>
ndufresne: From the looks of it, it looks like >= GXTVBB can do H.264 4K on the regular driver. Will have to test :)
<xdarklight>
TobiasTh1Viking: hmm, one defines if the pin is in pull up or pull down mode, then the other defines if the whole pull-* logic is enabled at all
<TobiasTh1Viking>
so, some of this data i already have (first/last pin). but the register and bit offset. and irq's. i'll have too look that up somewhere. yes? is it in the 3.10 source for me to locate?
<xdarklight>
yep, that is the next step :)
<xdarklight>
one more hint (that I find important): the REG_* values always specify the register and bit offset of the *first* pin in a bank
<TobiasTh1Viking>
ok
<xdarklight>
so let's keep going with the Meson8 example: direction register = 0 direction bit = 22
<xdarklight>
this means that CARD_0 will use register 0 and bit 22, CARD_1 will use register 0 and bit 23, ...
<TobiasTh1Viking>
ok. i'm not good with registers. but makes sense.
<TobiasTh1Viking>
for reference, you said we should do the meson6_aobus_banks. which only has BANK("AO", GPIOAO_0, GPIO_TEST_N, everything else is in cbus bank
<TobiasTh1Viking>
so, that's first and last pin?
<TobiasTh1Viking>
oh, AOMAP, has more values.
<xdarklight>
let's start with what you have: BANK("AO", GPIOAO_0, GPIO_TEST_N,
<xdarklight>
that looks good so far, now we need to fill the remaining values
<xdarklight>
for the two IRQ fields you can go with -1 for now, they're not used by the pinctrl driver yet
<TobiasTh1Viking>
sorry, i have some confusion, let me reread
<TobiasTh1Viking>
i think i'm just being confused by the comment block. it says "irq" once. but there are two irq variables.
<xdarklight>
ah yes, it's actual comment should be "irq first" and "irq last"
<TobiasTh1Viking>
good.
<TobiasTh1Viking>
changing from 0, 13 to -1, -1
<xdarklight>
yep
<Ely>
ndufresne: haha yup, H.264 4K works on GXL out of the box with the current driver. Decoding happens at 24-25fps
<TobiasTh1Viking>
xdarklight: so, now i need to parse register and bit from the "PIN_AOMAP" yes?
<xdarklight>
TobiasTh1Viking: yep, I'm slightly confused currently since the 3.10 kernel doesn't give the PULL* offsets. let's fill these with -1 for now (we'll set them later)
<TobiasTh1Viking>
done
<xdarklight>
next is the "direction" register and bit
<xdarklight>
check gpio_amlogic_direction_input and gpio_amlogic_direction_output in the 3.10 kernel, they use the "out_en_reg_bit" struct member to configure the direction
<TobiasTh1Viking>
define PIN_AOMAP(pin,en_reg,en_bit,out_reg,out_bit,in_reg,in_bit) <- seems to be what i need. yes?
<xdarklight>
yep
<TobiasTh1Viking>
en_reg,en_bit <- pullen?
<TobiasTh1Viking>
en(able)
<xdarklight>
no, they're for the direction register
<xdarklight>
REG_DIR
<xdarklight>
(REG_DIR in the mainline kernel code)
<TobiasTh1Viking>
oh wait, i could see that later in code.
<TobiasTh1Viking>
ok, let me try
<TobiasTh1Viking>
so, dir, in and out, all use register 7. bit 0 for dir and in. bit 16 for out. ?
<xdarklight>
the register offsets (7 in case of the AO bank) in the 3.10 kernel are going through some lookup table (p_gpio_oen_addr)
<xdarklight>
index 7 ends up in the P_AO_GPIO_O_EN_N register, which in mainline register offsets is simply 0
<xdarklight>
(amlogic's driver only uses one pinctrl devicetree node for both, AOBUS and CBUS - but the mainline drivers are much cleaner: they use one devicetree node per controller, each with the "correct" base addresses already specified in devicetree)
trem_ has joined #linux-amlogic
<xdarklight>
it's a bit weird, not sure if you understand my (aim at an) explanation
<TobiasTh1Viking>
a bit too much info i don't know where to fit. i'll reread all of this a couple of times. i'm not sure if you gave me all the data needed for fill out the pullen and pull values. if you did you need to be a bit more specific.
<TobiasTh1Viking>
hopefully i'll catch up
<TobiasTh1Viking>
in p_gpio_oen_addr in 3.10, i find aobus at 7. not 0. :/
trem has quit [Ping timeout: 246 seconds]
<xdarklight>
ok, for pull and pullen I'll rephrase:
<xdarklight>
pullen -> use same register and bit offset as for "direction"
<xdarklight>
pull -> use same register and bit offset as for "out"
<TobiasTh1Viking>
ah. oki.
<TobiasTh1Viking>
for now it just feels like black magic numbers. but i'll sure i'll get it later.
<xdarklight>
regarding P_AO_GPIO_O_EN_N
<TobiasTh1Viking>
so besides for irq. everything is 7,0, or 7,16
<xdarklight>
in this case you can take the values 1:1 :)
<TobiasTh1Viking>
why 1:1?
<xdarklight>
the GPIO numbers in the Amlogic driver are identical with the GPIO numbers
<xdarklight>
sorry, GPIO numbers are identical with the IRQ numbers
<xdarklight>
^that's what I wanted to say
<TobiasTh1Viking>
doesn't it say 182
<xdarklight>
yep
<xdarklight>
that's where the mainline driver differs from Amlogic's driver
<xdarklight>
mainline: each pin controller starts counting the GPIO at 0, Amlogic: they count the overall pins in the order that some chip designer has defined
<TobiasTh1Viking>
oh. so because AO is on its own pinctrl devicetree, it becomes 1:1 ?
<xdarklight>
it'll be the same for CBUS: the IRQ numbers are always the ones from that gpio.h file
<TobiasTh1Viking>
still kinda confused. what would the irq be for, lets say card and boot?
<xdarklight>
CARD_0=121 (that would be irq start)
<xdarklight>
CARD_8=129 (that would be irq end)
<TobiasTh1Viking>
so, just 121 and 129, no conversion needed?
<xdarklight>
indeed
<TobiasTh1Viking>
only AO needed conversion. But why isn't it 1:13 for AO?
<TobiasTh1Viking>
wait, why isn't it 0:13 (starting at 0).
<xdarklight>
ah, the reason for that is they have *one* GPIO interrupt controller but two pin controllers. the GPIO interrupt controller takes the pins from both pin controller
<xdarklight>
so they can't use 0 for GPIOAO_0 and 0 for GPIOZ_0 again because then the interrupt controller couldn't differentiate the pins
<TobiasTh1Viking>
ah. oki. so 0 is reserved.
<xdarklight>
not really, it's just used for GPIOZ_0 :)
<xdarklight>
and GPIOAO_0 uses 182
<TobiasTh1Viking>
ok. i have enough data now that i should be able to finish meson6_cbus_banks on my own?
<TobiasTh1Viking>
for verification, just (un)plug sdcard, and check dmesg for card plugged unplugged. or is there a better way i can directly check the GPIO pin? (like in sys or proc)
<xdarklight>
let me check the CBUS banks first
<xdarklight>
ok, for CBUS it's similar but not identical
<xdarklight>
in the mainline driver this bank looks like: BANK("X", GPIOX_0, GPIOX_21, 112, 133, 4, 0, 4, 0, 0, 0, 1, 0, 2, 0),
<xdarklight>
(let's ignore IRQ, pull and pullen for now again)
<xdarklight>
you can see that "dir" is 0, 0 in the mainline driver, just like in Amlogic's code
Barada has quit [Quit: Barada]
<TobiasTh1Viking>
yes
<xdarklight>
BUT: out is "1, 0" in the mainline driver (and in is "2, 0" in mainline)
Barada has joined #linux-amlogic
<xdarklight>
while there doesn't seem to be a difference in Amlogic's code
Barada has quit [Client Quit]
Barada has joined #linux-amlogic
<xdarklight>
this is because they use these p_gpio_oen_addr, p_gpio_output_addr and p_gpio_input_addr lookup tables that map indices to registers
<TobiasTh1Viking>
and mainline uses pinctrl and device tree. for which i need to define it?
<xdarklight>
so in Amlogic's code PIN_MAP(GPIOX_0,0,0) means: "for GPIO_X look up the registers (direction, input and output) at index 0, then use bit 0 in the resulting register"
<xdarklight>
index 0 maps to P_PREG_PAD_GPIO0_EN_N (for the direction register), P_PREG_PAD_GPIO0_O (output register) and P_PREG_PAD_GPIO0_I (input register)
<xdarklight>
only the first of these 3 addresses is defined in your .dts
<xdarklight>
to find it: multiply 0x200c by 4
<xdarklight>
found it?
<TobiasTh1Viking>
i'm getting way wrong numbers out.
<TobiasTh1Viking>
i've found the things. but i'm not comprehending.
<xdarklight>
0x200c * 4 = 0x8030
<xdarklight>
you find this in your cbus pinctrl node, it matches the "reg-name" "gpio"
Barada has quit [Ping timeout: 246 seconds]
<TobiasTh1Viking>
isn't 0x8030 == 32816 ?
<xdarklight>
yep
<xdarklight>
but the numbers in .dts are all hex
<TobiasTh1Viking>
ah, it's for the dts.
<TobiasTh1Viking>
ok, see it in dts.
<xdarklight>
ok
Barada has joined #linux-amlogic
<xdarklight>
so long story short: this is how I would translate the cbus banks:
* TobiasTh1Viking
thought you were explaining how to calculate out and in for mainline.
<xdarklight>
BANK("X", GPIOX_0, GPIOX_NN, <take the original numbering for IRQ first>, <take the original numbering for IRQ last>, <ignore pullen reg for now>, <ignore pullen bit for now>, <ignore pull reg for now>, <ignore pull bit for now>, <register from PIN_MAP>, <bit from PIN_MAP>, <register from PIN_MAP + 1>, <bit from PIN_MAP>, <register from PIN_MAP + 2>, <bit from PIN_MAP>),
<xdarklight>
why + 1 and why + 2? well, it gets you from the 0x8030 register to the next register (0x200d, or to the one after that: 0x200e)
<TobiasTh1Viking>
oki. i think i got it.
<TobiasTh1Viking>
will that be enough to check the sdcard inserted GPIO pin?
<xdarklight>
should be
<xdarklight>
show the diff before you boot something
<xdarklight>
just so someone else can check - then hope that it works :)
<xdarklight>
in /sys/class/gpio you can export gpios
<xdarklight>
so you can see that state in sysfs
<TobiasTh1Viking>
ok. sounds good. And definetly don't boot without showing code first. i can fry something?
<TobiasTh1Viking>
if there is no risk of frying something, i don't see why i don't just boot and try.
<xdarklight>
I've not fried a board with "just" software yet
<xdarklight>
you can probably just try it
<TobiasTh1Viking>
i'll probably try then. thanks for help. i'll post a patch when i'm done with the cbus bank.
<TobiasTh1Viking>
but i'll start compiling and do a test run once i've posted the patch.
Barada has quit [Quit: Barada]
Barada has joined #linux-amlogic
<xdarklight>
good luck!
<TobiasTh1Viking>
thx
<TobiasTh1Viking>
reading thourhg this, you said dts file like 5 times where i missed it looking at code. sorry bout that.
<ndufresne>
I wonder what's the diff with the other ucode ?
<Ely>
ndufresne: I spoke a tad too soon, the picture looks heavily corrupted, but at least the decoder doesn't complain and "decodes" 4K. I've seen some "if (is_4k" conditions in the original vh264.c so I'll have to check further. But without a doubt it's possible.
<ndufresne>
yeah, well I notice we have broken frame with bbb 1080p60, I think one of our internal buffer is too small
<Ely>
Ah, great that you figured that out. I noticed that some frames in my test files always got corrupted (buffer decode error 00200), but I never knew why. Most likely the bframes.
<Ely>
They do have a define "DROP_B_FRAME_FOR_1080P_50_60FPS" but it's only for <= meson6, so yeah probably we do something else wrong.
<ndufresne>
I see a lot of comment in the code that seems to indicate they add hacks like this, or bump some buffer size in a test driven way
<ndufresne>
instead of trying to figure-out from the spec
<ndufresne>
will be around later
tingoose has quit [Remote host closed the connection]
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: 264 seconds]
Elpaulo_m2 has quit [Client Quit]
Elpaulo has quit [Quit: Elpaulo]
Elpaulo has joined #linux-amlogic
Barada has quit [Quit: Barada]
tingoose has joined #linux-amlogic
fedux has joined #linux-amlogic
vagrantc has joined #linux-amlogic
BlueMatt has quit [Excess Flood]
BlueMatt has joined #linux-amlogic
fedux has quit []
Ntemis has joined #linux-amlogic
Guest8491 has quit [Quit: Bye]
mag has joined #linux-amlogic
<ndufresne>
Ely, I'm trying to understand the purpose of load_extended_firmware(), the h264 implementation seems to allocate cma, and copy into it, and later free it, I don't see any use of ext_fw_vaddr. Am I missing something ?
<ndufresne>
the canvas have an extra (generally unused in the numerous copy of the canva implementation) bit mask
<ndufresne>
from the rights, each bits will, swap every byte for each 16bit, then swap every 16bit every 32bit, swap every 32bit every 64bit and swap every 64bit every 128bit
<ndufresne>
we saw that we had 64bit with bytes being swapped, so setting the first 3 lowest significant bits (0x7) will revert the order, then on uv plane, if you set 0x6, you get NV21
<ndufresne>
Ely, btw, I found that in hevc driver
<narmstrong>
i will need to take care of these bits in the drm driver
<dsd_>
NV21 or NV12?
<narmstrong>
both !
<ndufresne>
yes, we can select both
<Ely>
Isn't it "then on uv plane, if you set 0x6, you get NV12" ?
<ndufresne>
I'm quite sure having 0x7 0x7 from both canvas produced NV12, because I had the color swapped at first
<ndufresne>
so 0x7 0x6 should be NV21
<Ely>
Oh I see
<ndufresne>
it's natively NV21, but as we said, all bytes over 64bit are revered order
<ndufresne>
dsd_, so it's likely we'll be able to expose NV12, NV21 and I420, + 32x32 tiling
<ndufresne>
when we get there ;-P
<ndufresne>
but it's not clear yet if tiling improve performance yet
* narmstrong
trying the last version, working !!
<narmstrong>
Ely: what are your options to kmssink to make it smooth ?
<Ely>
sync=false helps a ton at the end iirc
<Ely>
Also the perf seems better since we switched to NV12
<narmstrong>
ok, but it plays at 1/2 speed, I need to apply the patch ndufresne pointed us
<narmstrong>
Ely: did apply the patch to kmssink ?
<ndufresne>
Ely, the reason for the sync=0 being better is because of how v4l2video0dec guesses the decoder latency
<Ely>
huh. 720p30/1080p30 plays almost smoothly on my TV
<ndufresne>
I'll need to figure-out something
<narmstrong>
bbb unflower 1080p30 ?
<ndufresne>
Ely, with sync=0, max-lateness should have no effect, also max_lateness is not a property of kmssink
<Ely>
ah okay, I'll remove it then.
<Ely>
narmstrong: my kernel isn't in a state where I can play a H.264 video right now (I'm getting at HEVC), sorry :S
<ndufresne>
narmstrong, I was surprise, but here, after fresh boot, I don't need to pass the connector and force the mode
<narmstrong>
Ely: don't worry !
<ndufresne>
narmstrong, I'm running bbb_sunflower_1080p_30fps_normal.mp4 here, it breaks at two spots
<ndufresne>
first one is a usual spot, as I don't think the file is totally legit, the second spot was new to me
<narmstrong>
ndufresne: it's because the HDMI connector is linked to an encoder since the fbcon uses it, but when kmssink stop it disconnects the connector and a the next run, HDMI and CVBS are equal and CVBS is selected
<narmstrong>
kodi has the same issue...
<ndufresne>
fair
<ndufresne>
would be nice we kmssink also supported connectors by name, which I guess is what we have in old things like xrandr
<narmstrong>
indeed, the number is board dependent
* ndufresne
taking notes ;-P
Ntemis has quit [Remote host closed the connection]
<Ely>
narmstrong oh, oops. I thought the clock framework automatically found the best parent to use
<narmstrong>
Ely: the lowest, 500MHz is the lowest closest
<narmstrong>
or you must add some other flags
tingoose has quit [Ping timeout: 256 seconds]
<Ely>
okay
<Ely>
but are you sure the clk framework doesn't try all the possible parents to see which one will give the best result ?
<Ely>
closest* result
<Ely>
well, lowest closest, whatever
<Ely>
:D
<narmstrong>
yes,it should if you have the right flags
<Ely>
alright
<Ely>
I think they use something else than DIV4 for 648 though let me check
<narmstrong>
you will need to remove CLK_SET_RATE_NO_REPARENT then !
<narmstrong>
they must use DIV1 and a divider on the VDEC1_DIV
<narmstrong>
hmm, it can only use DIV3, 4, 5 & 7
<Ely>
yes it's just like the vpu clks
<narmstrong>
set to 666MHz, it's the max clock rate
<Ely>
nvm the code says 648M but it's div4 with divider=1
<Ely>
so indeed 666
Ivanovic has quit [Quit: Caught sigterm, terminating...]
Ivanovic has joined #linux-amlogic
Ivanovic has quit [Changing host]
Ivanovic has joined #linux-amlogic
<Ely>
what's the clock of xtal ?
<Ely>
"but it's div3* with divider=1"
<Ely>
and nevermind, found it in the HK datasheets
<Ely>
narmstrong: but I think it makes sense to remove the clk flag, I'll want to not care about what the parent is in the future
<Ely>
What's the flag to get closest instead of lowest ?
<narmstrong>
Hmm, none, just put 666 you won’t get upper anyway
<Ely>
Sure, but how do you tell the clk framework to autoselect the parent without specifically telling it ? Like, I don't want to have to put this entry: assigned-clock-parents
<narmstrong>
Remove the flag on clk_sel
<Ely>
Thank you!
dsd_ has quit [Quit: Lost terminal]
trem_ has quit [Quit: Leaving]
<chewitt>
xdarklight: someone was asking about the meson6 HDMI IP (not being the same Synopsys part as S805/905). Contacts say it's from Transwitch