11:34 <warpme> guys: i'm developing dt for radxa zero3 (https://radxa.com/products/zeros/zero3w/ ). Kernel is 6.7 mainline. Have all working except emmc. My dt has sdhci enabled. sysfs for sdhci appears (/sys/devices/platform/fe310000.mmc) but it has "waiting_for_supplier". So it looks to me something is missing in dt. May somebody hint me how can i find what is missing ?

13:50 <phh> warpme: a voltage regulator

13:52 <warpme> phh : this is what i checked first.... Comparing with other rk3566 boards: iirc none of them has voltage regulators present in sdhci....

13:54 <warpme> my dtsi: https://gist.github.com/warpme/a725da0b64514fe47948aa204f1bcd2a

13:55 <warpme> and dts for w variant:https://gist.github.com/warpme/5a26b7cb8a128906c1f7634e80a83cf2

20:38 <linkmauve> CounterPillow, I’ve added support for decoding JPEGs to onix, my image decoding library, you should be able to use it whenever you get back to writing the driver for the VDPU720.

20:38 <CounterPillow> :D yeah I haven't worked on that driver in a hot minute

20:38 <linkmauve> I’ve only tested it on experimental cedrus patches I wrote two years ago and jarnej helped me fix today. :)

20:39 <linkmauve> Will send them for mainlining soon.

20:39 <linkmauve> Would be nice if it could get into 6.8, but 6.9 sounds more realistic.

20:39 <CounterPillow> too late for 6.8

20:40 <linkmauve> The merge window is still open isn’t it?

20:40 <CounterPillow> Yeah but if it's not in a maintainer's tree before the merge window opens it's unlikely to get in

20:40 <CounterPillow> since then the maintainer has to send a second pull request

20:41 <linkmauve> Alright.

20:46 <CounterPillow> less than 2 weeks would be an insane turnover for a new feature to be added. Generally when you post something on the list it'll take a few days until someone gives it any attention (unless it's a DT bindings patch, they're on that on the same day). Then you'll probably get feedback that requires incorporating some changes, which means a V2, which you don't want to send out immediately but only after a few days as to not flood the

20:46 <CounterPillow> list too much. Then it needs to undergo review again and if you're lucky is good enough to be applied by the respective subsystem maintainers

20:47 <CounterPillow> A good time to send in new features is generally around rc1/rc2, since then maintainers aren't busy dealing with merge window stress and there's plenty of time left for reviews until the next merge window

20:48 <linkmauve> Ok. :)