narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki - ml - Publicly Logged on
aballier has quit [Ping timeout: 264 seconds]
aballier has joined #linux-amlogic
<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> let's look at the MESON_BANK preprocessor macro to understand it's parameters:
<TobiasTh1Viking> oki.
<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.
<xdarklight> next is where you find this information in the 3.10 kernel:
<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> seems so :)
<TobiasTh1Viking> BANK("AO", GPIOAO_0, GPIO_TEST_N, -1, -1, -1, -1, -1, -1, 7, 0, 7, 16, 7, 0),
<xdarklight> (when we add the cbus bank you'll see why they are separated)
<TobiasTh1Viking> and the code automatically +1 on the bit.
<xdarklight> right!
<TobiasTh1Viking> k. so now i do this for cbus, compile, and check sdcard gpio?
<xdarklight> let's fill the PULL and PULLEN bits also
<TobiasTh1Viking> oki. not irq?
<xdarklight> on Meson8 and Meson8b this simply uses the "direction" values for "pullen" and "out" values for "pull"
<xdarklight> IRQ is not used in the pinctrl drivers internally (yet). so you don't lose functionality if you don't add it for now
<TobiasTh1Viking> well, would have to go back and fix it later. might as well do it correctly now.
<xdarklight> I need to check where the IRQs are defined first
<xdarklight> before we do that we need one more step
<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> (0x00 << 10) results in 0
<xdarklight> (0x09 << 2) results in 0x24
<xdarklight> so the actual register address of P_AO_GPIO_O_EN_N is wherever AOBUS is plus 0x24
<TobiasTh1Viking> yeah, i have never understood the << thing. and i don't know what it is called, so i can't google it.
<xdarklight> now look at your .dts: we already specify register 0x24 there :)
<xdarklight> ah, it's bit shifting
<xdarklight> shift 0x09 two bits to the left
<xdarklight> (shift by 1 also means: multiply with 2, so in this case you can simply multiply with 4 ;))
<TobiasTh1Viking> oki. got a nice wikipedia open, thx. i'll read up.
<TobiasTh1Viking> not getting it now. but bit's are easy. so no problem. :)
<xdarklight> :)
<TobiasTh1Viking> yes, i see "0x24 0x8" in dts.
<xdarklight> that was a lot of text just for saying: we have to replace register "7" with register "0" (only for the AO bank)
<TobiasTh1Viking> bahahaha
<TobiasTh1Viking> nice
<xdarklight> now onto the IRQ numbers
<xdarklight> the first parameter to PIN_AOMAP is pin, the store it in the .num field (and read that in gpio_amlogic_to_irq)
<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> let's take Meson8 as an example: let's go with PIN_MAP(GPIOX_0,0,0)
<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.
dsd_ has joined #linux-amlogic
<ndufresne> Ely, nice, make sense, it's it's basically 1080p115 / 4
<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 ?
<Ely> writel_relaxed(h264->ext_fw_paddr, core->dos_base + AV_SCRATCH_G);
<Ely> you had me worried for a second :D
<ndufresne> I'm blind ...
<Ely> Regarding what's inside that extended firmware, I have no idea. There are 5 sections of microcode named "header, data, mmco, list, slice"
<Ely> well you probably already know about them
<ndufresne> yeah, no idea
<ndufresne> I was trying to learn something about MDEC_PIC_DC_CTRL
<Ely> ah, the magic NV21 register..
<ndufresne> all I know is that (1 << 17) enabled NV21 (some kind of), but what happens if you don't enable that ?
<Ely> then you get a 3-plane format and you have to map 3 canvases per buffer
<Ely> at least in 3.10/S805. The more recent the code, the more everything is hardcoded to nv21
<Ely> No idea about the specific 3-plane pixfmt. With your canvas changes maybe you get yuv420p.
<ndufresne> ok, sounds like I420, or YUV420P in v4l2 terms
<ndufresne> well, no idea which plane will be U and which one V ;-P
<Ely> #else
<Ely> buffer_spec[i].v_canvas_index = 128 + i * 3 + 2;
<Ely> buffer_spec[i].u_canvas_index = 128 + i * 3 + 1;
<Ely> buffer_spec[i].y_canvas_index = 128 + i * 3;
<Ely> so.. yeah probably I420
<dsd_> i guess that is the setup we have in endless 3.10 kernel
<dsd_> unfortunately its not quite a standard format
<Ely> Don't you use ge2d to convert the buffer to a standard pixfmt?
<dsd_> but you can use ge2d to convert it to a standard format
<Ely> ndufresne recently discovered that you can configure the canvas in a way that you get proper NV21 or NV12 out of the decoder
<Ely> no tiling, no endianness..
<dsd_> nice
<dsd_> got any details there?
<dsd_> i wonder if that is S805 or S905+ only. we did ask amlgog
<dsd_> i think we asked amlogic at the time and they pointed us to ge2d only
<Ely> What you're looking for to get NV12 is linear mode + the proper bits in endian control
<dsd_> thanks a lot, very cool
<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 ?
<Ely> gst-launch-1.0 souphttpsrc location=<loc> ! parsebin ! v4l2video0dec ! videoconvert n-threads=4 ! kmssink driver-name=meson force-modesetting=true connector-id=31 max_lateness=-1 sync=false
<Ely> No I didn't apply any gst patch
<ndufresne> I also get steady 15fps
<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]
<narmstrong> this `gst-launch-1.0 souphttpsrc location= ! parsebin ! v4l2video0dec ! videoconvert n-threads=4 ! kmssink driver-name=meson force-modesetting=true connector-id=31 sync=false`is really smooth
<narmstrong> seems 1080p frames are too big to render in SW...
<narmstrong> Ely: you 648MHz fix is not good, you must force FCLK_DIV4 and use 666MHz like //
<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