Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264256AbUILXxq (ORCPT ); Sun, 12 Sep 2004 19:53:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264299AbUILXxq (ORCPT ); Sun, 12 Sep 2004 19:53:46 -0400 Received: from holly.csn.ul.ie ([136.201.105.4]:59831 "EHLO holly.csn.ul.ie") by vger.kernel.org with ESMTP id S264256AbUILXxn (ORCPT ); Sun, 12 Sep 2004 19:53:43 -0400 Date: Mon, 13 Sep 2004 00:53:41 +0100 (IST) From: Dave Airlie X-X-Sender: airlied@skynet To: Linus Torvalds Cc: Jon Smirl , Christoph Hellwig , Alan Cox , =?ISO-8859-1?Q?Felix_K=FChling?= , DRI Devel , lkml Subject: Re: radeon-pre-2 In-Reply-To: Message-ID: References: <9e47339104090919015b5b5a4d@mail.gmail.com> <9e47339104091010221f03ec06@mail.gmail.com> <1094835846.17932.11.camel@localhost.localdomain> <9e47339104091011402e8341d0@mail.gmail.com> <20040911132727.A1783@infradead.org> <9e47339104091109111c46db54@mail.gmail.com> <9e473391040911105448c3f089@mail.gmail.com> <9e4733910409111721534b2e6d@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1944 Lines: 45 > > > > We already have a mechanism for this: suspend/resume. > > Jon, you're not making sense any more. > This discussion is just ridiculous, and I don't think it's worth cc'ing me > if people can't try to work together, since I'm sadly not going to have > time to actually implement any of this myself. > > If you are claiming that we should suspend/resume the whole chip just > because two different programs want to access it, you're just crazy. > > We clearly _do_ have different subsystems already working together > accessign the same chip, and they are _not_ doing stupid things like you > are suggesting. They _work_. Today. No suspend/resume involved. I think you are missing Jon's point here, we do complete suspend/resume nowdays, just look at the radeon DDX Enter/Leave VT code, now I don't particularly want that code in the kernel, it assumes nothing about the chip after you switch back to X and restores the whole lot.. so we are doing this today, they work because of that code, the DRM doesn't do anything unless X is running in most scenarios today, so the DRM and fb never do anything that simulatenous that you might notice as when you switch away from X the drm is locked against working, and the fb can take over, in the future this isn't going to be true, the mesa-solo work being one case where fb and drm are going to be accessed from the one process.... So his statement didn't seem that idiotic to me... he might have explained himself better, and may have assumed everyone understands the internals of the X DDXes, Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person - 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/