On Mon, Nov 15, 2021 at 12:40 PM Claudio Suarez <cssk@xxxxxxxx> wrote: > > On Mon, Nov 15, 2021 at 12:24:26PM +0200, Jani Nikula wrote: > > On Sun, 14 Nov 2021, Claudio Suarez <cssk@xxxxxxxx> wrote: > > > On Sat, Nov 13, 2021 at 09:39:46PM +0100, Sam Ravnborg wrote: > > >> Hi Claudio, > > >> > > >> On Sat, Nov 13, 2021 at 08:27:30PM +0100, Claudio Suarez wrote: > > >> > The prefered way to log connectors is [CONNECTOR:id:name]. Change it in > > >> > drm core programs. > > >> > > > >> > Suggested-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > >> > Signed-off-by: Claudio Suarez <cssk@xxxxxxxx> > > >> > > >> While touching all these logging calls, could you convernt them to the > > >> newer drm_dbg_kms variants? > > >> DRM_DEBUG_* are all deprecated. > > >> > > > > > > Yes, I can, but it is recommended to do it in a different patch: > > > > > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#separate-your-changes > > > > > > C&P: > > > "Separate your changes > > > Separate each logical change into a separate patch. > > > For example, if your changes include both bug fixes and performance enhancements..." > > > > > > > > > I will study and send a new separate patch with your suggestion. > > > > I feel these logging changes are the types of changes where I'd err on > > the side of fewer patches than strictly following the above guidelines. > > To size the problem: > - there are about 3434 references to DRM_DEBUG_* in all the drm code, all drivers. > - there are 413 references to DRM_DEBUG_* in the drm core code, only 66 of > them are related to connectors. > - there are 62 references to DRM_ERR* and 7 references to DRM_INFO in > the drm core programs. > > I meant I can make two patches: > 1 - this one with the change to CONNECTOR:id:name (29 changes) Is there a "committee" that makes or coordinates these log-facing changes ? The reason I ask is that Ive proposed that the DRM_UT_<Categories> be replaced by a set of prefix strings; "drm:core:" "drm:kms:" etc. If the DRM_DEBUG_* etc api were converted to use pr_debug, then dyndbg could optimize away the drm_debug_enabled() overheads. dyndbg would enable those classes of drm-debug callsites using #> echo module drm format drm:kms: > /proc/dyndbg/control the patchset includes a macro to declare a bit-field to implement drm.debug https://patchwork.freedesktop.org/series/96328/ how would one (hope to) coordinate changes like this ?
