Hi Mark.
On Sat, Jul 04, 2020 at 02:09:38PM +0100, Mark Cave-Ayland wrote:
On 04/07/2020 12:11, Mark Cave-Ayland wrote:
According to gdbstub the destination address in $g3 looks like this:
Breakpoint 1, 0x00000000007ad8e4 in cfb_imageblit () (gdb) i r $g3 g3 0x100220000 4297195520
The 0x100220000 address still isn't right. On sun4u the PCI address space is mapped at physical address 0x1fe00000000 and adding these two together gives 0x1ff00220000 which seems closer, but still not the correct framebuffer address 0x1ff22000000 which is reported at boot:
[ 9.007161] [drm] Found bochs VGA, ID 0xb0c5. [ 9.007840] [drm] Framebuffer size 16384 kB @ 0x1ff22000000, mmio @ 0x1ff23000000.
As a comparison, I took the last known good commit 7a0483ac4ffc~1: "drm/bochs: add basic prime support" and added some debug in cfb_imageblit() to allow me to pick out p->screen_base:
(gdb) i r $o1 o1 0x1ff22000000 2195298713600
When running git master with your patch in the same way I get a completely different value:
(gdb) i r $o1 o1 0x100050000 4295294976
Does p->screen_base need to be initialised differently when using the cfb helpers?
I think what is happening is that the bochs driver request a shadow copy for the frambuffer. And with the change to fbops we now use the cfb_ functions to write to the shadow framebuffer - which is not in any IO space. So this does not work.
So maybe all we need is the fix in drm_fb_helper_dirty_blit_real(). If you try to undo the change so fbops is set to &drm_fbdev_fb_ops, but keep the fix in drm_fb_helper_dirty_blit_real() how does it then behave?
I did not find time to follow your instructions to test this myself with qemu - sorry.
Sam
ATB,
Mark.