* omap_device prints
@ 2011-07-21 9:51 Russell King - ARM Linux
2011-07-21 9:58 ` Felipe Balbi
2011-07-21 14:57 ` Kevin Hilman
0 siblings, 2 replies; 3+ messages in thread
From: Russell King - ARM Linux @ 2011-07-21 9:51 UTC (permalink / raw)
To: linux-omap
I spotted this while booting the OMAP4430 SDP:
omap_device: omap4-keypad.-1: new worst case activate latency 0: 61035
and found that it came from here:
pr_debug("omap_device: %s: activating\n", od->pdev.name);
pr_debug("omap_device: %s: pm_lat %d: activate: elapsed time "
"%llu nsec\n", od->pdev.name, od->pm_lat_level,
act_lat);
pr_warning("omap_device: %s.%d: new worst case "
"activate latency %d: %llu\n",
od->pdev.name, od->pdev.id,
od->pm_lat_level, act_lat);
pr_warning("omap_device: %s.%d: activate "
"latency %d higher than exptected. "
"(%llu > %d)\n",
od->pdev.name, od->pdev.id,
od->pm_lat_level, act_lat,
odpl->activate_lat);
Is there something wrong with dev_name(&od->pdev.dev) so that we have
consistent naming of devices, rather than poking about inside the
platform_device accessing the name initializers directly ?
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: omap_device prints
2011-07-21 9:51 omap_device prints Russell King - ARM Linux
@ 2011-07-21 9:58 ` Felipe Balbi
2011-07-21 14:57 ` Kevin Hilman
1 sibling, 0 replies; 3+ messages in thread
From: Felipe Balbi @ 2011-07-21 9:58 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: linux-omap
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]
On Thu, Jul 21, 2011 at 10:51:09AM +0100, Russell King - ARM Linux wrote:
> I spotted this while booting the OMAP4430 SDP:
>
> omap_device: omap4-keypad.-1: new worst case activate latency 0: 61035
>
> and found that it came from here:
>
> pr_debug("omap_device: %s: activating\n", od->pdev.name);
>
> pr_debug("omap_device: %s: pm_lat %d: activate: elapsed time "
> "%llu nsec\n", od->pdev.name, od->pm_lat_level,
> act_lat);
>
> pr_warning("omap_device: %s.%d: new worst case "
> "activate latency %d: %llu\n",
> od->pdev.name, od->pdev.id,
> od->pm_lat_level, act_lat);
> pr_warning("omap_device: %s.%d: activate "
> "latency %d higher than exptected. "
> "(%llu > %d)\n",
> od->pdev.name, od->pdev.id,
> od->pm_lat_level, act_lat,
> odpl->activate_lat);
>
> Is there something wrong with dev_name(&od->pdev.dev) so that we have
> consistent naming of devices, rather than poking about inside the
> platform_device accessing the name initializers directly ?
or dev_*() macros, instead ?
dev_dbg(&od->pdev.dev, "activating\n");
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: omap_device prints
2011-07-21 9:51 omap_device prints Russell King - ARM Linux
2011-07-21 9:58 ` Felipe Balbi
@ 2011-07-21 14:57 ` Kevin Hilman
1 sibling, 0 replies; 3+ messages in thread
From: Kevin Hilman @ 2011-07-21 14:57 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: linux-omap
Russell King - ARM Linux <linux@arm.linux.org.uk> writes:
> I spotted this while booting the OMAP4430 SDP:
>
> omap_device: omap4-keypad.-1: new worst case activate latency 0: 61035
>
[...]
> Is there something wrong with dev_name(&od->pdev.dev) so that we have
> consistent naming of devices, rather than poking about inside the
> platform_device accessing the name initializers directly ?
I've been meaning to convert most of these from pr_debug() to dev_dbg().
There are a few that have to remain pr_debug() because they are used
before the platform_device (and struct device) are initialized, but most
of them can be converted.
Patch coming shortly.
Kevin
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-07-21 14:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-07-21 9:51 omap_device prints Russell King - ARM Linux
2011-07-21 9:58 ` Felipe Balbi
2011-07-21 14:57 ` Kevin Hilman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.