[PATCH 0/4] drm/amd/powerplay: introduce the cgs print helpers

[Huang Rui]

On Thu, Dec 08, 2016 at 09:04:13PM +0800, Grazvydas Ignotas wrote:
> On Thu, Dec 8, 2016 at 11:50 AM, Huang Rui <ray.huang at amd.com> wrote:
> > On Thu, Dec 08, 2016 at 05:27:30PM +0800, Christian König wrote:
> >> Am 08.12.2016 um 10:02 schrieb Huang Rui:
> >> > On Thu, Dec 08, 2016 at 04:41:04PM +0800, Koenig, Christian wrote:
> >> >> Sorry, but that just sounds like OS abstraction code which isn't allowed.
> >> >>
> >> >> There is no benefit except routing all messages through CGS which makes
> >> >> things much harder to follow.
> >> >>
> >> > There isn't COS part at current driver. But it seems to be not good to
> >> > introduce COS just for prints. Actually, most of drivers prefer to use
> >> > dev_* prints, and it's able to dynamic control the print level when we
> >> > debug it.
> >>
> >> Well I'm not sure if you have understood what I wanted to say.
> >>
> >> The reason that there isn't any COS abstraction is that it isn't allowed
> >> upstream.
> >>
> >
> > OK, I see.
> >
> >> Using the dev_* prints in the powerplay code is fine, but don't use the
> >> CGS or any other abstraction layer for them.
> >>
> >
> > Powerplay is quite independent component without amdgpu object, it is
> > hard to use dev_* prints without any abstraction layer.
> 
> Maybe you could use dev_set_name() with something powerplay related on
> relevant devices and then dev_* will print what you want?
> 

Garzvydas, thanks to your comments. dev_set_name function needs "struct
device" object in powerplay. But powerplay uses CGS layer to call into
"amdgpu" or "struct device". I think the intention is to make code porting
easier. So we won't bring any OS abstraction code into powerplay.

> Alternatively you could do
> 
> #define pr_fmt(fmt) "[powerplay] " fmt
> 
> before #include <linux/...> and then all pr_* functions will prefix
> their messages.
> 

pr_* actually is almost the same with printk, but it seems fine here to
just add a prefix.

Thanks,
Rui