search for: drm_dbg

...lues 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 value might point to a user-space error. At least there should be a drm_dbg(). > >> parameter is not very precise. The solution would be a new ioctl call >> that receives the DRM format and returns a buffer for each individual >> plane. > > Yes, I think that makes sense. That's a long road, though =). So my > question is, is CREATE_DUM...

...save_stack+0x8c/0xb0 > ? vprintk_func+0x96/0x1bf > ? __printk_safe_exit+0x10/0x10 > intel_atomic_check+0x234/0x4750 [i915] > ? printk+0x9f/0xc5 > ? kmsg_dump_rewind_nolock+0xd9/0xd9 > ? _raw_spin_lock_irqsave+0xa4/0x140 > ? drm_atomic_check_only+0xb1/0x28b0 [drm] > ? drm_dbg+0x186/0x1b0 [drm] > ? drm_dev_dbg+0x200/0x200 [drm] > ? intel_link_compute_m_n+0xb0/0xb0 [i915] > ? drm_mode_put_tile_group+0x20/0x20 [drm] > ? skl_plane_format_mod_supported+0x17f/0x1b0 [i915] > ? drm_plane_check_pixel_format+0x14a/0x310 [drm] > drm_atomic_check_only+0x13c4...

...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 value might point to a > user-space error. At least there should be a drm_dbg(). > >> >>> parameter is not very precise. The solution would be a new ioctl call >>> that receives the DRM format and returns a buffer for each individual >>> plane. >> >> Yes, I think that makes sense. That's a long road, though =). So my &g...

...per] ? __printk_safe_exit+0x10/0x10 ? save_stack+0x8c/0xb0 ? vprintk_func+0x96/0x1bf ? __printk_safe_exit+0x10/0x10 intel_atomic_check+0x234/0x4750 [i915] ? printk+0x9f/0xc5 ? kmsg_dump_rewind_nolock+0xd9/0xd9 ? _raw_spin_lock_irqsave+0xa4/0x140 ? drm_atomic_check_only+0xb1/0x28b0 [drm] ? drm_dbg+0x186/0x1b0 [drm] ? drm_dev_dbg+0x200/0x200 [drm] ? intel_link_compute_m_n+0xb0/0xb0 [i915] ? drm_mode_put_tile_group+0x20/0x20 [drm] ? skl_plane_format_mod_supported+0x17f/0x1b0 [i915] ? drm_plane_check_pixel_format+0x14a/0x310 [drm] drm_atomic_check_only+0x13c4/0x28b0 [drm] ? drm_state_inf...

...gure 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 value might point >> to a user-space error. At least there should be a drm_dbg(). >> >>> >>>> parameter is not very precise. The solution would be a new ioctl >>>> call that receives the DRM format and returns a buffer for each >>>> individual plane. >>> >>> Yes, I think that makes sense. That's a long...

...per] ? __printk_safe_exit+0x10/0x10 ? save_stack+0x8c/0xb0 ? vprintk_func+0x96/0x1bf ? __printk_safe_exit+0x10/0x10 intel_atomic_check+0x234/0x4750 [i915] ? printk+0x9f/0xc5 ? kmsg_dump_rewind_nolock+0xd9/0xd9 ? _raw_spin_lock_irqsave+0xa4/0x140 ? drm_atomic_check_only+0xb1/0x28b0 [drm] ? drm_dbg+0x186/0x1b0 [drm] ? drm_dev_dbg+0x200/0x200 [drm] ? intel_link_compute_m_n+0xb0/0xb0 [i915] ? drm_mode_put_tile_group+0x20/0x20 [drm] ? skl_plane_format_mod_supported+0x17f/0x1b0 [i915] ? drm_plane_check_pixel_format+0x14a/0x310 [drm] drm_atomic_check_only+0x13c4/0x28b0 [drm] ? drm_state_inf...

...k_func+0x96/0x1bf > > ? __printk_safe_exit+0x10/0x10 > > intel_atomic_check+0x234/0x4750 [i915] > > ? printk+0x9f/0xc5 > > ? kmsg_dump_rewind_nolock+0xd9/0xd9 > > ? _raw_spin_lock_irqsave+0xa4/0x140 > > ? drm_atomic_check_only+0xb1/0x28b0 [drm] > > ? drm_dbg+0x186/0x1b0 [drm] > > ? drm_dev_dbg+0x200/0x200 [drm] > > ? intel_link_compute_m_n+0xb0/0xb0 [i915] > > ? drm_mode_put_tile_group+0x20/0x20 [drm] > > ? skl_plane_format_mod_supported+0x17f/0x1b0 [i915] > > ? drm_plane_check_pixel_format+0x14a/0x310 [drm] > >...

This fixes the extra issues I discovered upstream after the introduction of my rework of the atomic VCPI helpers that occur during suspend/resume. This time around, we use a slightly different but much less complicated approach for fixing said issues. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude Paul (4): drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()

This fixes the extra issues I discovered upstream after the introduction of my rework of the atomic VCPI helpers that occur during suspend/resume. This time around, we use a slightly different but much less complicated approach for fixing said issues. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude Paul (4): drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()

...aybe 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 value might point >>> to a user-space error. At least there should be a drm_dbg(). >>> >>>> >>>>> parameter is not very precise. The solution would be a new ioctl >>>>> call that receives the DRM format and returns a buffer for each >>>>> individual plane. >>>> >>>> Yes, I think that ma...

Hi, On 15/01/2025 12:26, Thomas Zimmermann wrote: > 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:

From: Sui Jingfeng <suijingfeng at loongson.cn> On a machine with multiple GPUs, a Linux user has no control over which one is primary at boot time. This series tries to solve above mentioned problem by introduced the ->be_primary() function stub. The specific device drivers can provide an implementation to hook up with this stub by calling the vga_client_register() function. Once the