08:08 <narmstrong> endrift: honestly, the HW is very correct and simple (no IOMMU and complex PM stuff), and almost no bugs, but yeah the vendor source code is really crappy

08:09 <narmstrong> endrift: having vendor tweaks in driver seems a nonsense, but it's pretty common when dealing with generic IPs like ARM or Synopsys ones

08:10 <endrift> it was specifically the source code that gave me this reaction

08:10 <endrift> I was trying to fix a bug in one kernel for one chip that made the cores not all come back up properly after a suspend

08:10 <endrift> and they'd just randomly refactored core power management routines for no apparent reason

08:10 <endrift> I have to imagine they were shotgun debugging

08:10 <endrift> which is discouraging in kernel code

08:11 <endrift> I believe the issue ended up being that only one of the cores ended up getting reattached to the CPU governor for whatever reason (I never fixed it) so while all the cores did come back up only one ever got reclocked above 40 MHz

08:12 <endrift> which led to things seemingly behaving like it was a single core; anything that ran on the second core was just incredibly slow until it got moved to the first core

11:41 <icecream95> alyssa: MALI_AFBC_YTR is definitely the right bit for making the red and blue channels be TRanslated down by Y (green)

12:57 <alyssa> icecream95: I mean it's YUV but yeah, i'm fairly certain it's a rockchip display kernel bug which I guess I should send a patch for