On Fri, Mar 01, 2024 at 02:03:12PM +0100, Jocelyn Falempe wrote:
> Thanks for the patch.
>
> I think it misses to initialize the lock, so we need to add a
> raw_spin_lock_init() in the drm device initialization.
>
> Also I'm wondering if it make sense to put that under the CONFIG_DRM_PANIC
>
On Tue, Mar 05, 2024 at 09:20:04AM +0106, John Ogness wrote:
> Hi Daniel,
>
> Great to see this moving forward!
>
> On 2024-03-01, Daniel Vetter wrote:
> > But for the initial cut of a drm panic printing support I don't think
> > we need that, because the critical sections are extremely small
Hi Daniel,
Great to see this moving forward!
On 2024-03-01, Daniel Vetter wrote:
> But for the initial cut of a drm panic printing support I don't think
> we need that, because the critical sections are extremely small and
> only happen once per display refresh. So generally just 60 tiny locked
Thanks for the patch.
I think it misses to initialize the lock, so we need to add a
raw_spin_lock_init() in the drm device initialization.
Also I'm wondering if it make sense to put that under the
CONFIG_DRM_PANIC flag, so that if you don't enable it, panic_lock() and
panic_unlock() would
Rough sketch for the locking of drm panic printing code. The upshot of
this approach is that we can pretty much entirely rely on the atomic
commit flow, with the pair of raw_spin_lock/unlock providing any
barriers we need, without having to create really big critical
sections in code.
This also
From: Jocelyn Falempe
Rough sketch for the locking of drm panic printing code. The upshot of
this approach is that we can pretty much entirely rely on the atomic
commit flow, with the pair of raw_spin_lock/unlock providing any
barriers we need, without having to create really big critical
