Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757923AbZFVS7U (ORCPT ); Mon, 22 Jun 2009 14:59:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752261AbZFVS7H (ORCPT ); Mon, 22 Jun 2009 14:59:07 -0400 Received: from mail-bw0-f213.google.com ([209.85.218.213]:41207 "EHLO mail-bw0-f213.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752730AbZFVS7G convert rfc822-to-8bit (ORCPT ); Mon, 22 Jun 2009 14:59:06 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=r9X4bRVngUx+iMJglj1Qc2B726c2fYevKu1GNTgkPARj1lAqGtrGaA9fvKQRBMRkE7 mZYTDO8+mmZzh7dOc+RU/MXYIdEy6XSAkYWbLEZwo80JOSs8IRmR5wcazXDUGbVjEOFg yUmTly1Y4wUUKmg56N4cbg9DCcEU/gxDLTlkU= MIME-Version: 1.0 In-Reply-To: References: <4A3DABE1.50309@mit.edu> <4A3F3E3A.2030202@shipmail.org> Date: Mon, 22 Jun 2009 14:59:07 -0400 X-Google-Sender-Auth: 4016159a29a95396 Message-ID: Subject: Re: [git pull] drm: previous pull req + 1. From: Andrew Lutomirski To: Linus Torvalds Cc: =?ISO-8859-1?Q?Thomas_Hellstr=F6m?= , Dave Airlie , Alex Deucher , dri-devel@lists.sf.net, Jerome Glisse , Linux Kernel Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1169 Lines: 31 2009/6/22 Linus Torvalds : > > > On Mon, 22 Jun 2009, Thomas Hellstr?m wrote: >> >> It would be very helpful if we could introduce an fbdev mutex that protects >> fbdev accesses to the kernel map and to the fbdev acceleration functions. > > Not going to happen. > > Why? 'printk'. > > If you can't handle printk, then you're basically useless. And printk > absolutely -has- to work in bad situations (the most important messages > could happen in any context). What if we only guaranteed that the framebuffer is mapped when it's showing on the screen? printk doesn't need to write to the framebuffer immediately when X isn't running (since the framebuffer isn't shown) and presumably the framebuffer needs to be pinned somewhere when it's being displayed anyway. This would involve fbcon knowing how to buffer text to be shown later so that printk still works in interrupt context. --Andy -- 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/