Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 20 Feb 2002 13:34:02 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 20 Feb 2002 13:33:54 -0500 Received: from [62.47.19.142] ([62.47.19.142]:4737 "HELO twinny.dyndns.org") by vger.kernel.org with SMTP id ; Wed, 20 Feb 2002 13:33:46 -0500 Message-ID: <3C73EA06.82394673@webit.com> Date: Wed, 20 Feb 2002 19:25:10 +0100 From: Thomas Winischhofer X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,en-GB,en-US,de-AT,de-DE,de-CH,sv MIME-Version: 1.0 To: linux-kernel@vger.kernel.org CC: Jean Paul Sartre Subject: Re: sis_malloc / sis_free Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 20 Feb 2002, Christoph Pittracher wrote: > > Hello! Hi everyone, > > Yes, the sisfb/drm code has some design lacks. Well, well. I have by now come to the conclusion that this isn't really the case... > > Another lack is the necessary memory offset between framebuffer/drm and > > the X driver (see http://www.webit.at/~twinny/linuxsis630.shtml for > > details). > > Oh, okay. Should that memory offset be a source of processor time > waste for allocating memory when switching through FB and X, for an > example? If so, sharing the code (instead of duplicating it) is the ideal > approach. This has nothing whatsoever with processor time to do. It's to keep DRM/DRI from overwriting X's screen and off-screen buffers. > > I don't think that it would be a problem to duplicate the code. the > > sis_malloc / sis_free functions seems quite stable. I don't think that > > there will be big updates for this code. > > Hmm, but as you stated, I do not think code duplication should be > the best approach. No, it would not. You've obviously not understood the problems. It's not done by simply duplicating the sis_malloc/sis_free functions as these also require - detecting the type and size of the memory (of many different SiS chipsets), - initializing a heap (based on which you later allocate/free the memory) taking into account a possibe TurboQueue, a possible AGP command queue and the HWCursor memory area. Believe me: I know the code by heart right now, and moving the memory management out of the framebuffer driver will require HUGE parts of the code copied (not speaking about maintainance issues). Finally: I intend to implement (real) 2D accelleration in the framebuffer driver. Thus, I will need a >common< memory management (ie. ONE SINGLE heap) for both the framebuffer driver as well as the X driver. Otherwise these two will again overwrite each others video memory, very possibly leading into problems with the accellerator engines (which use parts of the video RAM for buffering). This can only be avoided by keeping the memory management inside the framebuffer driver. I don't think it's good to be forced to load the DRM module (if that one then contains memory management) for only being able to use the framebuffer driver... > > Thomas Winischhofer is working on that SiS stuff for > > about 2 months. I think it would be best if you contact him and ask > > what he thinks about that. I know that he said it would be a good idea > > to seperate the sisfb and sis_drm code but he doesn't have enough time > > to do it... It's not a time issue. As said, the concept isn't that bad for future development. I consider it wise enough to keep the drivers separated, as this also allows separate usage (framebuffer only, X only) without memory clashes. > If I have such time, I'll contact him. But for the moment, if the > code does not compile (still with 2.4.18-rc2-ac1) I'll duplicate the code > to get it working until a better solution raises. You don't have to do that. If you don't like a graphical console, simple start the framebuffer driver with "mode=none" (or as a kernel parameter "mode:none"). In this case, sisfb will only initialize the memory but leave the console alone. I don't recommend changing anything that big in the framebuffer driver at the moment. I am currently in close contact with SiS who help me fixing the (still) remaining problems with it - based on the existing code. In the very only case you'd like to reinclude a number of changes for a number of times - well, go ahead :) Thomas -- Thomas Winischhofer Vienna/Austria mailto:tw@webit.com *** http://www.webit.com/tw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/