Shutdown of firmware framebuffer has a bunch of problems. Because of this the framebuffer region might still be reserved even after drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
Don't consider pci_request_region() failure for the framebuffer region as fatal error to workaround this issue.
Reported-by: Marek Marczykowski-Górecki marmarek@invisiblethingslab.com Signed-off-by: Gerd Hoffmann kraxel@redhat.com --- drivers/gpu/drm/bochs/bochs_hw.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c index 952199cc0462..dce4672e3fc8 100644 --- a/drivers/gpu/drm/bochs/bochs_hw.c +++ b/drivers/gpu/drm/bochs/bochs_hw.c @@ -157,10 +157,8 @@ int bochs_hw_init(struct drm_device *dev) size = min(size, mem); }
- if (pci_request_region(pdev, 0, "bochs-drm") != 0) { - DRM_ERROR("Cannot request framebuffer\n"); - return -EBUSY; - } + if (pci_request_region(pdev, 0, "bochs-drm") != 0) + DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
bochs->fb_map = ioremap(addr, size); if (bochs->fb_map == NULL) {
Hi Gred.
On Fri, Mar 13, 2020 at 09:41:52AM +0100, Gerd Hoffmann wrote:
Shutdown of firmware framebuffer has a bunch of problems. Because of this the framebuffer region might still be reserved even after drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
Don't consider pci_request_region() failure for the framebuffer region as fatal error to workaround this issue.
Reported-by: Marek Marczykowski-Górecki marmarek@invisiblethingslab.com Signed-off-by: Gerd Hoffmann kraxel@redhat.com
drivers/gpu/drm/bochs/bochs_hw.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c index 952199cc0462..dce4672e3fc8 100644 --- a/drivers/gpu/drm/bochs/bochs_hw.c +++ b/drivers/gpu/drm/bochs/bochs_hw.c @@ -157,10 +157,8 @@ int bochs_hw_init(struct drm_device *dev)
There is a drm_device avilable.
size = min(size, mem);
}
- if (pci_request_region(pdev, 0, "bochs-drm") != 0) {
DRM_ERROR("Cannot request framebuffer\n");
return -EBUSY;
- }
- if (pci_request_region(pdev, 0, "bochs-drm") != 0)
DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
So you could use drm_WARN() which is what is preferred these days. With this fixed: Acked-by: Sam Ravnborg sam@ravnborg.org
Sam
On Fri, Mar 13, 2020 at 03:35:30PM +0100, Gerd Hoffmann wrote:
Hi,
- if (pci_request_region(pdev, 0, "bochs-drm") != 0)
DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
So you could use drm_WARN() which is what is preferred these days.
Nope, this isn't yet in -fixes.
Ups, did not see this was for -fixes. My ack stands without ths change then.
Sam
On Fri, Mar 13, 2020 at 09:41:52AM +0100, Gerd Hoffmann wrote:
Shutdown of firmware framebuffer has a bunch of problems. Because of this the framebuffer region might still be reserved even after drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
Is that still the fbdev lifetime fun where the cleanup might be delayed if the char device node is still open? -Daniel
Don't consider pci_request_region() failure for the framebuffer region as fatal error to workaround this issue.
Reported-by: Marek Marczykowski-Górecki marmarek@invisiblethingslab.com Signed-off-by: Gerd Hoffmann kraxel@redhat.com
drivers/gpu/drm/bochs/bochs_hw.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c index 952199cc0462..dce4672e3fc8 100644 --- a/drivers/gpu/drm/bochs/bochs_hw.c +++ b/drivers/gpu/drm/bochs/bochs_hw.c @@ -157,10 +157,8 @@ int bochs_hw_init(struct drm_device *dev) size = min(size, mem); }
- if (pci_request_region(pdev, 0, "bochs-drm") != 0) {
DRM_ERROR("Cannot request framebuffer\n");
return -EBUSY;
- }
if (pci_request_region(pdev, 0, "bochs-drm") != 0)
DRM_WARN("Cannot request framebuffer, boot fb still active?\n");
bochs->fb_map = ioremap(addr, size); if (bochs->fb_map == NULL) {
-- 2.18.2
On Tue, Mar 17, 2020 at 05:49:41PM +0100, Daniel Vetter wrote:
On Fri, Mar 13, 2020 at 09:41:52AM +0100, Gerd Hoffmann wrote:
Shutdown of firmware framebuffer has a bunch of problems. Because of this the framebuffer region might still be reserved even after drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
Is that still the fbdev lifetime fun where the cleanup might be delayed if the char device node is still open?
Yes.
cheers, Gerd
On Wed, Mar 18, 2020 at 7:49 AM Gerd Hoffmann kraxel@redhat.com wrote:
On Tue, Mar 17, 2020 at 05:49:41PM +0100, Daniel Vetter wrote:
On Fri, Mar 13, 2020 at 09:41:52AM +0100, Gerd Hoffmann wrote:
Shutdown of firmware framebuffer has a bunch of problems. Because of this the framebuffer region might still be reserved even after drm_fb_helper_remove_conflicting_pci_framebuffers() returned.
Is that still the fbdev lifetime fun where the cleanup might be delayed if the char device node is still open?
Yes.
In that case I think a FIXME comment that this should be upgraded again to a full error once fbdev unloading is fixed should be added. With that:
Reviewed-by: Daniel Vetter daniel.vetter@ffwll.ch
I guess you might want a cc: stable on this too? -Daniel
cheers, Gerd
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel@lists.freedesktop.org