[alsa-devel] [RFC PATCH 1/2] regmap: add configurable lock class key for lockdep
Nicolas Boichat
drinkcat at chromium.org
Fri Jun 26 05:16:24 CEST 2015
On Fri, Jun 26, 2015 at 12:08 AM, Mark Brown <broonie at kernel.org> wrote:
[...]
>> >As far as I can tell we're likely to end up needing a key per regmap or
>> >something similar.
>
>> Since the number of lockdep classes itself is also limited we should avoid
>> creating extra lockdep classes when we can. I think the approach which
>> having the option of specifying a lockdep class in the regmap config will be
>> ok. The only case it can't handle if we nest instances with the same config,
>> but I don't really see valid use scases for that at the moment.
>
> Oh, ffs. This just keeps getting better. I hadn't been aware of that
> limitation. We still have the problem that this needs to be something
> users can understand rather than something that's just "define something
> here in one of your drivers if you're running into problems with
> spurious warnings" here. That's always been the biggest problem here
> (once we got past the "what is this supposed to do in the first place?"
> issues).
I found that V4L2 uses separate lockdep classes for each of their
v4l2_ctrl. This was introduced in 6cd247ef22e "[media] v4l2-ctrls:
eliminate lockdep false alarms for struct v4l2_ctrl_handler.lock"
(https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6cd247ef22e),
so we could possibly take that approach.
On my system, I have:
# cat /proc/lockdep_stats
lock-classes: 1241 [max: 8191]
direct dependencies: 7364 [max: 32768]
indirect dependencies: 27686
all direct dependencies: 158097
dependency chains: 10011 [max: 65536]
dependency chain hlocks: 38887 [max: 327680]
in-hardirq chains: 92
in-softirq chains: 372
in-process chains: 9547
stack-trace entries: 107703 [max: 524288]
So, at least on that platform, there is some room to grow...
I'm just afraid that implementing this may require creating a bunch of
macros to wrap all regmap_init_[i2c/spi/...] functions, as the lockdep
classes need to be statically allocated... Unless we find a different
solution than what V4L2 does.
More information about the Alsa-devel
mailing list