All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Stein <alexander.stein@systec-electronic.com>
To: Fabio Baltieri <fabio.baltieri@gmail.com>
Cc: Oliver Hartkopp <socketcan@hartkopp.net>, linux-can@vger.kernel.org
Subject: Re: [RFC PATCH] can: add tx/rx led trigger support
Date: Thu, 12 Apr 2012 08:32:22 +0200	[thread overview]
Message-ID: <5882451.nUC1A4BOX5@ws-stein> (raw)
In-Reply-To: <CABkP77eHcrOSG140HF++D9Gt=79gVgGZm5JX6ZVNuc4pjpujcA@mail.gmail.com>

Am Mittwoch, 11. April 2012, 21:36:05 schrieb Fabio Baltieri:
> On Wed, Apr 11, 2012 at 9:02 PM, Oliver Hartkopp <socketcan@hartkopp.net> 
wrote:
> >>> And we should probably add a new CAN netlink command here
> >>> 
> >>>        http://lxr.linux.no/#linux+v3.3.1/drivers/net/can/dev.c#L577
> >>> 
> >>> to configure the LED timer per interface: 0 -> LEDs off (==default)
> >> 
> >> Nice... I'm taking notes here. :-)
> > 
> > Hm - probably this is a bit heavy weighted suggestion from me.
> > 
> > Do you really think the timer value needs to be configurable or is a
> > simple
> > on/off switch ok too?
> 
> I think that if the bus only has a light traffic a longer time would
> be more helpful, otherwise any fixed time of some tenths of
> milliseconds should just do the job (that's how ledtrig-ide-disk
> works). A single module parameter looked like a decent compromise to
> me.
> 
> I should add a check to skip it entirely if led_off_delay == 0 as a
> run-time "optimization" if the feature is not used (triggers does not
> provide a use-counter). Do you think it should be disabled by default?
> 
> > The second question:
> > 
> > Is the LED "blinking" on traffic or is it just "on" for some time when a
> > CAN frame is processed?
> 
> It stays on for some time after each frame. Above a certain
> packet-rate (1/led_off_delay) LED appear to be constantly on. You can
> tell periodic packets from bursts from it but nothing more.

I think a Tx or Rx trigger should just "start" one LED blink, e.g. ON for 
100ms and OFF for 100ms no matter if other packets being processed. This way 
you will constantly see a LED blinking if a specific load is exceeded. If it 
is at lower rate the LED will blink more rarely.
You could even go one step further and activate a LED if the CAN interface is 
UP and turn it off for some time if there is some traffic. So the LED could 
inidicate if the interface is being used and/or if there is some traffic.

Regards,
Alexander
-- 
Dipl.-Inf. Alexander Stein

SYS TEC electronic GmbH
August-Bebel-Str. 29
D-07973 Greiz

Tel: +49-3661-6279-0, Fax: +49-3661-6279-99
eMail:    Alexander.Stein@systec-electronic.com
Internet: http://www.systec-electronic.com

Managing Director: Dipl.-Phys. Siegmar Schmidt
Commercial registry: Amtsgericht Jena, HRB 205563

  parent reply	other threads:[~2012-04-12  6:32 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-10 21:39 [RFC PATCH] can: add tx/rx led trigger support Fabio Baltieri
2012-04-11  6:14 ` Oliver Hartkopp
2012-04-11 17:58   ` Fabio Baltieri
2012-04-11 18:29     ` Oliver Hartkopp
2012-04-11 18:58       ` Wolfgang Grandegger
2012-04-12  6:16         ` Oliver Hartkopp
2012-04-11 19:02     ` Oliver Hartkopp
2012-04-11 19:36       ` Fabio Baltieri
2012-04-12  6:05         ` Oliver Hartkopp
2012-04-12  6:32         ` Alexander Stein [this message]
2012-04-12 15:52           ` Oliver Hartkopp
2012-04-12 18:30             ` Fabio Baltieri
2012-04-13 19:00               ` Oliver Hartkopp
2012-04-12  7:37         ` Wolfgang Grandegger
2012-04-12 11:07           ` Martin Gysel
2012-04-12 16:02             ` Oliver Hartkopp
2012-04-12 16:13               ` Wolfgang Grandegger
2012-04-12 17:28                 ` Fabio Baltieri
2012-04-12 18:47                   ` Wolfgang Grandegger
2012-04-12 17:46           ` Fabio Baltieri
2012-04-12 18:53             ` Wolfgang Grandegger
2012-04-11  6:29 ` Alexander Stein
2012-04-11 18:03   ` Fabio Baltieri
2012-04-11 14:45 ` Wolfgang Grandegger
2012-04-11 16:24   ` Oliver Hartkopp
2012-04-11 19:11   ` Fabio Baltieri

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=5882451.nUC1A4BOX5@ws-stein \
    --to=alexander.stein@systec-electronic.com \
    --cc=fabio.baltieri@gmail.com \
    --cc=linux-can@vger.kernel.org \
    --cc=socketcan@hartkopp.net \
    /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 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.