linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jamie@jamieiles.com (Jamie Iles)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 01/17] leds: create a trigger for CPU activity
Date: Wed, 3 Aug 2011 11:28:29 +0100	[thread overview]
Message-ID: <20110803102829.GC2607@pulham.picochip.com> (raw)
In-Reply-To: <1312364089-32380-2-git-send-email-bryan.wu@canonical.com>

Hi Bryan,

On Wed, Aug 03, 2011 at 05:34:33PM +0800, Bryan Wu wrote:
> Attempting to consolidate the ARM LED code, this removes the
> custom RealView LED trigger code to turn LEDs on and off in
> response to CPU activity and replace it with a standard trigger.
> 
> (bryan.wu at canonical.com:
> It moves arch/arm/kernel/leds.c syscore stubs into this trigger.
> It also provides ledtrig_cpu trigger event stub in <linux/leds.h>.
> Although it was inspired by ARM work, it can be used in other arch.)
> 
> Cc: Richard Purdie <rpurdie@rpsys.net>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Bryan Wu <bryan.wu@canonical.com>
> ---
>  drivers/leds/Kconfig       |   10 +++
>  drivers/leds/Makefile      |    1 +
>  drivers/leds/ledtrig-cpu.c |  144 ++++++++++++++++++++++++++++++++++++++++++++
>  include/linux/leds.h       |   15 +++++
>  4 files changed, 170 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/leds/ledtrig-cpu.c
> 
> diff --git a/drivers/leds/ledtrig-cpu.c b/drivers/leds/ledtrig-cpu.c
> new file mode 100644
> index 0000000..0537c3b
[...]
> +static DEFINE_PER_CPU(struct ledtrig_cpu_data *, ledtrig_cpu_triggers);
[...]
> +static void ledtrig_cpu_activate_cpu(void *data)
> +{
> +	struct ledtrig_cpu_data *cpu_data;
> +	struct led_classdev *led = data;
> +	int my_cpu = smp_processor_id();
> +	unsigned long target_cpu = (unsigned long) led->trigger_data;
> +
> +	if (target_cpu != my_cpu)
> +		return;
> +
> +	cpu_data = kzalloc(sizeof(*cpu_data), GFP_KERNEL);
> +	if (!cpu_data)
> +		return;
> +
> +	dev_info(led->dev, "led %s indicate activity on CPU %d\n",
> +		 led->name, my_cpu);
> +
> +	cpu_data->led = led;
> +	__get_cpu_var(ledtrig_cpu_triggers) = cpu_data;
> +}
> +
> +static void ledtrig_cpu_activate(struct led_classdev *led)
> +{
> +	on_each_cpu(ledtrig_cpu_activate_cpu, led, 1);
> +}
> +
> +static void ledtrig_cpu_deactivate(struct led_classdev *led)
> +{
> +	struct ledtrig_cpu_data *cpu_data = led->trigger_data;
> +
> +	kfree(cpu_data);
> +}

Is this deactivation correct?  My (limited) understanding of the smp api 
is that we'll allocate the ledtrig_cpu_data for each CPU and store it in 
the ledtrig_cpu_triggers pointers.  So shouldn't this be doing a 
__get_cpu_var(ledtrig_cpu_triggers) and a kfree() on that (and setting 
to NULL)?

Also, where does led->trigger_data get assigned with the cpu id?

Jamie

  parent reply	other threads:[~2011-08-03 10:28 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-03  9:34 [PATCH v2 00/17] Introduce a led trigger for CPU activity and consolidate LED driver in ARM Bryan Wu
2011-08-03  9:34 ` [PATCH 01/17] leds: create a trigger for CPU activity Bryan Wu
2011-08-03 10:23   ` Michał Mirosław
2011-08-04  9:18     ` Bryan Wu
2011-08-03 10:28   ` Jamie Iles [this message]
2011-08-03 15:22     ` Linus Walleij
2011-08-03 15:30       ` Jamie Iles
2011-08-03 16:02         ` Jochen Friedrich
2011-08-03 16:12         ` Linus Walleij
2011-08-05  9:48           ` Bryan Wu
2011-08-03  9:34 ` [PATCH 02/17] arm: at91: convert old leds drivers to gpio_led and led_trigger drivers Bryan Wu
2011-08-03  9:34 ` [PATCH 03/17] mach-realview and mach-versatile: retire custom LED code Bryan Wu
2011-08-03 11:59   ` Russell King - ARM Linux
2011-08-17 11:06     ` Bryan Wu
2011-08-03  9:34 ` [PATCH 04/17] mach-ks8695: remove leds driver, since nobody use it Bryan Wu
2011-08-03  9:34 ` [PATCH 05/17] mach-shark: retire custom LED code Bryan Wu
2011-08-03  9:34 ` [PATCH 06/17] mach-orion5x: convert custom LED code to gpio_led and LED CPU trigger Bryan Wu
2011-08-03  9:34 ` [PATCH 07/17] mach-integrator: introduce cm_read function helper to read CM_CTRL register Bryan Wu
2011-08-03 11:29   ` Sergei Shtylyov
2011-08-04  8:54     ` Bryan Wu
2011-08-03 11:30   ` Sergei Shtylyov
2011-08-03  9:34 ` [PATCH 08/17] mach-integrator: retire custom LED code Bryan Wu
2011-08-03  9:34 ` [PATCH 09/17] mach-clps711x: retire custom LED code of P720T machine Bryan Wu
2011-08-03  9:34 ` [PATCH 10/17] mach-ebsa110: retire custom LED code Bryan Wu
2011-08-03  9:34 ` [PATCH 11/17] mach-footbridge: " Bryan Wu
2011-08-03  9:34 ` [PATCH 12/17] mach-pxa: " Bryan Wu
2011-08-03  9:34 ` [PATCH 13/17] plat-samsung: remove including old leds event API header file Bryan Wu
2011-08-03  9:34 ` [PATCH 14/17] mach-pnx4008: " Bryan Wu
2011-08-03  9:34 ` [PATCH 15/17] mach-omap1: retire custom LED code Bryan Wu
2011-08-03  9:34 ` [PATCH 16/17] mach-sa1100: " Bryan Wu
2011-08-03  9:34 ` [PATCH 17/17] ARM: use new LEDS CPU trigger stub to replace old one Bryan Wu
  -- strict thread matches above, loose matches on Subject: below --
2011-07-06 12:34 [PATCH 00/17] Introduce a led trigger for CPU activity Bryan Wu
2011-07-06 12:34 ` [PATCH 01/17] leds: create a " Bryan Wu
2011-07-06 13:16   ` Eric Miao
2011-07-06 13:35     ` Russell King - ARM Linux
2011-07-06 14:11       ` Nicolas Pitre
2011-07-07 12:58     ` Bryan Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110803102829.GC2607@pulham.picochip.com \
    --to=jamie@jamieiles.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).