From: Ingo Molnar <mingo@kernel.org>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: Takashi Iwai <tiwai@suse.de>,
Stephen Warren <swarren@wwwdotorg.org>,
"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: cirrusdrmfb broken with simplefb
Date: Wed, 18 Dec 2013 09:29:41 +0000 [thread overview]
Message-ID: <20131218092941.GA19210@gmail.com> (raw)
In-Reply-To: <CANq1E4TFKDduy71jCXy+8CMS1_OFxWEpsHY3AA0RUJPW4VE8hg@mail.gmail.com>
* David Herrmann <dh.herrmann@gmail.com> wrote:
> Hi
>
> On Wed, Dec 18, 2013 at 8:42 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > Hi,
> >
> > with the recent enablement of simplefb on x86, cirrusdrmfb on QEMU/KVM
> > gets broken now, as reported at:
> > https://bugzilla.novell.com/show_bug.cgi?id…5821
> >
> > The cirrus VGA resource is reserved at first as "BOOTFB" in
> > arch/x86/kernel/sysfb_simplefb.c, which is taken by simplefb platform
> > device. This resource is, however, never released until the platform
> > device is destroyed, and the framebuffer switching doesn't trigger
> > it. It calls fb's destroy callback, at most. Then, cirrus driver
> > tries to assign the resource, fails and gives up, resulting in a
> > complete blank screen.
> >
> > The same problem should exist on other KMS drivers like mgag200 or
> > ast, not only cirrus. Intel graphics doesn't hit this problem just
> > because the reserved iomem by BOOTFB isn't required by i915 driver.
> >
> > The patch below is a quick attempt to solve the issue. It adds a new
> > API function for releasing resources of platform_device, and call it
> > in destroy op of simplefb. But, forcibly releasing resources of a
> > parent device doesn't sound like a correct design. We may take such
> > as a band aid, but definitely need a more fundamental fix.
> >
> > Any thoughts?
>
> That bug always existed, simplefb is just the first driver to hit it
> (vesafb/efifb didn't use resources). I'm aware of the issue but as a
> workaround you can simply disable CONFIG_X86_SYSFB. That restores
> the old behavior.
This looks like a regression, so we'll either need a fix or we'll have
to mark CONFIG_X86_SYSFB as CONFIG_BROKEN.
> As a proper fix, I'd propose something like:
> dev = platform_find_device("platform-framebuffer");
> platform_remove_device(dev);
>
> And we wrap this as:
> sysfb_remove_framebuffers()
> in arch/x86/kernel/sysfb.c
>
> This should cause a ->remove() event for the platform-driver and
> correctly release the resources. Comments?
> I will try to write a patch and send it later.
A fix would be awesome.
Thanks,
Ingo
WARNING: multiple messages have this Message-ID (diff)
From: Ingo Molnar <mingo@kernel.org>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: Takashi Iwai <tiwai@suse.de>,
Stephen Warren <swarren@wwwdotorg.org>,
"linux-fbdev@vger.kernel.org" <linux-fbdev@vger.kernel.org>,
the arch/x86 maintainers <x86@kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: cirrusdrmfb broken with simplefb
Date: Wed, 18 Dec 2013 10:29:41 +0100 [thread overview]
Message-ID: <20131218092941.GA19210@gmail.com> (raw)
In-Reply-To: <CANq1E4TFKDduy71jCXy+8CMS1_OFxWEpsHY3AA0RUJPW4VE8hg@mail.gmail.com>
* David Herrmann <dh.herrmann@gmail.com> wrote:
> Hi
>
> On Wed, Dec 18, 2013 at 8:42 AM, Takashi Iwai <tiwai@suse.de> wrote:
> > Hi,
> >
> > with the recent enablement of simplefb on x86, cirrusdrmfb on QEMU/KVM
> > gets broken now, as reported at:
> > https://bugzilla.novell.com/show_bug.cgi?id=855821
> >
> > The cirrus VGA resource is reserved at first as "BOOTFB" in
> > arch/x86/kernel/sysfb_simplefb.c, which is taken by simplefb platform
> > device. This resource is, however, never released until the platform
> > device is destroyed, and the framebuffer switching doesn't trigger
> > it. It calls fb's destroy callback, at most. Then, cirrus driver
> > tries to assign the resource, fails and gives up, resulting in a
> > complete blank screen.
> >
> > The same problem should exist on other KMS drivers like mgag200 or
> > ast, not only cirrus. Intel graphics doesn't hit this problem just
> > because the reserved iomem by BOOTFB isn't required by i915 driver.
> >
> > The patch below is a quick attempt to solve the issue. It adds a new
> > API function for releasing resources of platform_device, and call it
> > in destroy op of simplefb. But, forcibly releasing resources of a
> > parent device doesn't sound like a correct design. We may take such
> > as a band aid, but definitely need a more fundamental fix.
> >
> > Any thoughts?
>
> That bug always existed, simplefb is just the first driver to hit it
> (vesafb/efifb didn't use resources). I'm aware of the issue but as a
> workaround you can simply disable CONFIG_X86_SYSFB. That restores
> the old behavior.
This looks like a regression, so we'll either need a fix or we'll have
to mark CONFIG_X86_SYSFB as CONFIG_BROKEN.
> As a proper fix, I'd propose something like:
> dev = platform_find_device("platform-framebuffer");
> platform_remove_device(dev);
>
> And we wrap this as:
> sysfb_remove_framebuffers()
> in arch/x86/kernel/sysfb.c
>
> This should cause a ->remove() event for the platform-driver and
> correctly release the resources. Comments?
> I will try to write a patch and send it later.
A fix would be awesome.
Thanks,
Ingo
next prev parent reply other threads:[~2013-12-18 9:29 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-18 7:42 cirrusdrmfb broken with simplefb Takashi Iwai
2013-12-18 7:42 ` Takashi Iwai
2013-12-18 8:21 ` David Herrmann
2013-12-18 8:21 ` David Herrmann
2013-12-18 8:44 ` Takashi Iwai
2013-12-18 8:44 ` Takashi Iwai
2013-12-18 8:48 ` Geert Uytterhoeven
2013-12-18 8:48 ` Geert Uytterhoeven
2013-12-18 10:17 ` Takashi Iwai
2013-12-18 10:17 ` Takashi Iwai
2013-12-18 10:21 ` David Herrmann
2013-12-18 10:21 ` David Herrmann
2013-12-18 11:39 ` Takashi Iwai
2013-12-18 11:39 ` Takashi Iwai
2013-12-18 11:48 ` [RFC] x86: sysfb: remove sysfb when probing real hw David Herrmann
2013-12-18 11:48 ` David Herrmann
2013-12-18 11:54 ` Ingo Molnar
2013-12-18 11:54 ` Ingo Molnar
2013-12-18 13:03 ` Takashi Iwai
2013-12-18 13:03 ` Takashi Iwai
2013-12-18 13:34 ` David Herrmann
2013-12-18 13:34 ` David Herrmann
2013-12-18 14:02 ` Takashi Iwai
2013-12-18 14:02 ` Takashi Iwai
2013-12-18 13:50 ` [PATCH v2] " David Herrmann
2013-12-18 13:50 ` David Herrmann
2013-12-18 14:15 ` David Herrmann
2013-12-18 14:15 ` David Herrmann
2013-12-18 14:21 ` Takashi Iwai
2013-12-18 14:21 ` Takashi Iwai
2013-12-19 10:13 ` [PATCH v3] " David Herrmann
2013-12-19 10:13 ` David Herrmann
2013-12-19 16:36 ` Ingo Molnar
2013-12-19 16:36 ` Ingo Molnar
2013-12-19 17:03 ` David Herrmann
2013-12-19 17:03 ` David Herrmann
2013-12-19 17:09 ` Ingo Molnar
2013-12-19 17:09 ` Ingo Molnar
2013-12-19 17:18 ` David Herrmann
2013-12-19 17:18 ` David Herrmann
2013-12-19 17:24 ` [PATCH v4] " David Herrmann
2013-12-19 17:24 ` David Herrmann
2013-12-19 18:33 ` Ingo Molnar
2013-12-19 18:33 ` Ingo Molnar
2013-12-20 14:46 ` David Herrmann
2013-12-20 14:46 ` David Herrmann
2013-12-19 18:54 ` [PATCH v3] " Stephen Warren
2013-12-19 18:54 ` Stephen Warren
2013-12-19 18:55 ` Ingo Molnar
2013-12-19 18:55 ` Ingo Molnar
2013-12-19 19:09 ` Stephen Warren
2013-12-19 19:09 ` Stephen Warren
2013-12-19 19:19 ` Ingo Molnar
2013-12-19 19:19 ` Ingo Molnar
2013-12-18 9:29 ` Ingo Molnar [this message]
2013-12-18 9:29 ` cirrusdrmfb broken with simplefb Ingo Molnar
2013-12-19 0:03 ` One Thousand Gnomes
2013-12-19 10:46 ` David Herrmann
2013-12-19 10:46 ` David Herrmann
2013-12-19 11:06 ` Takashi Iwai
2013-12-19 11:06 ` Takashi Iwai
2013-12-19 12:36 ` David Herrmann
2013-12-19 12:36 ` David Herrmann
2013-12-19 13:22 ` Takashi Iwai
2013-12-19 13:22 ` Takashi Iwai
2013-12-19 13:37 ` David Herrmann
2013-12-19 13:37 ` David Herrmann
2013-12-19 14:03 ` Takashi Iwai
2013-12-19 14:03 ` Takashi Iwai
2013-12-19 14:13 ` David Herrmann
2013-12-19 14:13 ` David Herrmann
2013-12-19 14:22 ` Takashi Iwai
2013-12-19 14:22 ` Takashi Iwai
2013-12-19 12:31 ` Ingo Molnar
2013-12-19 12:31 ` Ingo Molnar
2013-12-19 12:39 ` David Herrmann
2013-12-19 12:39 ` David Herrmann
2013-12-19 12:44 ` Ingo Molnar
2013-12-19 12:44 ` Ingo Molnar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131218092941.GA19210@gmail.com \
--to=mingo@kernel.org \
--cc=dh.herrmann@gmail.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=swarren@wwwdotorg.org \
--cc=tiwai@suse.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.