Hi On 19.10.20 21:43, Kevin Brace wrote: > Hi Sam, > > Thanks for asking the question. > The current OpenChrome DRM code has these two major issues. > > 1) It does not support atomic modesetting > > I do internally have working code to support atomic modesetting, but it is > not ready for committing into the upstream OpenChrome DRM repository. > In particular, it suffers from a freeze relating to a cursor plane. > The freeze is a bad kind that kern.log does not really tell me what is wrong. > If I disable hardware cursor, the atomic modesetting based OpenChrome DRM > appears to work okay. > In other words, I am getting close to getting atomic modesetting working, but > I am stuck.
This could be related to the memory problems. See below. Otherwise, I suggest to reduce the driver to the minimum functionality that is required for modesetting (even without HW cursors) and submit this code for review and merging. > > > 2) Double allocation of visible portion of frame buffer > > This is a big problem left behind from the previous developer who developed > OpenChrome prior to me. > For some reason, the developer wanted to allocate visible portion of the > frame buffer to be the maximum possible size supported by the detected > monitor when initializing the frame buffer inside OpenChrome DRM code. > I believe Radeon DRM does something similar to that. > The problem is, OpenChrome DDX allocates an equal sized frame buffer visible > portion during the DDX's initialization. > This means that we got two same sized visible portions allocated, but > OpenChrome DDX and OpenChrome DRM combined should really be allocating only > one. > At this point, OpenChrome is not supporting double buffering. > This double allocation of a visible portion of the frame buffer contributes > to a X Server crash when the screen is resized and 16 MB or less (i.e., 8 MB) > shared frame buffer is reserved by the system via BIOS setup. > I personally think letting OpenChrome DRM allocate the visible portion of the > frame buffer is the way to go, but if so, how do I get the DDX or shadow FB > to access the frame buffer visible portion allocated by OpenChrome DRM? > Any suggestions on what to do about this issue will be greatly appreciated. > Perhaps, I should post a question to dri-devel regarding this issue. > I really do not know what I should do at this point. The double allocation is expected. Atomic modesetting requires two framebuffers in video memory during the pageflip. You have to sort out the modes where 2 framebuffers do not fit into video memory at the same time. The mode_valid callback in struct drm_mode_config_funcs [1] is a good place to do this. Check the mode's pixels with the maximum BPC against the available memory. Example code is at [2]. You should also plane for common additional layers, such as HW cursors, to require video memory. So maybe test the mode against 80% of the video memory. Best regards Thomas [1] https://cgit.freedesktop.org/openchrome/drm-openchrome/tree/drivers/gpu/drm/openchrome/openchrome_fb.c?h=drm-next-5.10&id=22e0ee2460b4b70cde562b7a3818ae94c2786f46#n102 [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_gem_vram_helper.c?h=v5.9#n1285 > > Regards, > > Kevin Brace > Brace Computer Laboratory blog > https://bracecomputerlab.com > > >> Sent: Sunday, October 18, 2020 at 2:04 PM >> From: "Sam Ravnborg" <s...@ravnborg.org> >> To: "Kevin Brace" <kevinbr...@gmx.com> >> Cc: dri-devel@lists.freedesktop.org, "Dave Airlie" <airl...@redhat.com> >> Subject: Re: It appears drm-next TTM cleanup broke something . . . >> >> Hi Kevin. >> >> On Sun, Oct 18, 2020 at 09:15:17PM +0200, Kevin Brace wrote: >>> As usual, I pulled in DRM repository code for an out of tree OpenChrome DRM >>> repository a few days ago. >> >> I know you have been working on and off on the openchrome driver for a >> long time now. Any chance we will see the driver submitted for upstream soon? >> >> Sam >> > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
OpenPGP_0x680DC11D530B7A23.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
