09:24 <rockosov> jbrunet: Hello Jerome! First of all, thank you very much for detailed review of my meson a1 clock driver, appreciate it! I have one dilemma in the A1 clock driver implementation. It's related to pwm clocks. As you can see pwm clocks have different parents connected through the pwm_sel mux. One of them is RTC clock. We know that usually RTC clock is more accurate and sometimes it must be

09:24 <rockosov> selected by default depending on what you connected to the SoC PWM I/O. So if we mark pwm clocks with auto-reparent flag and use .set_rate() callback, sometimes CCF logic will not choose RTC clock. If we open pwm_sel to device tree public IP (dt-bindings) and mark pwm clock with NO_REPARENT flag, we will not have ability to set_rate automatically for some pwm clocks which should not be

09:24 <rockosov> connected with RTC. Do you know any way to resolve this problem and implement both ways together: auto-reparent and static parent binding? Appreciate any help, thank you for your time.

12:52 <phh> narmstrong: wrt bypassing esparser, I would like to take a look at it. do you know what does the decoder take as input (let's say h264 for the moment)? so far it seems to me that the only thing esparser does is filling the vififo, and that bypassing esparser is "simply" setting vdec's vififo register to manual input, and the input format of vdec is still just NALs. Does that match your knowledge?

14:19 <narmstrong> phh: probably, I haven't looked at that, it was what mjourdan figured out with he wrote the multi h264 decoder

14:20 <narmstrong> phh: did you see the WiP multi h264 decoder he wrote just before disappearing ?

14:21 <phh> nope, that's on patchwork?

14:21 <narmstrong> https://gitlab.baylibre.com/baylibre/amlogic/atv/linux/-/commits/mjourdan/amlogic/v5.6/vdec-h264-multi/

14:21 <narmstrong> he last commited exactly 3y ago today :-(

14:23 <phh> thanks

14:23 <narmstrong> it was close to be functionnal, and his plan was to convert the vp9 & hevc to direct input once the h264 was working

14:24 <narmstrong> honestly I'll split the "old" and "new" into 2 drivers because the sequencing is very different, and it would greatly simplify the code

14:25 <narmstrong> be first we must get rid of esparser for the new codecs so we can correctly track buffer lifetime

14:25 <phh> i gidn't plan to go the multi route, but well

14:26 <narmstrong> honestly, I tried fixing it but it's very hard to maintain both routes working with a common code, and it will be even worse when introducing direct input & multi output buffer formats

14:26 <phh> ok, good to know

14:26 <rockosov> narmstrong: Hello Neil! Could you please take a look at the above question about clk re-parent problem? Thanks in advance for any suggestion.

14:27 <phh> doesn't multi end up being a stateless codec?

14:29 <narmstrong> phh: hard to say, but perhaps we could reconstruct NAL units/buffers from userspace state and feed the decoder, or reverse the metadata buffer and fill it

14:32 <narmstrong> rockosov: hmm, indeed it's a complex issue, there's no "preferred parent" stuff, perhaps find why the other parent is selected ? perhaps calculation is slighly off

14:32 <narmstrong> rockosov: a way would be to set NO_REPARENT and specify parent in DT with assigned-clock-parents

14:33 <narmstrong> rockosov: with this it would match the behavior of the GX/G12 PWM clk selection

14:41 <f_> HackerKkillinghi, narmstrong: Got IR to work!

14:41 <f_> I just had to enable the NEC decoder....XD

14:41 <f_> Which meant rebuilding the kernel.

14:41 <f_> HackerKkillinghi: I'll send a MR, adding support for the remote!

14:42 <rockosov> narmstrong: Is it any reason to not have 'preferred parent' functionality? By design? Calculation may be wrong, but when we calculate clk rates properly, several clock parents can fit final rate, but they will have different HW parameters, for example accuracy (sysclk vs rtc clock)

14:42 <narmstrong> f_: nice! I was wondering about that

14:42 <f_> Yeah.

14:42 <narmstrong> rockosov: no idea, I think accuracy is a kind of "generic" way to prefer a clock over another

14:42 <f_> The `dmesg` error I pasted, saying that it was interesting, was actually telling that the IR used the NEC protocol, but that the kernel couldn't handle it because, the NEC decoder wasn't there.

14:43 <f_> HackerKkillinghi: Also

14:43 <f_> Both the IR remote that came with my device AND an aftermarket one work!

14:44 <f_> HackerKkillinghi: You said you knew that one day we'll have a working IR remote without any additional configuration.

14:44 <f_> Well. Today is the day!

14:44 <f_> Anyway, I'll work on SXMO's "TV mode". Cya

15:03 <rockosov> narmstrong: so, may be it's time to propose 'preferred parent' optional feature to CCF :)

15:04 <narmstrong> rockosov: Yea probably, but meantime sticking to NO_REPARENT and specifying assigned-clock-parents would be the best way to go

15:11 <rockosov> narmstrong: NO_REPARENT totally disable re-parent mechanism, without assigned-clock-parents there is no way to set parent by rate propagation.

15:14 <narmstrong> rockosov: rate propagation will work but with parent programmed in register at probe

15:14 <narmstrong> so it's not a big deal

15:19 <rockosov> narmstrong: yep, rate propagation will work only for static parent, set in the probe() during assigned-clocks handling. I mean auto-reparent process will not work. But yes, maybe it's not a big deal.

15:24 <HackerKkillinghi> <f_> "Anyway, I'll work on SXMO's "..." <- Good kbd are useless now

15:25 <HackerKkillinghi> u only need alot of different remote

15:26 <f_> Sorry but what do you mean by that?

15:26 <f_> I didn't fully understand.

15:27 <HackerKkillinghi> f_: Joke

15:27 <f_> ¯\_(ツ)_/¯ Heh. That's why you said that we needed lots of different remotes

15:27 <f_> So yeah, it works.

15:28 <HackerKkillinghi> XD yeah

15:28 <f_> Without needing anything else.

15:28 <f_> I don't even need to use lirc!

15:28 <HackerKkillinghi> XD

15:28 <f_> It's recognised as an input by libinput/Sway, so yeah!

15:28 <f_> It's basically handled just like a keyboard!

15:28 <HackerKkillinghi> Ah

15:29 <f_> Some of the buttons actually map to keyboard buttons!

15:29 <HackerKkillinghi> Have you

15:29 <f_> OK maps to Enter, for example!

15:29 <f_> HackerKkillinghi: Yes?

15:29 <HackerKkillinghi> HackerKkillinghi: make a mr for fixing that

15:29 <f_> (nice one, appservice-irc)

15:29 <f_> I'll make one shortly.

15:29 <f_> And update the wiki page.

15:30 <HackerKkillinghi> f_: i mean

15:31 <HackerKkillinghi> make a mr on pm os for adding the ir nfc config in the kernel

15:31 <f_> Yes..

15:31 <f_> I just said I'll make one shortly. I'm testing and will create one later today.

15:31 <HackerKkillinghi> f_: Ok

15:32 <f_> So that others can benefit from the ultimate fix to my mistake!

15:32 <HackerKkillinghi> f_: check yourmartix

15:32 <f_> HackerKkillinghi: My matrix client doesn't work at the moment so I can't really check.

15:32 <HackerKkillinghi> f_: XD

15:32 <f_> I have to recompile it.

15:33 <f_> Oh, and Element's unusable.

15:33 <HackerKkillinghi> f_: I sented a dm to u

15:33 <f_> Maybe send a PM on IRC? That'll be much easier.

15:33 <f_> Or on XMPP if you use it?