public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Jean-Francois Moine <moinejf@free.fr>
Cc: "Németh Márton" <nm127@freemail.hu>,
	"Hans de Goede" <hdegoede@redhat.com>,
	"V4L Mailing List" <linux-media@vger.kernel.org>
Subject: Re: [PATCH 1/3] add feedback LED control
Date: Thu, 06 May 2010 15:14:55 -0300	[thread overview]
Message-ID: <4BE3071F.3040206@redhat.com> (raw)
In-Reply-To: <20100301101806.7c7986be@tele>

Jean-Francois Moine wrote:
> On Sun, 28 Feb 2010 20:38:00 +0100
> Németh Márton <nm127@freemail.hu> wrote:
> 
>> With a bitfield on and off state can be specified. What about the
>> "auto" mode? Should two bits grouped together to have auto, on and
>> off state? Is there already a similar control?
>>
>> Is the brightness of the background light LEDs adjustable or are they
>> just on/off? If yes, then maybe the feedback LEDs and the background
>> light LEDs should be treated as different kind.
> 
> OK. My idea about switching the LEDs by v4l2 controls was not good. So,
> forget about it.
> 
> Instead, some job of the led class may be done in the gspca main,
> especially register/unregister.
> 
> I propose to add a LED description in the gspca structure (level
> 'struct cam'). There would be 'nleds' for the number of LEDS and
> 'leds', a pointer to an array of:
> 
> 	struct gspca_led {
> 		struct led_classdev led_cdev;
> 		char led_name[32];
> 		struct led_trigger led_trigger;
> 		char trigger_name[32];
> 	};
> 
> (this array should be in the subdriver structure - I don't show the
> #ifdef's)
> 
> Then, this would work as:
> 
> - on probe, in the 'config' function of the subdriver, this one
>   initializes the led and trigger fields. The 'led_cdev.name' and
>   'led_trigger.name' should point to a sprintf format with one
>   argument: the video device number (ex: "video%d::toplight").
> 
> - then, at the end of gspca_dev_probe(), the gspca main creates the real
>   names of the leds and triggers, and does the register job.
> 
> - all led/trigger events are treated by the subdriver, normally by a
>   workqueue. This one must not be the system workqueue.
> 
> - on disconnection, the gspca main unregisters the leds and triggers
>   without calling the subdriver. In the workqueue, the disconnection
>   can be simply handled testing the flag 'present' after each subsystem
>   call.
> 
> Cheers.
> 

The feedback LED patch series doesn't apply anymore.

patching file Documentation/DocBook/v4l/controls.xml
Hunk #1 succeeded at 324 (offset 13 lines).
patching file Documentation/DocBook/v4l/videodev2.h.xml
Hunk #1 succeeded at 1031 (offset 7 lines).
patching file drivers/media/video/v4l2-common.c
Hunk #1 succeeded at 358 (offset 9 lines).
Hunk #3 FAILED at 442.
Hunk #4 succeeded at 598 (offset 14 lines).
1 out of 4 hunks FAILED -- saving rejects to file drivers/media/video/v4l2-common.c.rej
patching file include/linux/videodev2.h
Hunk #1 FAILED at 1030.
1 out of 1 hunk FAILED -- saving rejects to file include/linux/videodev2.h.rej
>>> Patch patches/lmml_82773_1_3_add_feedback_led_control.patch doesn't apply

As the original approach weren't accepted, I'm dropping those patches from
my queue. Please re-submit after having some agreement about that.

-- 

Cheers,
Mauro

  parent reply	other threads:[~2010-05-06 18:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-28  7:55 [PATCH 1/3] add feedback LED control Németh Márton
2010-02-28 19:28 ` Jean-Francois Moine
2010-02-28 19:38   ` Németh Márton
2010-03-01  9:03     ` Laurent Pinchart
2010-03-01  9:18     ` Jean-Francois Moine
2010-03-02 23:42       ` [RFC, PATCH 1/3] gspca: add LEDs subsystem connection Németh Márton
2010-03-09 11:27         ` Laurent Pinchart
2010-03-09 16:02           ` Richard Purdie
2010-05-06 18:14       ` Mauro Carvalho Chehab [this message]
2010-03-01  9:01 ` [PATCH 1/3] add feedback LED control Laurent Pinchart

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=4BE3071F.3040206@redhat.com \
    --to=mchehab@redhat.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-media@vger.kernel.org \
    --cc=moinejf@free.fr \
    --cc=nm127@freemail.hu \
    /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