09:22 <javierm> geertu: thanks for the v2 of your ssd130x patches! I'll wait for daniels answer and then land if he agrees. But I think the same than you, if anything is missing w.r.t modifers is not related to your patch

09:39 <geertu> javierm: Thanks for agreeing ;-)

09:40 <geertu> javierm: BTW, I added some debug prints, and noticed that 45b58669e532bcdf ("drm/ssd130x: Allocate buffer in the plane's .atomic_check() callback") completely defeated 49d7d581ceaf4cf8 ("drm/ssd130x: Don't allocate buffers on each plane update"): buffers are allocated and freed on every change (e.g. cursor blinking).

09:41 <geertu> "echo 0 > /sys/class/graphics/fbcon/cursor_blink" has a noticable impact on system performance on my meager VexRiscV softcore...

09:43 <javierm> geertu: yeah... but the former was done due feedback on the latter. That is more correct from a KMS pov

09:44 <javierm> geertu: that was suggested by mripard, maybe he can comment on that

09:44 <javierm> ah, he is not here

09:45 <geertu> javierm: I plan to fix that for good if I find some time to work on it...

09:46 <javierm> geertu: what's your plan?

09:46 <geertu> javierm: Move it to another atomic state callback, so it's doing during mode changing.

09:46 <geertu> s/doing/done/

09:47 <javierm> geertu: problem is that there are only a handful of atomic state callbacks that are allowed to fail

09:47 <javierm> nothing after drm_atomic_helper_swap_state() should

09:48 <javierm> that's why plane's .atomic_check() was suggested by Maxime as the correct place to do it

09:48 <geertu> javierm: hence crtc's .atomic_check

09:52 <javierm> geertu: right, that should work I believe

09:55 <javierm> geertu: having it in the primary plane .atomic_check is cleaner IMO because the buffers are related to the plane content but no if the perf hit is noticeable

09:56 <geertu> javierm: The size of the intermediate buffer is related to the mode, the size of the hardware buffer is related to the hardware.

09:58 <javierm> geertu: yes, I meant the intermediate buffer. The hardware buffer is fixed (just depends on the res defined in the DTB)

09:58 <javierm> geertu: just asked Maxime, he says that CRTC's .atomic_check would be fine too

09:58 <javierm> I can type a patch for that once your changes land

10:02 <javierm> geertu: likely you are the one running DRM/KMS in the slower platform :) unless someone has something slower than your VexRiscV softcore

10:02 <javierm> and is testing a KMS driver

10:03 <geertu> javierm: I should do bitbanged i2c on the Amiga, and try there ;-)

10:03 <javierm> :)

10:14 <milkylainen> any mtd knowledgeable people in here?

10:15 <milkylainen> I moved the index of CONFIG_MTD_PARTITIONED_MASTER and would like an opinion.

10:20 <geertu> milkylainen: index?

10:31 <milkylainen> geertu: The mtd device name index.

10:32 <milkylainen> geertu: problem is that on devices without gpt or similar, root=/dev/mtd<numbersomething> indexing is broken by PARTITIONED_MASTER which takes index 0.

10:33 <milkylainen> I don't think labels work without gpt, uuid or similar? Either way, that old bootloader is released.

10:35 <geertu> milkylainen: IC

10:35 <milkylainen> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mtd/mtdcore.c#n656

10:36 <milkylainen> I'm not sure the current method of picking up of indexes works for non partitions?

10:37 <milkylainen> I only want the master to move.

10:43 <headless> milkylainen: there's #mtd channel on OFTC...

10:45 <javierm> geertu: I applied your v2 locally and typed this (untested for now) patch: https://paste.centos.org/view/raw/02a9a696

10:45 <javierm> geertu: is that what you had in mind?

10:46 <milkylainen> headless: tnx

10:55 <geertu> javierm: thx, something like that (+ freeing in crtc_destroy_state ;-)

11:07 <javierm> geertu: ups, right. I forgot to revert the change for ssd130x_primary_plane_destroy_state()

11:08 <javierm> geertu: that's what I meant that was going to be cleaner to do it in the plane's .atomic_check, since will have to iterate over the planes again in crtc_destroy_state

11:10 <javierm> I could move the buffers again to struct ssd130x_device but at least the intermediate buffer is really part of the plane atomic state...

11:10 <javierm> geertu: anyway, just wanted to know if we were on the same page. I could write a proper patch and post it once your changes are merged