Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S268168AbUIKPjY (ORCPT ); Sat, 11 Sep 2004 11:39:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268170AbUIKPjY (ORCPT ); Sat, 11 Sep 2004 11:39:24 -0400 Received: from the-village.bc.nu ([81.2.110.252]:26035 "EHLO localhost.localdomain") by vger.kernel.org with ESMTP id S268168AbUIKPjQ (ORCPT ); Sat, 11 Sep 2004 11:39:16 -0400 Subject: Re: radeon-pre-2 From: Alan Cox To: Vladimir Dergachev Cc: Michel =?ISO-8859-1?Q?D=E4nzer?= , Dave Airlie , Jon Smirl , Felix =?ISO-8859-1?Q?K=FChling?= , DRI Devel , lkml , Linus Torvalds In-Reply-To: References: <9e47339104090919015b5b5a4d@mail.gmail.com> <20040910153135.4310c13a.felix@trabant> <9e47339104091008115b821912@mail.gmail.com> <1094829278.17801.18.camel@localhost.localdomain> <9e4733910409100937126dc0e7@mail.gmail.com> <1094832031.17883.1.camel@localhost.localdomain> <9e47339104091010221f03ec06@mail.gmail.com> <1094835846.17932.11.camel@localhost.localdomain> <9e47339104091011402e8341d0@mail.gmail.com> <1094853588.18235.12.camel@localhost.localdomain> <1094873412.4838.49.camel@admin.tel.thor.asgaard.local> <1094883136.6095.75.camel@admin.tel.thor.asgaard.local> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1094913414.21157.65.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Sat, 11 Sep 2004 15:36:55 +0100 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1059 Lines: 25 On Sad, 2004-09-11 at 08:11, Vladimir Dergachev wrote: > The thing is I know of no way to provide arbitration in such a way as to > permit other code to access PLL registers directly. This arises solely because the DRM and framebuffer drivers cannot find each other and have no shared structures. The moment you have that it becomes down(&dev->foo->pll_lock); > Thus at the very least you would want to mandate the availability of mode > setting part of FB when DRM is loaded - and they you can just as well link > the relevant code together. You are making a generic assumption for a single card specific problem in a specific situation. That leads to bad decisions for embedded. It does argue for mode setting and fb to be separate too. (Remember for most embedded devices mode setting code is trivial) - 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/