On Mon, 23 Dec 2019, Sam Ravnborg sam@ravnborg.org wrote:
Hi Jani.
On Mon, Dec 23, 2019 at 01:29:19PM +0200, Jani Nikula wrote:
On Sat, 21 Dec 2019, Sam Ravnborg sam@ravnborg.org wrote:
There are a lot of cases where we have a device * but no drm_device *. Add drm_dev_* variants of the logging functions to cover these cases.
So I know there are some valid cases where we only have struct device *, and instead of passing struct drm_device * will need the distinction between multiple struct device *.
Not all current uses of DRM_DEV_* meet that criteria, however. I think I'd like to have those converted over to the drm_device based logging first, and then see what's left. Because I fear adding these will just lead to mass conversion from DRM_DEV_* to drm_dev_*, and the ball gets dropped there.
Hmm... $ git grep -E '(DRM_DEV_ERROR|DRM_DEV_INFO|DRM_DEV_WARN|DRM_DEV_DEBUG)' 953 There are 4 hits in drm/* - the rest is in drivers (no suprise).
$ git grep -E '(DRM_ERROR|DRM_INFO|DRM_WARN|DRM_DEBUG)' | wc -l 8380 There are 626 hits in drm/* - the rest in drivers.
So moving over all DRM_DEV looks doable with a lot of effort. It touches all drivers. But the non-DEV variants - thats just too much. This is a lot of effort required before we can offer new drivers a simple a logical logging solution.
I guess that's part of the point. Do we even want to offer new non-dev based alternatives for (DRM_ERROR|DRM_INFO|DRM_WARN|DRM_DEBUG)? We'll end up carrying the alternatives for years. And face tons of churn for no real benefit. Why not just stick to the old ones when you're not using a drm device based alternative?
Switching from non-dev based logging to drm device based logging, OTOH, is worth the churn.
On top of this - there is today no gain using drm_device * versus device *. The output is exactly the same.
For me and i915 the gain is in not having to do the dereference everywhere. Having drm device available is the more common case.
If you go through the current DRM_DEV_* uses, a significant portion of them use drm->dev or have drm device readily available. Again, I'd prefer converting them over to drm device instead of just changing the call to another struct device based version. And then see how big the demand really is for struct device based logging before adding all possible variations of it. Could they do with less?
Using drm device gives us the benefit that we can also add drm device based debug control if we want, for example to enable debug only for a certain device in a multi-GPU system. That option is not easily available with struct device based logging.
We should discuss what is required before we can offer the full solution for new drivers. And how much the existing usage should hold this back.
I guess I'm more concerned about existing drivers and the conversion than new drivers...
BR, Jani.