09:33 <diederik> Dex2x: try without the ``ARCH=arm64``. If you don't specify it, it takes the native arch ... which is arm64

09:48 <diederik> tbf: it shouldn't make a difference

11:19 <jaganteki> mriesch: about bayer question. I did try the pipeline using bayer2rgb and it stream and hangs in all resolutions

11:19 <jaganteki> gst-launch-1.0 -v aravissrc do-timestamp=true ! video/x-bayer,format=gbrg,width=2448,height=2048 ! queue ! bayer2rgb ! queue ! videoconvert ! queue ! fpsdisplaysink sync=false text-overlay=true video-sink="kmssink"

11:19 <jaganteki> mriesch: like above pipeline.

11:21 <CounterPillow> mriesch may specifically be inquiring further because he is working on getting the camera and ISP stuff up and running in mainline ;)

11:22 <mriesch> jaganteki: triggered by your question i quickly ran a test pipeline on rk3588 with the downstream kernel and gstreamer 1.26. this ended up in a segfault :-/

11:23 <mriesch> but CounterPillow is correct of course, i used the element before for my rk3588 vicap mainline work. but there the issue is that i don't get any frames out of the hw

11:26 <mriesch> jaganteki: since your pipeline is not exactly trivial, have you tried simplifying it a bit to rule out issues that could stem from other elements?

12:06 <jaganteki> mriesch: i'm running downstream 6.1.84 with 1.22 gst. do you have any apt source to grab 1.26 gst?

12:23 <mriesch> jaganteki: should be this one, if you can access it: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/pkg/gst-plugins-bad1.0/

12:23 <mriesch> anyway in the mean time the rk3588 showed the first signs of life with a mainline driver

12:24 <mriesch> (based on mainline, more like. or hopefully-soon-to-be-mainline)

12:25 <mriesch> and the bayer2rgb element worked as expected. the image is wrong in many ways, but i don't think the bayer2rgb is to blame for that

12:26 <qschulz> mriesch: \o/

12:37 <mriesch> (rk3588 VICAP, that is)

12:41 <qschulz> mriesch: but once that's done, we can use Software ISP in libcamera no?

12:59 <mriesch> qschulz: surely there's a ton of bugs remaining, but in principle yes

13:03 <qschulz> darn it, I should really start working on the few camera modules we have :)

13:03 <qschulz> so we're ready when this time comes

13:13 <mriesch> qschulz: what modules do you have? :-)

13:15 <qschulz> ov5675 which needs to run at 24MHz, ov13850 and ov9281

13:16 <qschulz> fortunately the first two I can have them run with a PX30/RK3399-based SoM

13:16 <qschulz> the latter is more difficult, have to dig a downstream-only motherboard

13:17 <qschulz> and it's also black and white only, which the ISP doesn't like

13:17 <mriesch> does omnivision encode the megapixels in their part names?

13:17 <qschulz> I was able to hack things quickly a year or so ago and then some deeper changes happened in v4l2 and my quick and dirty solutionm doesn't apply anymore :)

13:18 <qschulz> no clue :)

13:19 <qschulz> but no, 13850 is 13.2Mp, but maybe if you count the binning or whatever the name of the "dead" pixels are, maybe?

13:52 <warpme> guys: i'm adding 3566 cpu overclock capability via overlays and have strange issue(?). My overlay adds two extra oop: 1608Mhz and 1800Mhz. But on running system dt opp table gets active only 1608 opp. 1800 is present but with status 'disabled'. My dtbs: https://gist.github.com/warpme/84cff21d8ed0715e65c893e9f7ce1438 I see cpu_vdd is the allowable limit of regulator: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boo

13:52 <warpme> t/dts/rockchip/rk3566-radxa-zero-3.dtsi?h=v6.15#n428 Why this?

13:56 <qschulz> warpme: did I misread or is the two OPPs you want to add already in the rk3566.dtsi?

13:57 <warpme> well - i wan to add them to https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3566t.dtsi?h=v6.15 as afaik zero3e is 3566t ?

13:58 <qschulz> grmbl, why is the board not named rk3566t then

13:59 <qschulz> smh

13:59 <qschulz> no clue otherwise, sorry

13:59 <warpme> ah got it! i have typo in board dtsi. let me fix this....

14:07 <robmur01> mriesch: seems there's definitely some rough numerical relationship: ov2xxx == ~2MP, ov5xxx == ~5MP, ov7xxx == 0.7MP, ov9xxx == 0.9-1MP

14:08 <mriesch> robmur01: ah, 9 means 0.9 :-)

14:08 <mriesch> i like that sort of thing :-)

17:50 <CounterPillow> rockchip-dfi in mainline seems busted for LPDDR4/X on RK3588, as I've noticed while adding LPDDR5 support. I get half the clock cycles I should be getting, and 2/3rds of the bandwidth I expect of 2112 MHz memory.

17:50 <CounterPillow> 22625.43 / 1.003342714 * 8 / 64 / 4224 = 0.6673192361128852

17:50 <CounterPillow> 1059590022 / 1.003342714 / (2112 * 1000 * 1000) = 0.5000283691926299

17:50 <CounterPillow> can anyone else confirm?

18:39 <CounterPillow> okay, the bandwidth is actually fine, as stress-ng --stream confirms

20:04 <CounterPillow> Kwiboo: ROCK 2A/2F boards arrived btw, will use some time on the weekend or next week to play with them :)