On Sat, Jun 4, 2016 at 3:51 AM, Stefan Agner <stefan@xxxxxxxx> wrote: > On 2016-06-03 16:00, Daniel Vetter wrote: >> On Fri, Jun 03, 2016 at 03:43:19PM -0700, Stefan Agner wrote: >>> Using flat regmap cache instead of RB-tree to avoid the following >>> lockdep warning on driver load: >>> WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2755 lockdep_trace_alloc+0x15c/0x160() >>> DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) >>> >>> The RB-tree regmap cache needs to allocate new space on first >>> writes. However, allocations in an atomic context (e.g. when a >>> spinlock is held) are not allowed. The function regmap_write >>> calls map->lock, which acquires a spinlock in the fast_io case. >>> Since the FSL DCU driver uses MMIO, the regmap bus of type >>> regmap_mmio is being used which has fast_io set to true. >>> >>> Use flat regmap cache and specify max register to be large >>> enouth to cover all registers available in LS1021a and Vybrids >>> register space. >>> >>> Signed-off-by: Stefan Agner <stefan@xxxxxxxx> >>> Cc: Mark Brown <broonie@xxxxxxxxxx> >>> Cc: stable@xxxxxxxxxxxxxxx >>> --- >>> While regmap cache is used for suspend/resume only (which is >>> broken in its current state) Mark noted that using the RB regmap >>> cache can also cause issues during initialization of the driver. >>> This patch migrates to flat regmap cache (which we can also use >>> to fix the issue in stable kernels), and yet another patchset >>> moves to the atomic suspend/resume helpers (which will not go >>> into stable...) >> >> While talking suspend/resume, I highly recommend >> drm_atomic_helper_suspend and drm_atomic_helper_resume. In my experience >> dumb safe/restore of registers for restoring modeset state leads to tears. >> -Daniel > > Since you commented to the patchset implementing exactly that I assume > you have seen it. Yup, that was pretty awesome coincidence ;-) > I still would like to have this patch applied to fix the regmap cache > warning also for older kernels. Sure, this was just a quick comment on your remark that there's still trouble left with suspend/resume. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
