search for: drm_warn

...xcept for bpp==32 (XRGB8888), where it is the number of bits per pixel. It's therefore best to interpret it like a color-mode enum. > > So, I'm all for a new ioctl, but I don't right away see why the > current ioctl couldn't be used. Which makes me wonder about the > drm_warn() in your patch, and the "userspace throws in arbitrary > values for bpp and relies on the kernel to figure it out". Maybe I'm > missing something here. I was unsure about the drm_warn() as well. It's not really wrong to have odd bpp values, but handing in an unknown bpp...

...out color depth here? We're just allocating memory. Doesn't DIV_ROUND_UP(args->bpp, SZ_8) work fine for XRGB1555 too? >> So, I'm all for a new ioctl, but I don't right away see why the >> current ioctl couldn't be used. Which makes me wonder about the >> drm_warn() in your patch, and the "userspace throws in arbitrary >> values for bpp and relies on the kernel to figure it out". Maybe I'm >> missing something here. > > I was unsure about the drm_warn() as well. It's not really wrong to have > odd bpp values, but ha...

...rameter, which as the same odd semantics. The fallback that uses bpp directly will hopefully be the exception. > >>> So, I'm all for a new ioctl, but I don't right away see why the >>> current ioctl couldn't be used. Which makes me wonder about the >>> drm_warn() in your patch, and the "userspace throws in arbitrary >>> values for bpp and relies on the kernel to figure it out". Maybe I'm >>> missing something here. >> >> I was unsure about the drm_warn() as well. It's not really wrong to >> have odd...

...> > void omap_fbdev_setup(struct drm_device *dev) > { > + struct omap_drm_private *priv = dev->dev_private; > struct omap_fbdev *fbdev; > struct drm_fb_helper *helper; > int ret; > @@ -345,24 +345,28 @@ void omap_fbdev_setup(struct drm_device *dev) > drm_WARN(dev, !dev->registered, "Device has not been registered.\n"); > drm_WARN(dev, dev->fb_helper, "fb_helper is already set!\n"); > > - fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL); > + fbdev = drmm_kzalloc(dev, sizeof(*fbdev), GFP_KERNEL); > if (!fbdev)...

...h and height do give an exact pitch and size, do they not? It does require the userspace to handle the subsampling and planes, though, so far from perfect. So, I'm all for a new ioctl, but I don't right away see why the current ioctl couldn't be used. Which makes me wonder about the drm_warn() in your patch, and the "userspace throws in arbitrary values for bpp and relies on the kernel to figure it out". Maybe I'm missing something here. > parameter is not very precise. The solution would be a new ioctl call > that receives the DRM format and returns a buffer fo...

...e559 100644 --- a/drivers/gpu/drm/bochs/bochs_hw.c +++ b/drivers/gpu/drm/bochs/bochs_hw.c @@ -157,8 +157,7 @@ int bochs_hw_init(struct drm_device *dev) } if (pci_request_region(pdev, 0, "bochs-drm") != 0) { - DRM_ERROR("Cannot request framebuffer\n"); - return -EBUSY; + DRM_WARN("Cannot request framebuffer, boot framebuffer still active?\n"); } bochs->fb_map = ioremap(addr, size); -- 2.18.1

...e559 100644 --- a/drivers/gpu/drm/bochs/bochs_hw.c +++ b/drivers/gpu/drm/bochs/bochs_hw.c @@ -157,8 +157,7 @@ int bochs_hw_init(struct drm_device *dev) } if (pci_request_region(pdev, 0, "bochs-drm") != 0) { - DRM_ERROR("Cannot request framebuffer\n"); - return -EBUSY; + DRM_WARN("Cannot request framebuffer, boot framebuffer still active?\n"); } bochs->fb_map = ioremap(addr, size); -- 2.18.1

...out() to get the tiling parameters. * Have 2 set_pixel() functions, depending on GPU family. v4: * Refactor and move the tiling code from nouveau_display.c to dispnv50/tile.h, so that in can be re-used by drm_panic. (Lyude) * Refactor get_scanout_buffer() to use the new dispnv50/tile.h * use drm_warn() instead of pr_warn() in get_scanout_buffer Jocelyn Falempe (3): drm/panic: Add ABGR2101010 support drm/nouveau/disp: Move tiling functions to dispnv50/tile.h drm/nouveau: Add drm_panic support for nv50+ drivers/gpu/drm/drm_panic.c | 10 ++ drivers/gpu/drm/nouveau/dispnv50...

...GB format from drm_driver_color_mode_format(), and get a drm_format_info_min_pitch() for an RGB format. >>>> So, I'm all for a new ioctl, but I don't right away see why the >>>> current ioctl couldn't be used. Which makes me wonder about the >>>> drm_warn() in your patch, and the "userspace throws in arbitrary >>>> values for bpp and relies on the kernel to figure it out". Maybe I'm >>>> missing something here. >>> >>> I was unsure about the drm_warn() as well. It's not really wrong to &...

...bochs_hw.c > +++ b/drivers/gpu/drm/bochs/bochs_hw.c > @@ -157,8 +157,7 @@ int bochs_hw_init(struct drm_device *dev) > } > > if (pci_request_region(pdev, 0, "bochs-drm") != 0) { > - DRM_ERROR("Cannot request framebuffer\n"); > - return -EBUSY; > + DRM_WARN("Cannot request framebuffer, boot framebuffer still active?\n"); > } > > bochs->fb_map = ioremap(addr, size); > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 N?rnberg, Germany (HRB 36809, AG N?rnberg) Gesch...

...Don't support compressed format, or multiplane yet. */ > + if (nvbo->comp || fb->format->num_planes != 1) > + return -EOPNOTSUPP; > + > + if (nouveau_bo_map(nvbo)) { > + pr_warn("nouveau bo map failed, panic won't be displayed\n"); I think we would want drm_warn() here With the above changes handled/considered - Reviewed-by: Lyude Paul <lyude at redhat.com> Would be good to have james take another look at this if he's got the time, but I think this looks alright :) > + return -ENOMEM; > + } > + > + if (nvbo->kmap.bo_kmap_type...

...format, or multiplane yet. */ >> + if (nvbo->comp || fb->format->num_planes != 1) >> + return -EOPNOTSUPP; >> + >> + if (nouveau_bo_map(nvbo)) { >> + pr_warn("nouveau bo map failed, panic won't be displayed\n"); > > I think we would want drm_warn() here sure I will change that. > > With the above changes handled/considered - > > Reviewed-by: Lyude Paul <lyude at redhat.com> Thanks a lot, I will send a v4 later this week. > > Would be good to have james take another look at this if he's got the time, > but...

...return 0; > > - bo = gem_to_vbox_bo(to_vbox_framebuffer(new_state->fb)->obj); > - ret = vbox_bo_pin(bo, TTM_PL_FLAG_VRAM); > + gbo = drm_gem_ttm_of_gem(to_vbox_framebuffer(new_state->fb)->obj); > + ret = drm_gem_ttm_pin(gbo, TTM_PL_FLAG_VRAM); > if (ret) > DRM_WARN("Error %d pinning new fb, out of video mem?\n", ret); > > @@ -320,13 +321,13 @@ static int vbox_primary_prepare_fb(struct drm_plane *plane, > static void vbox_primary_cleanup_fb(struct drm_plane *plane, > struct drm_plane_state *old_state) > { > - struct...

...add63 100644 --- a/drivers/gpu/drm/qxl/qxl_irq.c +++ b/drivers/gpu/drm/qxl/qxl_irq.c @@ -57,10 +57,9 @@ irqreturn_t qxl_irq_handler(int irq, void *arg) * to avoid endless loops). */ qdev->irq_received_error++; - qxl_io_log(qdev, "%s: driver is in bug mode.\n", __func__); + DRM_WARN("driver is in bug mode\n"); } if (pending & QXL_INTERRUPT_CLIENT_MONITORS_CONFIG) { - qxl_io_log(qdev, "QXL_INTERRUPT_CLIENT_MONITORS_CONFIG\n"); schedule_work(&qdev->client_monitors_config_work); } qdev->ram_header->int_mask = QXL_INTERRUPT_MASK; --...

...add63 100644 --- a/drivers/gpu/drm/qxl/qxl_irq.c +++ b/drivers/gpu/drm/qxl/qxl_irq.c @@ -57,10 +57,9 @@ irqreturn_t qxl_irq_handler(int irq, void *arg) * to avoid endless loops). */ qdev->irq_received_error++; - qxl_io_log(qdev, "%s: driver is in bug mode.\n", __func__); + DRM_WARN("driver is in bug mode\n"); } if (pending & QXL_INTERRUPT_CLIENT_MONITORS_CONFIG) { - qxl_io_log(qdev, "QXL_INTERRUPT_CLIENT_MONITORS_CONFIG\n"); schedule_work(&qdev->client_monitors_config_work); } qdev->ram_header->int_mask = QXL_INTERRUPT_MASK; --...

Hi Am 15.01.25 um 11:13 schrieb Tomi Valkeinen: > Hi! > > On 09/01/2025 16:57, Thomas Zimmermann wrote: >> Call drm_mode_size_dumb() to compute dumb-buffer scanline pitch and >> buffer size. Align the pitch according to hardware requirements. >> >> Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> >> Cc: Laurent Pinchart <laurent.pinchart

...o + * finish. So, just defer this event for when we runtime + * resume again. It will be handled by fbcon_work. + */ + NV_DEBUG(drm, "fbcon HPD event deferred until runtime resume\n"); + fbcon->hotplug_waiting = true; + pm_runtime_put_noidle(drm->dev->dev); + } else { + DRM_WARN("fbcon HPD event lost due to RPM failure: %d\n", + ret); + } + + mutex_unlock(&fbcon->hotplug_lock); +} + +void +nouveau_fbcon_hotplug_resume(struct nouveau_fbdev *fbcon) +{ + struct nouveau_drm *drm; + + if (!fbcon) + return; + drm = nouveau_drm(fbcon->helper.dev); + + mute...

...o + * finish. So, just defer this event for when we runtime + * resume again. It will be handled by fbcon_work. + */ + NV_DEBUG(drm, "fbcon HPD event deferred until runtime resume\n"); + fbcon->hotplug_waiting = true; + pm_runtime_put_noidle(drm->dev->dev); + } else { + DRM_WARN("fbcon HPD event lost due to RPM failure: %d\n", + ret); + } + + mutex_unlock(&fbcon->hotplug_lock); +} + +void +nouveau_fbcon_hotplug_resume(struct nouveau_fbdev *fbcon) +{ + struct nouveau_drm *drm; + + if (!fbcon) + return; + drm = nouveau_drm(fbcon->helper.dev); + + mute...

Add drm_panic support, for nv50+ cards. It's enough to get the panic screen while running Gnome/Wayland on a GTX 1650. It doesn't support multi-plane or compressed format. Support for other formats and older cards will come later. Tiling is only tested on GTX1650, and might be wrong for other cards. Signed-off-by: Jocelyn Falempe <jfalempe at redhat.com> --- v2: * Rebase and drop

...o - * finish. So, just defer this event for when we runtime - * resume again. It will be handled by fbcon_work. - */ - NV_DEBUG(drm, "fbcon HPD event deferred until runtime resume\n"); - fbcon->hotplug_waiting = true; - pm_runtime_put_noidle(drm->dev->dev); - } else { - DRM_WARN("fbcon HPD event lost due to RPM failure: %d\n", - ret); - } - - mutex_unlock(&fbcon->hotplug_lock); -} - -void -nouveau_fbcon_hotplug_resume(struct nouveau_fbdev *fbcon) -{ - struct nouveau_drm *drm; - - if (!fbcon) - return; - drm = nouveau_drm(fbcon->helper.dev); - - mute...