Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 14 Mar 2001 08:19:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 14 Mar 2001 08:19:29 -0500 Received: from mailhost.mipsys.com ([62.161.177.33]:26051 "EHLO mailhost.mipsys.com") by vger.kernel.org with ESMTP id ; Wed, 14 Mar 2001 08:19:12 -0500 From: Benjamin Herrenschmidt To: Brad Douglas , Linux Fbdev development list , Subject: Re: [Linux-fbdev-devel] [RFC] fbdev & power management Date: Wed, 14 Mar 2001 14:17:56 +0100 Message-Id: <20010314131756.18036@mailhost.mipsys.com> In-Reply-To: In-Reply-To: X-Mailer: CTM PowerMail 3.0.8 MIME-Version: 1.0 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 >I think registering fbcon as a PM client and doing the above when the >fbdev suspend/resume hooks are called should work. A memory backup is >worked on until the resume is run and the backup is restored to the >display. > >So the fbdev drivers would register PM with fbcon, not PCI, correct? Either that, or the fbdev would register with PCI (or whatever), _and_ fbcon would too independently. In that scenario, fbcon would only handle things like disabling the cursor timer, while fbdev's would handle HW issues. THe only problem is for fbcon to know that a given fbdev is asleep, this could be an exported per-fbdev flag, an error code, or whatever. In this case, fbcon can either buffer text input, or fallback to the cfb working on the backed up fb image (that last thing can be handled entirely within the fbdev I guess). Ben. - 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/