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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
