10:17 <bbrezillon> robmur01: I'm currently looking at the VM_BIND implementation for pancsf, which is about delegating the VM map/unmap operations to an exec queue (sched_entity). The thing is, we need to make sure no allocation happens in the run_job() path, which is where the map/unmap operation happen. Do you think it'd be possible to extend the pgtable API to pass a custom page allocator (or pass

10:17 <bbrezillon> pre-allocated pages), or should I just consider duplicating the page table logic in pancsf (AFAICT, most drivers have their own pgtable implem, but it might be just because they don't re-use an existing pgtable format)

10:27 <bbrezillon> there might be other good reasons for having our own pgtable implementation though. I know TTM manages page table memory too, and, if we ever want to use clever reclaim/swap-out mechanisms, we should probably switch to TTM. Not sure how well the iopgtable stuff would interface with the TTM abstraction, even if we have a way to delegate page table allocation.

16:43 <Googulator> bbrezillon : Are these commits still relevant? https://github.com/Googulator/linux-rk3588-midstream/compare/122887d92300034fb8a5721576aba8d66d072011...Googulator:linux-rk3588-midstream:cf13616a062411f4d7d804e6d6af8f695a2c7f63

16:46 <Googulator> These were in the pancsf branch before it was rebased, but are now gone. I reapplied them in my fork on top of the newer code from the 7th, and with a small additional fix (https://github.com/Googulator/linux-rk3588-midstream/commit/f563c09394db72ff99e18fd038c78abd46228a77), got devfreq to work, but I'm wondering if all of them are still needed.

16:47 <Googulator> (2nd supply doesn't seem to be essential, probably we only incur a small power efficiency hit by running SRAM at a fixed voltage.)

16:55 <Googulator> actually - looking closely at the vendor DTS, the 2nd supply doesn't actually exist

16:55 <Googulator> see https://github.com/radxa/kernel/blob/stable-5.10-rock5/arch/arm64/boot/dts/rockchip/rk3588-rk806-single.dtsi#L153 - vdd_gpu_s0 and vdd_gpu_mem_s0 are synonymous

17:00 <Googulator> They may be distinct on boards with 2 RK806 PMICs (Rock 5B has only one, QuartzPro64 probably has two)

18:24 <bbrezillon> Googulator: re commits: the fixups were merged in the original patch, and the rest is just WIP and debug hacks

18:27 <bbrezillon> the GPU needs 2 power supplies, the fact it's provided by the same PMIC output on rk3588 boards means we don't have to figure it out right now, but it's still something we need to address before merging the devfreq support

19:58 <robmur01> bbrezillon: confused... grepping for "run_job", pretty much every implementation seems to make *some* kind of GFP_KERNEL allocation - am I looking at the wrong thing?

20:02 <robmur01> what would the custom allocator look like?