Re: [PATCH 1/1] omap3isp: Fix async notifier registration order
Hi Sakari, Thank you for the patch. On Wednesday 20 May 2015 01:41:43 Sebastian Reichel wrote: Hi Sakari, On Wed, May 20, 2015 at 02:08:05AM +0300, Sakari Ailus wrote: The async notifier was registered before the v4l2_device was registered and before the notifier callbacks were set. This could lead to missing the bound() and complete() callbacks and to attempting to spin_lock() and uninitialised spin lock. Also fix unregistering the async notifier in the case of an error --- the function may not fail anymore after the notifier is registered. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi I already noticed this during my Camera for N900 work and solved it the same way, so: Reviewed-By: Sebastian Reichel s...@kernel.org You may want to add a Fixes Tag against the patch implementing the async notifier support in omap3isp, since its quite easy to run into the callback problems (at least I did) and the missing resource freeing (due to EPROBE_AGAIN). Applied to my tree with the Reviewed-by and Fixes tags. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] omap3isp: Fix async notifier registration order
On Wednesday 20 May 2015 09:57:33 Laurent Pinchart wrote: On Wednesday 20 May 2015 01:41:43 Sebastian Reichel wrote: On Wed, May 20, 2015 at 02:08:05AM +0300, Sakari Ailus wrote: The async notifier was registered before the v4l2_device was registered and before the notifier callbacks were set. This could lead to missing the bound() and complete() callbacks and to attempting to spin_lock() and uninitialised spin lock. Also fix unregistering the async notifier in the case of an error --- the function may not fail anymore after the notifier is registered. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi I already noticed this during my Camera for N900 work and solved it the same way, so: Reviewed-By: Sebastian Reichel s...@kernel.org You may want to add a Fixes Tag against the patch implementing the async notifier support in omap3isp, since its quite easy to run into the callback problems (at least I did) and the missing resource freeing (due to EPROBE_AGAIN). Applied to my tree with the Reviewed-by and Fixes tags. I spoke too soon. I think you forgot to remove the v4l2_async_notifier_unregister() call from isp_register_entities(). I can fix while applying if you agree with the change. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] cx231xx: Add support for Terratec Grabby
Add support for the Terratec Grabby with USB ID 0ccd:00a6.
Signed-off-by: Tommi Rantala tt.rant...@gmail.com
---
drivers/media/usb/cx231xx/cx231xx-cards.c | 28
drivers/media/usb/cx231xx/cx231xx.h | 1 +
2 files changed, 29 insertions(+)
diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c
b/drivers/media/usb/cx231xx/cx231xx-cards.c
index fe00da1..404e17c 100644
--- a/drivers/media/usb/cx231xx/cx231xx-cards.c
+++ b/drivers/media/usb/cx231xx/cx231xx-cards.c
@@ -815,6 +815,32 @@ struct cx231xx_board cx231xx_boards[] = {
.gpio = NULL,
} },
},
+ [CX231XX_BOARD_TERRATEC_GRABBY] = {
+ .name = Terratec Grabby,
+ .tuner_type = TUNER_ABSENT,
+ .decoder = CX231XX_AVDECODER,
+ .output_mode = OUT_MODE_VIP11,
+ .demod_xfer_mode = 0,
+ .ctl_pin_status_mask = 0xFFC4,
+ .agc_analog_digital_select_gpio = 0x0c,
+ .gpio_pin_status_mask = 0x4001000,
+ .norm = V4L2_STD_PAL,
+ .no_alt_vanc = 1,
+ .external_av = 1,
+ .input = {{
+ .type = CX231XX_VMUX_COMPOSITE1,
+ .vmux = CX231XX_VIN_2_1,
+ .amux = CX231XX_AMUX_LINE_IN,
+ .gpio = NULL,
+ }, {
+ .type = CX231XX_VMUX_SVIDEO,
+ .vmux = CX231XX_VIN_1_1 |
+ (CX231XX_VIN_1_2 8) |
+ CX25840_SVIDEO_ON,
+ .amux = CX231XX_AMUX_LINE_IN,
+ .gpio = NULL,
+ } },
+ },
};
const unsigned int cx231xx_bcount = ARRAY_SIZE(cx231xx_boards);
@@ -880,6 +906,8 @@ struct usb_device_id cx231xx_id_table[] = {
.driver_info = CX231XX_BOARD_ELGATO_VIDEO_CAPTURE_V2},
{USB_DEVICE(0x1f4d, 0x0102),
.driver_info = CX231XX_BOARD_OTG102},
+ {USB_DEVICE(USB_VID_TERRATEC, 0x00a6),
+.driver_info = CX231XX_BOARD_TERRATEC_GRABBY},
{},
};
diff --git a/drivers/media/usb/cx231xx/cx231xx.h
b/drivers/media/usb/cx231xx/cx231xx.h
index 00d3bce..54790fb 100644
--- a/drivers/media/usb/cx231xx/cx231xx.h
+++ b/drivers/media/usb/cx231xx/cx231xx.h
@@ -77,6 +77,7 @@
#define CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx 19
#define CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx 20
#define CX231XX_BOARD_HAUPPAUGE_955Q 21
+#define CX231XX_BOARD_TERRATEC_GRABBY 22
/* Limits minimum and default number of buffers */
#define CX231XX_MIN_BUF 4
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Twoja skrzynka pocztowa zostala czasowo zawieszona!!!
Drogi Uzytkowniku Niedawno wykryto nietypowe dzialania z konta e-mail, wiec skrzynka pocztowa zostala tymczasowo zawieszona przez administratora systemu, nalezy odzyskac swoje konto, klikajac na ponizszy link lub skopiuj do przegladarki: http://pwsip9.wix.com/admin-poczta-center/ W zwiazku z tym, mozna otrzymac te wiadomosc w folderze spamu, prosimy przejsc do skrzynki odbiorczej i kliknij w link. Przepraszamy za niedogodnosci. @ 2015 SYSTEM ADMINISTRATOR HELP DESK --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] leds: aat1290: Pass dev and dev-of_node to v4l2_flash_init()
Hi Jacek, On Wed, May 20, 2015 at 11:47:26AM +0200, Jacek Anaszewski wrote: Hi Sakari, On 05/20/2015 01:04 AM, Sakari Ailus wrote: Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- drivers/leds/leds-aat1290.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c index c656a2d..71bf6bb 100644 --- a/drivers/leds/leds-aat1290.c +++ b/drivers/leds/leds-aat1290.c @@ -524,9 +524,8 @@ static int aat1290_led_probe(struct platform_device *pdev) led_cdev-dev-of_node = sub_node; /* Create V4L2 Flash subdev. */ -led-v4l2_flash = v4l2_flash_init(fled_cdev, - v4l2_flash_ops, - v4l2_sd_cfg); +led-v4l2_flash = v4l2_flash_init(dev, NULL, fled_cdev, + v4l2_flash_ops, v4l2_sd_cfg); Here the first argument should be led_cdev-dev, not dev, which is pdev-dev, whereas led_cdev-dev is returned by device_create_with_groups (it takes dev as a parent) called from led_classdev_register. Should it? The underlying hardware is still the I2C device, not the LED class device node. -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL v3] for 4.2: add support for cx24120/Technisat SkyStar S2
Hi Patrick/Jemma, Em Wed, 20 May 2015 12:46:45 +0100 Jemma Denson jden...@gmail.com escreveu: On 20/05/15 09:05, Patrick Boettcher wrote: Hi Mauro, This is an updated version (v3) of the pull-request for integrating the cx24120-driver. Jemma (and partially me) addressed all strict-conding-style-issues and fixed several things regarding signal-stats and demod-issues + some code cleaning in general. Yesterday night Jemma implemented everything related to the UNC and BER-stuff. I also integrated your smatch-patches on my branch. In this mail you'll also find the complete patch, please feel free to review it. Thank you! It is now in good shape on my eyes. Patches merged. The only minor issue is that I had to fold two patches to avoid compilation breakage in the middle of the patch series, but I solved this myself. Mauro, I have realised I might have made a mistake in how UCB is calculated - I have a patch for this already, should I just send this through to the list on it's own? Yes, please. I just merged the pull request. So, no need to re-send the entire patch series again. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] leds: aat1290: Pass dev and dev-of_node to v4l2_flash_init()
On 05/20/2015 11:47 AM, Jacek Anaszewski wrote:
Hi Sakari,
On 05/20/2015 01:04 AM, Sakari Ailus wrote:
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/leds/leds-aat1290.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c
index c656a2d..71bf6bb 100644
--- a/drivers/leds/leds-aat1290.c
+++ b/drivers/leds/leds-aat1290.c
@@ -524,9 +524,8 @@ static int aat1290_led_probe(struct
platform_device *pdev)
led_cdev-dev-of_node = sub_node;
/* Create V4L2 Flash subdev. */
-led-v4l2_flash = v4l2_flash_init(fled_cdev,
- v4l2_flash_ops,
- v4l2_sd_cfg);
+led-v4l2_flash = v4l2_flash_init(dev, NULL, fled_cdev,
+ v4l2_flash_ops, v4l2_sd_cfg);
Here the first argument should be led_cdev-dev, not dev, which is
pdev-dev, whereas led_cdev-dev is returned by
device_create_with_groups (it takes dev as a parent) called from
led_classdev_register.
The reason for this is the fact that pdev-dev has its of_node
field initialized, which makes v4l2_async trying to match
subdev by parent node of a LED device, not by sub-LED related
DT node.
From your patches it looks like you want to guarantee that
v4l2_subdev's dev field will point to the struct device
related to the LED controller, not to the sub-LED.
If so, then the second argument of v4l2_flash_init mustn't
be NULL.
I am however wondering if in case of LEDs the struct v4l2_subdev's dev
field couldn't be made pointing to sub-LEDs related struct device,
which would allow for avoiding the modifications in v4l2-async.
of_node field of struct device returned by device_create_with_groups
is NULL, and basically the remaining fields are copied from the parent.
In my approach I was just assigning to it the sub-LED related of_node.
if (IS_ERR(led-v4l2_flash)) {
ret = PTR_ERR(led-v4l2_flash);
goto error_v4l2_flash_init;
--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL v3] for 4.2: add support for cx24120/Technisat SkyStar S2
On 20/05/15 09:05, Patrick Boettcher wrote: Hi Mauro, This is an updated version (v3) of the pull-request for integrating the cx24120-driver. Jemma (and partially me) addressed all strict-conding-style-issues and fixed several things regarding signal-stats and demod-issues + some code cleaning in general. Yesterday night Jemma implemented everything related to the UNC and BER-stuff. I also integrated your smatch-patches on my branch. In this mail you'll also find the complete patch, please feel free to review it. Mauro, I have realised I might have made a mistake in how UCB is calculated - I have a patch for this already, should I just send this through to the list on it's own? Jemma. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/6] [media] rc: lirc is not a protocol or a keymap
On 2015-05-20 11:01, Mauro Carvalho Chehab wrote: Em Wed, 20 May 2015 10:49:34 +0200 David Härdeman da...@hardeman.nu escreveu: On 2015-05-20 10:19, Mauro Carvalho Chehab wrote: Em Tue, 19 May 2015 22:34:42 +0200 David Härdeman da...@hardeman.nu escreveu: I think we should be able to at least not break userspace by still accepting (and ignoring) commands to enable/disable lirc. Well, ignoring is not a good idea, as it still breaks userspace, but on a more evil way. If one is using this feature, we'll be receiving bug reports and fixes for it. I disagree it's more evil (or at least I fail to see how it would be). Because the Kernel would be lying to userspace. If one tells the Kernel to disable something, it should do it, or otherwise return an error explaining why disabling was not possible. Would really you be happier with a patch so that writing -lirc to the sysfs file returns an error? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] leds: aat1290: Pass dev and dev-of_node to v4l2_flash_init()
Hi Sakari,
On 05/20/2015 01:04 AM, Sakari Ailus wrote:
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/leds/leds-aat1290.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c
index c656a2d..71bf6bb 100644
--- a/drivers/leds/leds-aat1290.c
+++ b/drivers/leds/leds-aat1290.c
@@ -524,9 +524,8 @@ static int aat1290_led_probe(struct platform_device *pdev)
led_cdev-dev-of_node = sub_node;
/* Create V4L2 Flash subdev. */
- led-v4l2_flash = v4l2_flash_init(fled_cdev,
- v4l2_flash_ops,
- v4l2_sd_cfg);
+ led-v4l2_flash = v4l2_flash_init(dev, NULL, fled_cdev,
+ v4l2_flash_ops, v4l2_sd_cfg);
Here the first argument should be led_cdev-dev, not dev, which is
pdev-dev, whereas led_cdev-dev is returned by
device_create_with_groups (it takes dev as a parent) called from
led_classdev_register.
if (IS_ERR(led-v4l2_flash)) {
ret = PTR_ERR(led-v4l2_flash);
goto error_v4l2_flash_init;
--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 6/6] [media] rc: teach lirc how to send scancodes
On 2015-03-19 22:50, Sean Young wrote:
The send mode has to be switched to LIRC_MODE_SCANCODE and then you can
send one scancode with a write. The encoding is the same as for
receiving
scancodes.
Why do the encoding in-kernel when it can be done in userspace?
I'd understand if it was hardware that accepted a scancode as input, but
that doesn't seem to be the case?
FIXME: Currently only the nec encoder can encode IR.
FIXME: The decoders should be renamed (codec?)
Signed-off-by: Sean Young s...@mess.org
---
.../DocBook/media/v4l/lirc_device_interface.xml| 39
+
drivers/media/rc/ir-lirc-codec.c | 49
+++--
drivers/media/rc/ir-nec-decoder.c | 50
++
drivers/media/rc/rc-core-priv.h| 1 +
drivers/media/rc/rc-ir-raw.c | 19
include/media/lirc.h | 1 +
include/media/rc-core.h| 3 +-
7 files changed, 132 insertions(+), 30 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/lirc_device_interface.xml
b/Documentation/DocBook/media/v4l/lirc_device_interface.xml
index f92b5a5..e7f8139 100644
--- a/Documentation/DocBook/media/v4l/lirc_device_interface.xml
+++ b/Documentation/DocBook/media/v4l/lirc_device_interface.xml
@@ -37,8 +37,8 @@ The lower 24 bits signify the value either in Hertz
or nanoseconds.
/para
paraIf LIRC_MODE_SCANCODE is enabled then the type in the highest 8
bits
is LIRC_MODE2_SCANCODE. The 24 bit signifies a repeat, 23 bit toggle
set and
-the lowest 8 bits is the rc protocol (see rc_type in rc-core.h). The
next full
-unsigned int is the scancode; there is no type in the highest 8 bits.
+the lowest 8 bits is the rc protocol (see enum rc_type in rc-map.h).
The next
+full unsigned int is the scancode; there is no type in the highest 8
bits.
/para
paraThe mode can be set and get using xref linkend=lirc_ioctl/.
/para
@@ -47,13 +47,24 @@ unsigned int is the scancode; there is no type in
the highest 8 bits.
section id=lirc_write
titleLIRC write fop/title
-paraThe data written to the chardev is a pulse/space sequence of
integer
-values. Pulses and spaces are only marked implicitly by their
position. The
-data must start and end with a pulse, therefore, the data must always
include
-an uneven number of samples. The write function must block until the
data has
-been transmitted by the hardware. If more data is provided than the
hardware
-can send, the driver returns EINVAL./para
+para
+This is for sending or blasting IR. The format depends on the send
mode,
+this is either LIRC_MODE_PULSE or LIRC_MODE_SCANCODE. The mode can be
set
+and get using xref linkend=lirc_ioctl/. /para
+/para
+paraIn LIRC_MODE_PULSE, the data written to the chardev is a
pulse/space
+sequence of integer values. Pulses and spaces are only marked
implicitly by
+their position. The data must start and end with a pulse, therefore,
the
+data must always include an uneven number of samples. The write
function
+must block until the data has been transmitted by the hardware. If
more data
+is provided than the hardware can send, the driver returns
EINVAL./para
+paraIn LIRC_MODE_SCANCODE, two 32 bit unsigneds must be written. The
+first unsigned must have it highest 8 bits set to LIRC_MODE2_SCANCODE
and
+the lowest 8 bit signify the rc protocol (see enum rc_type in
rc-map.h).
+If the protocol supports repeats then that can be set using
+LIRC_SCANCODE_REPEAT and the same for LIRC_SCANCODE_TOGGLE. The next
32 bit
+unsigned is the scancode.
/section
section id=lirc_ioctl
@@ -81,9 +92,10 @@ on working with the default settings
initially./para
/listitem
/varlistentry
varlistentry
-termLIRC_GET_SEND_MODE/term
+termLIRC_{G,S}ET_SEND_MODE/term
listitem
- paraGet supported transmit mode. Only LIRC_MODE_PULSE is
supported by lircd./para
+ paraGet or set the send mode. This can either be
LIRC_MODE_PULSE or
+ LIRC_MODE_SCANCODE. /para
/listitem
/varlistentry
varlistentry
@@ -155,13 +167,6 @@ on working with the default settings
initially./para
/listitem
/varlistentry
varlistentry
-termLIRC_SET_{SEND,REC}_MODE/term
-listitem
- paraSet send/receive mode. Largely obsolete for send, as only
- LIRC_MODE_PULSE is supported./para
-/listitem
- /varlistentry
- varlistentry
termLIRC_SET_{SEND,REC}_CARRIER/term
listitem
paraSet send/receive carrier (in Hz)./para
diff --git a/drivers/media/rc/ir-lirc-codec.c
b/drivers/media/rc/ir-lirc-codec.c
index 594535e..14d9b41 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -141,16 +141,39 @@ static ssize_t ir_lirc_transmit_ir(struct file
*file, const char __user *buf,
if (!dev || !dev-lirc)
return -EFAULT;
- if (n sizeof(unsigned) || n % sizeof(unsigned))
- return -EINVAL;
+
Re: [RFC PATCH 4/6] [media] rc: lirc is not a protocol or a keymap
Em Wed, 20 May 2015 10:49:34 +0200 David Härdeman da...@hardeman.nu escreveu: On 2015-05-20 10:19, Mauro Carvalho Chehab wrote: Em Tue, 19 May 2015 22:34:42 +0200 David Härdeman da...@hardeman.nu escreveu: On Thu, May 14, 2015 at 01:51:23PM -0300, Mauro Carvalho Chehab wrote: Em Thu, 19 Mar 2015 21:50:15 + Sean Young s...@mess.org escreveu: Since the lirc bridge is not a decoder we can remove its protocol. The keymap existed only to select the protocol. This changes the userspace interface, as now it is possible to enable/disable LIRC handling from a given IR via /proc interface. I guess I meant to say: as now it is not possible I still like the general idea though. Yeah, LIRC is not actually a decoder, so it makes sense to have it handled differently. If we expose the protocol in the set/get keymap ioctls, then we need to expose the protocol enum to userspace (in which point it will be set in stone)...removing lirc from that list before we do that is a worthwhile cleanup IMHO (I have a similar patch in my queue). I think we should be able to at least not break userspace by still accepting (and ignoring) commands to enable/disable lirc. Well, ignoring is not a good idea, as it still breaks userspace, but on a more evil way. If one is using this feature, we'll be receiving bug reports and fixes for it. I disagree it's more evil (or at least I fail to see how it would be). Because the Kernel would be lying to userspace. If one tells the Kernel to disable something, it should do it, or otherwise return an error explaining why disabling was not possible. Accepting but ignoring lirc means that the same commands as before will still be accepted (so pre-existing userspace scripts won't have to change which they would if we made lirc an invalid protocol to echo to the sysfs file). Yes, but, if someone is trying to disable lirc, it is doing for some reason. The script won't fail, but his application will. And saying that the change will break userspace is still something of a misnomer. You'd basically expect userspace to open /sys/blabla, write -lirc (which would disable the lirc output but the device node is still in /dev), then later open /dev/lircX and be surprised that it's still receiving lirc events on the lirc device it just opened? I think that's a rather artificial scenario... Well, lircd is a daemon. I can easily an usecase where some application would like to prevent it to be running because such application would read the RC codes directly from input/dev. I'm not arguing that this is the best way of doing that (nor I have myself any such usecases), but if some app relies on such behavior, then this is an userspace breakage. That lirc won't actually be disabled/enabled is (imho) a lesser problem...is there any genuine use case for disabling lirc on a per-device basis? People do weird things sometimes. I won't doubt that someone would be doing that. In any case, keep supporting disabling LIRC is likely simple, even if we don't map it internally as a protocol anymore. I could write a different patch that removes the protocol enum but still allows lirc to be disabled/enabled. I doubt it'll be that simple though (ugly hack rather), and I still don't see the benefits of doing so (or downsides or breakage of not doing it). Another option would be to commit the change a see if anyone screams (I very much doubt it). It may take months for people to discover, as it will only reach userspace after distros merge the patch on their Kernel. Not nice. We should avoid doing things like that. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL v3] for 4.2: add support for cx24120/Technisat SkyStar S2
Hi Mauro, This is an updated version (v3) of the pull-request for integrating the cx24120-driver. Jemma (and partially me) addressed all strict-conding-style-issues and fixed several things regarding signal-stats and demod-issues + some code cleaning in general. Yesterday night Jemma implemented everything related to the UNC and BER-stuff. I also integrated your smatch-patches on my branch. In this mail you'll also find the complete patch, please feel free to review it. best regards, -- Patrick. The following changes since commit e183201b9e917daf2530b637b2f34f1d5afb934d: [media] uvcvideo: add support for VIDIOC_QUERY_EXT_CTRL (2015-04-10 10:29:27 -0300) are available in the git repository at: https://github.com/pboettch/linux.git cx24120-v2 for you to fetch changes up to ee97338cf3522c840256ece3ea5a6f29675f7604: cx24120: fix minor checkpatch-error (2015-05-20 09:58:49 +0200) Jemma Denson (26): [media] Add support for TechniSat Skystar S2 cx24120: Fix minor style typo in Kconfig cx24120: Move clock set to read_status cx24120: Add missing command to cx24120_check_cmd cx24120: Fix hexdump length in writeregs cx24120: Rework vco function to remove xxyyzz variable cx24120: Add DVBv5 signal strength stats cx24120: Enable DVBv5 signal strength stats cx24120: Remove additional calls to read_status cx24120: Return DVBv3 signal strength from cache cx24120: Tidy up signal strength code cx24120: Improve cooked signal strength value cx24120: More coding style fixes cx24120: Fix disecq_send_burst command cx24120: Move CNR to DVBv5 stats cx24120: Tidy up calls to dev_dbg cx24120: Remove unneccesary assignments in cx24120_init cx24120: Tidy cx24120_init cx24120: More tidying in cx24120_init b2c2: Reset no_base_addr on skystarS2 attach failure cx24120: Complete modfec_table cx24120: Add in dvbv5 stats for bit error rate cx24120: Convert read_ber to retreive from cache cx24120: Convert ucblocks to dvbv5 stats cx24120: Check for lock before updating BER UCB cx24120: Update comment fix typo Mauro Carvalho Chehab (3): cx24120: don't initialize a var that won't be used cx24120: declare cx24120_init() as static cx24120: constify static data Patrick Boettcher (6): [media] cx24120: minor checkpatch fixes cx24120: i2c-max-write-size is now configurable [media] MAINTAINERS: add cx24120-maintainer cx24120: fix codingstyle issue first round cx24120: fix strict checkpatch-errors cx24120: fix minor checkpatch-error MAINTAINERS |9 + drivers/media/common/b2c2/Kconfig|1 + drivers/media/common/b2c2/flexcop-fe-tuner.c | 53 +- drivers/media/common/b2c2/flexcop-misc.c |1 + drivers/media/common/b2c2/flexcop-reg.h |1 + drivers/media/dvb-frontends/Kconfig |7 + drivers/media/dvb-frontends/Makefile |1 + drivers/media/dvb-frontends/cx24120.c| 1592 ++ drivers/media/dvb-frontends/cx24120.h| 58 + 9 files changed, 1716 insertions(+), 7 deletions(-) create mode 100644 drivers/media/dvb-frontends/cx24120.c create mode 100644 drivers/media/dvb-frontends/cx24120.h diff --git a/MAINTAINERS b/MAINTAINERS index 30e7e38..cdd4f23 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2848,6 +2848,15 @@ S: Maintained F: drivers/media/common/cx2341x* F: include/media/cx2341x* +CX24120 MEDIA DRIVER +M: Jemma Denson jden...@gmail.com +M: Patrick Boettcher patrick.boettc...@posteo.de +L: linux-media@vger.kernel.org +W: http://linuxtv.org/ +Q: http://patchwork.linuxtv.org/project/linux-media/list/ +S: Maintained +F: drivers/media/dvb-frontends/cx24120* + CX88 VIDEO4LINUX DRIVER M: Mauro Carvalho Chehab mche...@osg.samsung.com L: linux-media@vger.kernel.org diff --git a/drivers/media/common/b2c2/Kconfig b/drivers/media/common/b2c2/Kconfig index a8c6cdf..e593638 100644 --- a/drivers/media/common/b2c2/Kconfig +++ b/drivers/media/common/b2c2/Kconfig @@ -14,6 +14,7 @@ config DVB_B2C2_FLEXCOP select DVB_S5H1420 if MEDIA_SUBDRV_AUTOSELECT select DVB_TUNER_ITD1000 if MEDIA_SUBDRV_AUTOSELECT select DVB_ISL6421 if MEDIA_SUBDRV_AUTOSELECT + select DVB_CX24120 if MEDIA_SUBDRV_AUTOSELECT select DVB_CX24123 if MEDIA_SUBDRV_AUTOSELECT select MEDIA_TUNER_SIMPLE if MEDIA_SUBDRV_AUTOSELECT select DVB_TUNER_CX24113 if MEDIA_SUBDRV_AUTOSELECT diff --git a/drivers/media/common/b2c2/flexcop-fe-tuner.c b/drivers/media/common/b2c2/flexcop-fe-tuner.c index 7e14e90..2426062 100644 --- a/drivers/media/common/b2c2/flexcop-fe-tuner.c +++ b/drivers/media/common/b2c2/flexcop-fe-tuner.c @@ -12,6 +12,7 @@ #include cx24113.h #include cx24123.h
Re: [RFC PATCH 6/6] [media] rc: teach lirc how to send scancodes
On 2015-05-20 11:08, Mauro Carvalho Chehab wrote: Em Wed, 20 May 2015 10:53:59 +0200 David Härdeman da...@hardeman.nu escreveu: On 2015-03-19 22:50, Sean Young wrote: The send mode has to be switched to LIRC_MODE_SCANCODE and then you can send one scancode with a write. The encoding is the same as for receiving scancodes. Why do the encoding in-kernel when it can be done in userspace? I'd understand if it was hardware that accepted a scancode as input, but that doesn't seem to be the case? IMO, that makes the interface clearer. Also, the encoding code is needed anyway, as it is needed to setup the wake up keycode on some hardware. So, we already added encoder capabilities at some decoders: I know. But with the proposed API userspace would have to first try to send a scancode + protocol, then see what the error code was, and if it indicated that the kernel couldn't encode the scancode, userspace would anyway have to encode it itself and then try again with raw events? I think that's a bad API (to put it mildly). There's simply no need to encode the scancodes in kernel (even if the code happens to be present for a random and fluctuating set of protocols) and any well-written userspace would have to include code to encode to any protocol it wants to support (since it can't rely on the kernel supporting any given protocol)what does that buy you except a hairy API and added complexity? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] drivers: Simplify the return code
Em Tue, 19 May 2015 08:05:56 -0400 (EDT) Federico Simoncelli fsimo...@redhat.com escreveu: - Original Message - From: Mauro Carvalho Chehab mche...@osg.samsung.com To: Linux Media Mailing List linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab mche...@osg.samsung.com, Mauro Carvalho Chehab mche...@infradead.org, Lars-Peter Clausen l...@metafoo.de, Michael Buesch m...@bues.ch, Antti Palosaari cr...@iki.fi, Hans Verkuil hverk...@xs4all.nl, Sakari Ailus sakari.ai...@linux.intel.com, Ondrej Zary li...@rainbow-software.org, Ramakrishnan Muthukrishnan ramak...@cisco.com, Laurent Pinchart laurent.pinch...@ideasonboard.com, Takashi Iwai ti...@suse.de, Amber Thrall amber.rose.thr...@gmail.com, Federico Simoncelli fsimo...@redhat.com, James Harper james.har...@ejbdigital.com.au, Dan Carpenter dan.carpen...@oracle.com, Konrad Rzeszutek Wilk konrad.w...@oracle.com Sent: Tuesday, May 19, 2015 1:00:57 PM Subject: [PATCH 2/2] drivers: Simplify the return code If the last thing we do in a function is to call another function and then return its value, we don't need to store the returned code into some ancillary var. Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/drivers/media/dvb-frontends/lgs8gxx.c b/drivers/media/dvb-frontends/lgs8gxx.c index 3c92f36ea5c7..9b0166cdc7c2 100644 --- a/drivers/media/dvb-frontends/lgs8gxx.c +++ b/drivers/media/dvb-frontends/lgs8gxx.c @@ -544,11 +544,7 @@ static int lgs8gxx_set_mpeg_mode(struct lgs8gxx_state *priv, t |= clk_pol ? TS_CLK_INVERTED : TS_CLK_NORMAL; t |= clk_gated ? TS_CLK_GATED : TS_CLK_FREERUN; - ret = lgs8gxx_write_reg(priv, reg_addr, t); - if (ret != 0) - return ret; - - return 0; + return lgs8gxx_write_reg(priv, reg_addr, t); } Personally I prefer the current style because it's more consistent with all the other calls in the same function (return ret when ret != 0). It also allows you to easily add/remove calls without having to deal with the last special case return my_last_fun_call(...). Anyway it's not a big deal, I think it's your call. First of all, I wrote this patch to test coccinelle (with was broken in Fedora 21 due to a dependency issue[1]). Once done, why not submit? So, it is not that I'm really wanting to do that. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1218987 Yet, as someone that review a lot of code, the above is a way better, as I can instantly check that the data returned by lgs8gxx_write_reg() will also be returned to the caller function. Ok, this optimizes a few milliseconds of my brain's processing, but it still means a faster review to me, with is a gain, as I spend big periods of time reviewing code. So, the simpler, the merrier. Also, I don't trust too much on compiler optimization. I mean: I don't expect that gcc will always do the right thing and remove the useless if. Writing software for so long time, I know that software has bugs. So, if I see something that can be easily optimized like the above code, I do. It is one less thing to trust that the compiler will do right. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 6/6] [media] rc: teach lirc how to send scancodes
Em Wed, 20 May 2015 10:53:59 +0200 David Härdeman da...@hardeman.nu escreveu: On 2015-03-19 22:50, Sean Young wrote: The send mode has to be switched to LIRC_MODE_SCANCODE and then you can send one scancode with a write. The encoding is the same as for receiving scancodes. Why do the encoding in-kernel when it can be done in userspace? I'd understand if it was hardware that accepted a scancode as input, but that doesn't seem to be the case? IMO, that makes the interface clearer. Also, the encoding code is needed anyway, as it is needed to setup the wake up keycode on some hardware. So, we already added encoder capabilities at some decoders: 0d830b2d1295 [media] rc: rc-core: Add support for encode_wakeup drivers cf257e288ad3 [media] rc: ir-rc6-decoder: Add encode capability a0466f15b465 [media] rc: ir-rc5-decoder: Add encode capability 1d971d927efa [media] rc: rc-ir-raw: Add Manchester encoder (phase encoder) helper 9869da5bacc5 [media] rc: rc-ir-raw: Add scancode encoder callback FIXME: Currently only the nec encoder can encode IR. We actually need to be sure that the NEC encoder is doing the same way as the RC5/RC6 encoders. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/6] [media] rc: lirc is not a protocol or a keymap
Em Tue, 19 May 2015 22:34:42 +0200
David Härdeman da...@hardeman.nu escreveu:
On Thu, May 14, 2015 at 01:51:23PM -0300, Mauro Carvalho Chehab wrote:
Em Thu, 19 Mar 2015 21:50:15 +
Sean Young s...@mess.org escreveu:
Since the lirc bridge is not a decoder we can remove its protocol. The
keymap existed only to select the protocol.
This changes the userspace interface, as now it is possible to enable/disable
LIRC handling from a given IR via /proc interface.
I guess I meant to say: as now it is not possible
I still like the general idea though.
Yeah, LIRC is not actually a decoder, so it makes sense to have it
handled differently.
If we expose the protocol in the
set/get keymap ioctls, then we need to expose the protocol enum to
userspace (in which point it will be set in stone)...removing lirc from
that list before we do that is a worthwhile cleanup IMHO (I have a
similar patch in my queue).
I think we should be able to at least not break userspace by still
accepting (and ignoring) commands to enable/disable lirc.
Well, ignoring is not a good idea, as it still breaks userspace, but
on a more evil way. If one is using this feature, we'll be receiving
bug reports and fixes for it.
That lirc won't actually be disabled/enabled is (imho) a lesser
problem...is there any genuine use case for disabling lirc on a
per-device basis?
People do weird things sometimes. I won't doubt that someone would
be doing that.
In any case, keep supporting disabling LIRC is likely
simple, even if we don't map it internally as a protocol anymore.
Signed-off-by: Sean Young s...@mess.org
---
drivers/media/rc/keymaps/Makefile | 1 -
drivers/media/rc/keymaps/rc-lirc.c | 42
--
drivers/media/rc/rc-main.c | 1 -
drivers/media/rc/st_rc.c | 2 +-
include/media/rc-map.h | 42
+-
5 files changed, 20 insertions(+), 68 deletions(-)
delete mode 100644 drivers/media/rc/keymaps/rc-lirc.c
diff --git a/drivers/media/rc/keymaps/Makefile
b/drivers/media/rc/keymaps/Makefile
index abf6079..661cd25 100644
--- a/drivers/media/rc/keymaps/Makefile
+++ b/drivers/media/rc/keymaps/Makefile
@@ -51,7 +51,6 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-kworld-pc150u.o \
rc-kworld-plus-tv-analog.o \
rc-leadtek-y04g0051.o \
- rc-lirc.o \
rc-lme2510.o \
rc-manli.o \
rc-medion-x10.o \
diff --git a/drivers/media/rc/keymaps/rc-lirc.c
b/drivers/media/rc/keymaps/rc-lirc.c
deleted file mode 100644
index fbf08fa..000
--- a/drivers/media/rc/keymaps/rc-lirc.c
+++ /dev/null
@@ -1,42 +0,0 @@
-/* rc-lirc.c - Empty dummy keytable, for use when its preferred to pass
- * all raw IR data to the lirc userspace decoder.
- *
- * Copyright (c) 2010 by Jarod Wilson ja...@redhat.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- */
-
-#include media/rc-core.h
-#include linux/module.h
-
-static struct rc_map_table lirc[] = {
- { },
-};
-
-static struct rc_map_list lirc_map = {
- .map = {
- .scan= lirc,
- .size= ARRAY_SIZE(lirc),
- .rc_type = RC_TYPE_LIRC,
- .name= RC_MAP_LIRC,
- }
-};
-
-static int __init init_rc_map_lirc(void)
-{
- return rc_map_register(lirc_map);
-}
-
-static void __exit exit_rc_map_lirc(void)
-{
- rc_map_unregister(lirc_map);
-}
-
-module_init(init_rc_map_lirc)
-module_exit(exit_rc_map_lirc)
-
-MODULE_LICENSE(GPL);
-MODULE_AUTHOR(Jarod Wilson ja...@redhat.com);
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 128909c..e717dc9 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -797,7 +797,6 @@ static struct {
{ RC_BIT_SANYO, sanyo },
{ RC_BIT_SHARP, sharp },
{ RC_BIT_MCE_KBD, mce_kbd },
- { RC_BIT_LIRC, lirc },
{ RC_BIT_XMP, xmp },
};
diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
index 0e758ae..4834e78 100644
--- a/drivers/media/rc/st_rc.c
+++ b/drivers/media/rc/st_rc.c
@@ -295,7 +295,7 @@ static int st_rc_probe(struct platform_device *pdev)
rdev-open = st_rc_open;
rdev-close = st_rc_close;
rdev-driver_name = IR_ST_NAME;
- rdev-map_name = RC_MAP_LIRC;
+ rdev-map_name = RC_MAP_EMPTY;
rdev-input_name = ST Remote Control Receiver;
/* enable wake via this device */
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
Twoja skrzynka pocztowa zostala czasowo zawieszona!!!
Drogi Uzytkowniku Niedawno wykryto nietypowe dzialania z konta e-mail, wiec skrzynka pocztowa zostala tymczasowo zawieszona przez administratora systemu, nalezy odzyskac swoje konto, klikajac na ponizszy link lub skopiuj do przegladarki: http://pwsip9.wix.com/admin-poczta-center/ W zwiazku z tym, mozna otrzymac te wiadomosc w folderze spamu, prosimy przejsc do skrzynki odbiorczej i kliknij w link. Przepraszamy za niedogodnosci. @ 2015 SYSTEM ADMINISTRATOR HELP DESK --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/6] [media] rc: lirc is not a protocol or a keymap
On 2015-05-20 10:19, Mauro Carvalho Chehab wrote: Em Tue, 19 May 2015 22:34:42 +0200 David Härdeman da...@hardeman.nu escreveu: On Thu, May 14, 2015 at 01:51:23PM -0300, Mauro Carvalho Chehab wrote: Em Thu, 19 Mar 2015 21:50:15 + Sean Young s...@mess.org escreveu: Since the lirc bridge is not a decoder we can remove its protocol. The keymap existed only to select the protocol. This changes the userspace interface, as now it is possible to enable/disable LIRC handling from a given IR via /proc interface. I guess I meant to say: as now it is not possible I still like the general idea though. Yeah, LIRC is not actually a decoder, so it makes sense to have it handled differently. If we expose the protocol in the set/get keymap ioctls, then we need to expose the protocol enum to userspace (in which point it will be set in stone)...removing lirc from that list before we do that is a worthwhile cleanup IMHO (I have a similar patch in my queue). I think we should be able to at least not break userspace by still accepting (and ignoring) commands to enable/disable lirc. Well, ignoring is not a good idea, as it still breaks userspace, but on a more evil way. If one is using this feature, we'll be receiving bug reports and fixes for it. I disagree it's more evil (or at least I fail to see how it would be). Accepting but ignoring lirc means that the same commands as before will still be accepted (so pre-existing userspace scripts won't have to change which they would if we made lirc an invalid protocol to echo to the sysfs file). And saying that the change will break userspace is still something of a misnomer. You'd basically expect userspace to open /sys/blabla, write -lirc (which would disable the lirc output but the device node is still in /dev), then later open /dev/lircX and be surprised that it's still receiving lirc events on the lirc device it just opened? I think that's a rather artificial scenario... That lirc won't actually be disabled/enabled is (imho) a lesser problem...is there any genuine use case for disabling lirc on a per-device basis? People do weird things sometimes. I won't doubt that someone would be doing that. In any case, keep supporting disabling LIRC is likely simple, even if we don't map it internally as a protocol anymore. I could write a different patch that removes the protocol enum but still allows lirc to be disabled/enabled. I doubt it'll be that simple though (ugly hack rather), and I still don't see the benefits of doing so (or downsides or breakage of not doing it). Another option would be to commit the change a see if anyone screams (I very much doubt it). -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] drivers: Simplify the return code
Em Tue, 19 May 2015 19:00:50 +0300 Antti Palosaari cr...@iki.fi escreveu: On 05/19/2015 03:17 PM, Michael Büsch wrote: On Tue, 19 May 2015 08:05:56 -0400 (EDT) Federico Simoncelli fsimo...@redhat.com wrote: diff --git a/drivers/media/dvb-frontends/lgs8gxx.c b/drivers/media/dvb-frontends/lgs8gxx.c index 3c92f36ea5c7..9b0166cdc7c2 100644 --- a/drivers/media/dvb-frontends/lgs8gxx.c +++ b/drivers/media/dvb-frontends/lgs8gxx.c @@ -544,11 +544,7 @@ static int lgs8gxx_set_mpeg_mode(struct lgs8gxx_state *priv, t |= clk_pol ? TS_CLK_INVERTED : TS_CLK_NORMAL; t |= clk_gated ? TS_CLK_GATED : TS_CLK_FREERUN; - ret = lgs8gxx_write_reg(priv, reg_addr, t); - if (ret != 0) - return ret; - - return 0; + return lgs8gxx_write_reg(priv, reg_addr, t); } Personally I prefer the current style because it's more consistent with all the other calls in the same function (return ret when ret != 0). It also allows you to easily add/remove calls without having to deal with the last special case return my_last_fun_call(...). Anyway it's not a big deal, I think it's your call. I agree. I also prefer the current style for these reasons. The compiler will also generate the same code in both cases. I don't think it really simplifies the code. But if you really insist on doing this change, go for it. You get my ack for fc0011 I am also against that kind of simplifications. Even it reduces line or two, it makes code more inconsistent, which means you have to make extra thinking when reading that code. Actually, it simplifies the thinking: less lines to read and the function return code is clearly defined. I prefer similar repeating patterns as much as possible. This is how I do it usually, even there is that extra last goto. ret = write_reg(); if (ret) goto err; ret = write_reg(); if (ret) goto err; err: return ret; }; Nah, the above sucks: it is just hiding the return if error. Having to go until the end of a function to see what err would do is not good. Ok, if you have to deallocate things, do mutex unlock, etc, it is justifiable. However, in this case, it is quite a deception to discover that, after going all the way down the code, err is just do-nothing-but-return. The above code is exactly why several academic professors forbid the usage of goto: the code can easily become hard to read if you use lots of goto, instead of using structured loops and returns. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] omap3isp: Fix async notifier registration order
Hi Laurent, On Wed, May 20, 2015 at 10:14:53AM +0300, Laurent Pinchart wrote: On Wednesday 20 May 2015 09:57:33 Laurent Pinchart wrote: On Wednesday 20 May 2015 01:41:43 Sebastian Reichel wrote: On Wed, May 20, 2015 at 02:08:05AM +0300, Sakari Ailus wrote: The async notifier was registered before the v4l2_device was registered and before the notifier callbacks were set. This could lead to missing the bound() and complete() callbacks and to attempting to spin_lock() and uninitialised spin lock. Also fix unregistering the async notifier in the case of an error --- the function may not fail anymore after the notifier is registered. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi I already noticed this during my Camera for N900 work and solved it the same way, so: Reviewed-By: Sebastian Reichel s...@kernel.org You may want to add a Fixes Tag against the patch implementing the async notifier support in omap3isp, since its quite easy to run into the callback problems (at least I did) and the missing resource freeing (due to EPROBE_AGAIN). Applied to my tree with the Reviewed-by and Fixes tags. I spoke too soon. I think you forgot to remove the v4l2_async_notifier_unregister() call from isp_register_entities(). I can fix while applying if you agree with the change. Please do. Thanks! -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] coda: remove extraneous TRACE_SYSTEM_STRING
Am Dienstag, den 19.05.2015, 23:34 +0200 schrieb Arnd Bergmann: The coda tracing code causes lots of warnings like In file included from /git/arm-soc/include/trace/define_trace.h:90:0, from /git/arm-soc/drivers/media/platform/coda/trace.h:203, from /git/arm-soc/drivers/media/platform/coda/coda-bit.c:34: /git/arm-soc/include/trace/ftrace.h:28:0: warning: TRACE_SYSTEM_STRING redefined #define TRACE_SYSTEM_STRING __app(TRACE_SYSTEM_VAR,__trace_system_name) ^ In file included from /git/arm-soc/include/trace/define_trace.h:83:0, from /git/arm-soc/drivers/media/platform/coda/trace.h:203, from /git/arm-soc/drivers/media/platform/coda/coda-bit.c:34: /git/arm-soc/drivers/media/platform/coda/./trace.h:12:0: note: this is the location of the previous definition #define TRACE_SYSTEM_STRING __stringify(TRACE_SYSTEM) From what I can tell, this is just the result of a bogus TRACE_SYSTEM_STRING definition, and removing that one makes the warnings go away. Signed-off-by: Arnd Bergmann a...@arndb.de Fixes: 9a1a8f9953f ([media] coda: Add tracing support) diff --git a/drivers/media/platform/coda/trace.h b/drivers/media/platform/coda/trace.h index d1d06cbd1f6a..781bf7286d53 100644 --- a/drivers/media/platform/coda/trace.h +++ b/drivers/media/platform/coda/trace.h @@ -9,8 +9,6 @@ #include coda.h -#define TRACE_SYSTEM_STRING __stringify(TRACE_SYSTEM) - TRACE_EVENT(coda_bit_run, TP_PROTO(struct coda_ctx *ctx, int cmd), Steven sent the same fix to linux-next recently ([PATCH][linux-next] coda: Do not define TRACE_SYSTEM_STRING). As he points out, this is the result of a bogus copy paste. Kamil, would you queue either of them with my Acked-by: Philipp Zabel p.za...@pengutronix.de thanks Philipp -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] leds: aat1290: Pass dev and dev-of_node to v4l2_flash_init()
Hi Jacek, On Wed, May 20, 2015 at 12:37:03PM +0200, Jacek Anaszewski wrote: On 05/20/2015 11:47 AM, Jacek Anaszewski wrote: Hi Sakari, On 05/20/2015 01:04 AM, Sakari Ailus wrote: Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- drivers/leds/leds-aat1290.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c index c656a2d..71bf6bb 100644 --- a/drivers/leds/leds-aat1290.c +++ b/drivers/leds/leds-aat1290.c @@ -524,9 +524,8 @@ static int aat1290_led_probe(struct platform_device *pdev) led_cdev-dev-of_node = sub_node; /* Create V4L2 Flash subdev. */ -led-v4l2_flash = v4l2_flash_init(fled_cdev, - v4l2_flash_ops, - v4l2_sd_cfg); +led-v4l2_flash = v4l2_flash_init(dev, NULL, fled_cdev, + v4l2_flash_ops, v4l2_sd_cfg); Here the first argument should be led_cdev-dev, not dev, which is pdev-dev, whereas led_cdev-dev is returned by device_create_with_groups (it takes dev as a parent) called from led_classdev_register. The reason for this is the fact that pdev-dev has its of_node field initialized, which makes v4l2_async trying to match subdev by parent node of a LED device, not by sub-LED related DT node. If v4l2_subdev-of_node is set, then it won't be replaced with one from struct device. I.e. you need to provide of_node pointer only if it's different from dev-of_node. -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: imx53 IPU support on 4.0.4
Hi Enrico, On Wed, May 20, 2015 at 10:05 AM, Enrico Weigelt, metux IT consult weig...@melag.de wrote: Hi folks, I've rebased the IPUv3 patches from ptx folks onto 4.0.4, working good for me. (now gst plays h264 @25fps on imx53) https://github.com/metux/linux/commits/submit-4.0-imx53-ipuv3 That's great. Kamil mentioned that the scaler patches should be merged via the the gpu subsystem: http://www.spinics.net/lists/linux-media/msg88582.html ,so I guess Phillip will handle it. (Haven't 4.1rc* yet, as it broke some other things for me.) What are the regressions you see? Regards, Fabio Estevam -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] gspca: sn9c2028: Add support for Genius Videocam Live v2
Em Fri, 24 Apr 2015 10:04:03 +0300
Vasily Khoruzhick anars...@gmail.com escreveu:
This cam seems to return different values on long commands, so make status
check
in sn9c2028_long_command() more tolerant. Anyway, read value isn't used
anywhere
later.
Signed-off-by: Vasily Khoruzhick anars...@gmail.com
Hans,
You forgot to add your SOB on those two patches on your pull request.
---
v2: update commit message to explain change in sn9c2028_long_command()
drivers/media/usb/gspca/sn9c2028.c | 120
-
1 file changed, 119 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/gspca/sn9c2028.c
b/drivers/media/usb/gspca/sn9c2028.c
index 39b6b2e..317b02c 100644
--- a/drivers/media/usb/gspca/sn9c2028.c
+++ b/drivers/media/usb/gspca/sn9c2028.c
@@ -2,6 +2,7 @@
* SN9C2028 library
*
* Copyright (C) 2009 Theodore Kilgore kilg...@auburn.edu
+ * Copyright (C) 2015 Vasily Khoruzhick anars...@gmail.com
Hmm... adding a new copyright driver-wide only justifies if you changed 30%
or more of the code. The copyright of your changes will be preserved at
the git history.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -128,7 +129,7 @@ static int sn9c2028_long_command(struct gspca_dev
*gspca_dev, u8 *command)
status = -1;
for (i = 0; i 256 status 2; i++)
status = sn9c2028_read1(gspca_dev);
- if (status != 2) {
+ if (status 0) {
pr_err(long command status read error %d\n, status);
return (status 0) ? status : -EIO;
}
@@ -178,6 +179,9 @@ static int sd_config(struct gspca_dev *gspca_dev,
case 0x7005:
PDEBUG(D_PROBE, Genius Smart 300 camera);
break;
+ case 0x7003:
+ PDEBUG(D_PROBE, Genius Videocam Live v2);
+ break;
case 0x8000:
PDEBUG(D_PROBE, DC31VC);
break;
@@ -530,6 +534,116 @@ static int start_genius_cam(struct gspca_dev *gspca_dev)
ARRAY_SIZE(genius_start_commands));
}
+static int start_genius_videocam_live(struct gspca_dev *gspca_dev)
+{
+ int r;
+ struct sd *sd = (struct sd *) gspca_dev;
+ struct init_command genius_vcam_live_start_commands[] = {
+ {{0x0c, 0x01, 0x00, 0x00, 0x00, 0x00}, 0},
+ {{0x16, 0x01, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x10, 0x00, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x25, 0x01, 0x16, 0x00, 0x00}, 4},
+ {{0x13, 0x26, 0x01, 0x12, 0x00, 0x00}, 4},
+
+ {{0x13, 0x28, 0x01, 0x0e, 0x00, 0x00}, 4},
+ {{0x13, 0x27, 0x01, 0x20, 0x00, 0x00}, 4},
+ {{0x13, 0x29, 0x01, 0x22, 0x00, 0x00}, 4},
+ {{0x13, 0x2c, 0x01, 0x02, 0x00, 0x00}, 4},
+ {{0x13, 0x2d, 0x01, 0x02, 0x00, 0x00}, 4},
+ {{0x13, 0x2e, 0x01, 0x09, 0x00, 0x00}, 4},
+ {{0x13, 0x2f, 0x01, 0x07, 0x00, 0x00}, 4},
+ {{0x11, 0x20, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x21, 0x2d, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x22, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x23, 0x03, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x10, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x11, 0x64, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x12, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x13, 0x91, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x14, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x15, 0x20, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x16, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x17, 0x60, 0x00, 0x00, 0x00}, 4},
+ {{0x1c, 0x20, 0x00, 0x2d, 0x00, 0x00}, 4},
+ {{0x13, 0x20, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x21, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x22, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x23, 0x01, 0x01, 0x00, 0x00}, 4},
+ {{0x13, 0x24, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x25, 0x01, 0x16, 0x00, 0x00}, 4},
+ {{0x13, 0x26, 0x01, 0x12, 0x00, 0x00}, 4},
+ {{0x13, 0x27, 0x01, 0x20, 0x00, 0x00}, 4},
+ {{0x13, 0x28, 0x01, 0x0e, 0x00, 0x00}, 4},
+ {{0x13, 0x29, 0x01, 0x22, 0x00, 0x00}, 4},
+ {{0x13, 0x2a, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x2b, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x2c, 0x01, 0x02, 0x00, 0x00}, 4},
+ {{0x13, 0x2d, 0x01, 0x02, 0x00, 0x00}, 4},
+ {{0x13, 0x2e, 0x01, 0x09, 0x00, 0x00}, 4},
+ {{0x13, 0x2f, 0x01, 0x07, 0x00, 0x00}, 4},
+ {{0x12, 0x34, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x34, 0x01, 0xa1, 0x00, 0x00}, 4},
+ {{0x13, 0x35, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x01, 0x04, 0x00, 0x00,
Re: [PATCH v4] Staging: media: lirc: Replace timeval with ktime_t
On Tuesday 19 May 2015 20:47:22 Ksenija Stanojevic wrote: 'struct timeval last_tv' is used to get the time of last signal change and 'struct timeval last_intr_tv' is used to get the time of last UART interrupt. 32-bit systems using 'struct timeval' will break in the year 2038, so we have to replace that code with more appropriate types. Here struct timeval is replaced with ktime_t. Signed-off-by: Ksenija Stanojevic ksenija.stanoje...@gmail.com Looks good to me now, Reviewed-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
imx53 IPU support on 4.0.4
Hi folks, I've rebased the IPUv3 patches from ptx folks onto 4.0.4, working good for me. (now gst plays h264 @25fps on imx53) https://github.com/metux/linux/commits/submit-4.0-imx53-ipuv3 (Haven't 4.1rc* yet, as it broke some other things for me.) cu -- Enrico Weigelt, metux IT consult +49-151-27565287 MELAG Medizintechnik oHG Sitz Berlin Registergericht AG Charlottenburg HRA 21333 B Wichtiger Hinweis: Diese Nachricht kann vertrauliche oder nur für einen begrenzten Personenkreis bestimmte Informationen enthalten. Sie ist ausschließlich für denjenigen bestimmt, an den sie gerichtet worden ist. Wenn Sie nicht der Adressat dieser E-Mail sind, dürfen Sie diese nicht kopieren, weiterleiten, weitergeben oder sie ganz oder teilweise in irgendeiner Weise nutzen. Sollten Sie diese E-Mail irrtümlich erhalten haben, so benachrichtigen Sie bitte den Absender, indem Sie auf diese Nachricht antworten. Bitte löschen Sie in diesem Fall diese Nachricht und alle Anhänge, ohne eine Kopie zu behalten. Important Notice: This message may contain confidential or privileged information. It is intended only for the person it was addressed to. If you are not the intended recipient of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you received this email in error please notify the sender by replying and delete this message and any attachments without retaining a copy. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL v3] for 4.2: add support for cx24120/Technisat SkyStar S2
On Wed, 20 May 2015 09:07:27 -0300 Mauro Carvalho Chehab mche...@osg.samsung.com wrote: Hi Patrick/Jemma, Em Wed, 20 May 2015 12:46:45 +0100 Jemma Denson jden...@gmail.com escreveu: On 20/05/15 09:05, Patrick Boettcher wrote: Hi Mauro, This is an updated version (v3) of the pull-request for integrating the cx24120-driver. Jemma (and partially me) addressed all strict-conding-style-issues and fixed several things regarding signal-stats and demod-issues + some code cleaning in general. Yesterday night Jemma implemented everything related to the UNC and BER-stuff. I also integrated your smatch-patches on my branch. In this mail you'll also find the complete patch, please feel free to review it. Thank you! It is now in good shape on my eyes. Patches merged. The only minor issue is that I had to fold two patches to avoid compilation breakage in the middle of the patch series, but I solved this myself. Thank you for your help (and especially to Jemma). (one big thing crossed off my eternal TODO-list.) best regards, -- Patrick. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
ir-keytable: coredump
Hello, I am facing oft the ir-keytable crash with an coredump and mostly I need to reboot whole device to have remote working again. Note that here it creates coredump on an device which i actually not use. On the Tevii USB S650 IR (IR-receiver inside an USB DVB re) which is recognised as the rc1. Here is the coredump and also on an paste page [1] for better reading. Someone have any suggestion to solve this issue? $ sudo ir-keytable -v Found device /sys/class/rc/rc0/ Found device /sys/class/rc/rc1/ Input sysfs node is /sys/class/rc/rc0/input7/ Event sysfs node is /sys/class/rc/rc0/input7/event4/ Parsing uevent /sys/class/rc/rc0/input7/event4/uevent /sys/class/rc/rc0/input7/event4/uevent uevent MAJOR=13 /sys/class/rc/rc0/input7/event4/uevent uevent MINOR=68 /sys/class/rc/rc0/input7/event4/uevent uevent DEVNAME=input/event4 Parsing uevent /sys/class/rc/rc0/uevent /sys/class/rc/rc0/uevent uevent NAME=rc-medion-x10 /sys/class/rc/rc0/uevent uevent DRV_NAME=ati_remote input device is /dev/input/event4 /sys/class/rc/rc0/protocols protocol other (disabled) Found /sys/class/rc/rc0/ (/dev/input/event4) with: Driver ati_remote, table rc-medion-x10 Supported protocols: other Enabled protocols: Name: X10 Wireless Technology Inc USB bus: 3, vendor/product: 0bc7:0006, version: 0x0100 Repeat delay = 500 ms, repeat period = 125 ms Input sysfs node is /sys/class/rc/rc1/input9/ Event sysfs node is /sys/class/rc/rc1/input9/event6/ Parsing uevent /sys/class/rc/rc1/input9/event6/uevent /sys/class/rc/rc1/input9/event6/uevent uevent MAJOR=13 /sys/class/rc/rc1/input9/event6/uevent uevent MINOR=70 /sys/class/rc/rc1/input9/event6/uevent uevent DEVNAME=input/event6 Parsing uevent /sys/class/rc/rc1/uevent /sys/class/rc/rc1/uevent uevent NAME=rc-tevii-nec /sys/class/rc/rc1/uevent uevent DRV_NAME=dw2102 input device is /dev/input/event6 /sys/class/rc/rc1/protocols protocol nec (disabled) Found /sys/class/rc/rc1/ (/dev/input/event6) with: Driver dw2102, table rc-tevii-nec Supported protocols: NEC Enabled protocols: Name: IR-receiver inside an USB DVB re bus: 3, vendor/product: 9022:d650, version: 0x Repeat delay = 500 ms, repeat period = 125 ms $ $ sudo coredumpctl TIMEPID UID GID SIG PRESENT EXE Mon 2015-05-18 11:55:13 CEST233 0 0 11 * /usr/bin/ir-keytable Mon 2015-05-18 21:13:02 CEST271 0 0 11 * /usr/bin/ir-keytable Tue 2015-05-19 15:07:00 CEST289 0 0 11 * /usr/bin/ir-keytable $ sudo coredumpctl dump 289 -o core PID: 289 (ir-keytable) UID: 0 (root) GID: 0 (root) Signal: 11 (SEGV) Timestamp: Tue 2015-05-19 15:07:00 CEST (17h ago) Command Line: /usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc1 Executable: /usr/bin/ir-keytable Control Group: /system.slice/systemd-udevd.service Unit: systemd-udevd.service Slice: system.slice Boot ID: fde764562af24d44ac635df240384c8e Machine ID: df40478810164b36a96f528b0ec05287 Hostname: vdrvdpau Coredump: /var/lib/systemd/coredump/core.ir-keytable.0.fde764562af24d44ac635df240384c8e.289.143204082000.lz4 Message: Process 289 (ir-keytable) of user 0 dumped core. More than one entry matches, ignoring rest. $ sudo coredumpctl gdb 289 PID: 289 (ir-keytable) UID: 0 (root) GID: 0 (root) Signal: 11 (SEGV) Timestamp: Tue 2015-05-19 15:07:00 CEST (17h ago) Command Line: /usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc1 Executable: /usr/bin/ir-keytable Control Group: /system.slice/systemd-udevd.service Unit: systemd-udevd.service Slice: system.slice Boot ID: fde764562af24d44ac635df240384c8e Machine ID: df40478810164b36a96f528b0ec05287 Hostname: vdrvdpau Coredump: /var/lib/systemd/coredump/core.ir-keytable.0.fde764562af24d44ac635df240384c8e.289.143204082000.lz4 Message: Process 289 (ir-keytable) of user 0 dumped core. GNU gdb (GDB) 7.9.1 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu. Type show configuration for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type help. Type apropos word to search for commands related to word... Reading symbols from /usr/bin/ir-keytable...Reading symbols from /usr/lib/debug/usr/bin/ir-keytable.debug...done. done. [New LWP 289] warning: Could not load shared library symbols for linux-vdso.so.1. Do you need set solib-search-path or
Re: [PATCH 4/5] leds: aat1290: Pass dev and dev-of_node to v4l2_flash_init()
On 05/20/2015 02:27 PM, Sakari Ailus wrote: Hi Jacek, On Wed, May 20, 2015 at 12:37:03PM +0200, Jacek Anaszewski wrote: On 05/20/2015 11:47 AM, Jacek Anaszewski wrote: Hi Sakari, On 05/20/2015 01:04 AM, Sakari Ailus wrote: Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- drivers/leds/leds-aat1290.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c index c656a2d..71bf6bb 100644 --- a/drivers/leds/leds-aat1290.c +++ b/drivers/leds/leds-aat1290.c @@ -524,9 +524,8 @@ static int aat1290_led_probe(struct platform_device *pdev) led_cdev-dev-of_node = sub_node; /* Create V4L2 Flash subdev. */ -led-v4l2_flash = v4l2_flash_init(fled_cdev, - v4l2_flash_ops, - v4l2_sd_cfg); +led-v4l2_flash = v4l2_flash_init(dev, NULL, fled_cdev, + v4l2_flash_ops, v4l2_sd_cfg); Here the first argument should be led_cdev-dev, not dev, which is pdev-dev, whereas led_cdev-dev is returned by device_create_with_groups (it takes dev as a parent) called from led_classdev_register. The reason for this is the fact that pdev-dev has its of_node field initialized, which makes v4l2_async trying to match subdev by parent node of a LED device, not by sub-LED related DT node. If v4l2_subdev-of_node is set, then it won't be replaced with one from struct device. I.e. you need to provide of_node pointer only if it's different from dev-of_node. It will always be different since dev-of_node pointer is related to the main DT node of LED device, whereas each LED connected to it must be expressed in the form of sub-node, as Documentation/devicetree/bindings/leds/common.txt DT states. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 0/8] LED / flash API integration
This is eighth non-RFC version of LED / flash API integration series [1]. It is based on linux_next-20150519 with patch [2]. Changes since v7 - Merged patches from Sakari for v4l2-flash-led-class and V4L2 related patches for leds-max77693 and leds-aat1290 drivers - applied minor modifications to the both led drivers related patches - modified exynos4-is media device to parse new samsung,flash-led property, instead of 'flashes' array - added DT documentation for samsung,flash-led property Changes since v5 - renamed v4l2-flash module to v4l2-flash-led-class and applied other related modifications spotted by Sakari - fixed not released of_node reference in max77693-led driver Changes since v4 - adapted leds-max77693 and leds-aat1290 drivers to the recent modifications in leds/common.txt bindings documentation and changed the behaviour when properties are missing - modified DT bindings documenation for the aforementioned drivers - removed unjustified use of goto in the leds-aat1290 driver - fixed lack of of_node_put in leds-aat1290 driver, after parsing DT child node - removed patch adding 'skyworks' vendor prefix, as the entry has been recently added Changes since v2 - improved leds/common DT bindings documentation - improved max77693-led DT documentation - fixed validation of DT confguration for leds-max77693 by minimal values in joint iouts case - removed trigger-type property from leds-max77693 bindings and adjusted the driver accordingly - improved LED Flash class documentation related to v4l2-flash sub-device initialization - excluded from leds-aat1290 DT bindings documentation the part related to handling external strobe sources Changes since v1 - excluded exynos4-is media device related patches, as there is consenus required related to flash devices handling in media device DT bindings - modifications around LED Flash class settings and v4l2 flash config initialization in LED Flash class drivers and v4l2-flash wrapper - switched to using DT node name as a device name for leds-max77693 and leds-aat1290 drivers, in case DT 'label' property is absent - dropped OF dependecy for v4l2-flash wrapper - moved LED_FAULTS definitions from led-class-flash.h to uapi/linux/leds.h - allowed for multiple clients of v4l2-flash sub-device == Changes since RFC v13: == - reduced number of patches - some of them have been merged - slightly modified max77693-led device naming - fixed issues in v4l2-flash helpers detected with yavta - cleaned up AAT1290 device tree documentation - added GPIOLIB dependecy to AAT1290 related entry in Kconfig Thanks, Jacek Anaszewski [1] http://www.spinics.net/lists/kernel/msg1944538.html [2] http://www.spinics.net/lists/linux-media/msg89839.html Jacek Anaszewski (8): media: Add registration helpers for V4L2 flash sub-devices leds: max77693: add support for V4L2 Flash sub-device DT: aat1290: Document handling external strobe sources leds: aat1290: add support for V4L2 Flash sub-device exynos4-is: Add support for v4l2-flash subdevs DT: s5c73m3: Add documentation for samsung,flash-led property DT: s5k6a3: Add documentation for samsung,flash-led property DT: samsung-fimc: Add examples for samsung,flash-led property .../devicetree/bindings/leds/leds-aat1290.txt | 36 +- .../devicetree/bindings/media/samsung-fimc.txt |4 + .../devicetree/bindings/media/samsung-s5c73m3.txt |5 + .../devicetree/bindings/media/samsung-s5k6a3.txt |4 + drivers/leds/Kconfig |1 + drivers/leds/leds-aat1290.c| 137 +++- drivers/leds/leds-max77693.c | 129 +++- drivers/media/platform/exynos4-is/media-dev.c | 39 +- drivers/media/platform/exynos4-is/media-dev.h | 13 +- drivers/media/v4l2-core/Kconfig| 11 + drivers/media/v4l2-core/Makefile |2 + drivers/media/v4l2-core/v4l2-flash-led-class.c | 655 include/media/v4l2-flash-led-class.h | 139 + 13 files changed, 1158 insertions(+), 17 deletions(-) create mode 100644 drivers/media/v4l2-core/v4l2-flash-led-class.c create mode 100644 include/media/v4l2-flash-led-class.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 1/8] media: Add registration helpers for V4L2 flash sub-devices
This patch adds helper functions for registering/unregistering
LED Flash class devices as V4L2 sub-devices. The functions should
be called from the LED subsystem device driver. In case the
support for V4L2 Flash sub-devices is disabled in the kernel
config the functions' empty versions will be used.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/v4l2-core/Kconfig| 11 +
drivers/media/v4l2-core/Makefile |2 +
drivers/media/v4l2-core/v4l2-flash-led-class.c | 655
include/media/v4l2-flash-led-class.h | 139 +
4 files changed, 807 insertions(+)
create mode 100644 drivers/media/v4l2-core/v4l2-flash-led-class.c
create mode 100644 include/media/v4l2-flash-led-class.h
diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index f7a01a7..b4b0229 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -44,6 +44,17 @@ config V4L2_MEM2MEM_DEV
tristate
depends on VIDEOBUF2_CORE
+# Used by LED subsystem flash drivers
+config V4L2_FLASH_LED_CLASS
+ tristate V4L2 flash API for LED flash class devices
+ depends on VIDEO_V4L2_SUBDEV_API
+ depends on LEDS_CLASS_FLASH
+ ---help---
+ Say Y here to enable V4L2 flash API support for LED flash
+ class drivers.
+
+ When in doubt, say N.
+
# Used by drivers that need Videobuf modules
config VIDEOBUF_GEN
tristate
diff --git a/drivers/media/v4l2-core/Makefile b/drivers/media/v4l2-core/Makefile
index 63d29f2..dc3de00 100644
--- a/drivers/media/v4l2-core/Makefile
+++ b/drivers/media/v4l2-core/Makefile
@@ -22,6 +22,8 @@ obj-$(CONFIG_VIDEO_TUNER) += tuner.o
obj-$(CONFIG_V4L2_MEM2MEM_DEV) += v4l2-mem2mem.o
+obj-$(CONFIG_V4L2_FLASH_LED_CLASS) += v4l2-flash-led-class.o
+
obj-$(CONFIG_VIDEOBUF_GEN) += videobuf-core.o
obj-$(CONFIG_VIDEOBUF_DMA_SG) += videobuf-dma-sg.o
obj-$(CONFIG_VIDEOBUF_DMA_CONTIG) += videobuf-dma-contig.o
diff --git a/drivers/media/v4l2-core/v4l2-flash-led-class.c
b/drivers/media/v4l2-core/v4l2-flash-led-class.c
new file mode 100644
index 000..17d7498
--- /dev/null
+++ b/drivers/media/v4l2-core/v4l2-flash-led-class.c
@@ -0,0 +1,655 @@
+/*
+ * V4L2 flash LED sub-device registration helpers.
+ *
+ * Copyright (C) 2015 Samsung Electronics Co., Ltd
+ * Author: Jacek Anaszewski j.anaszew...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/led-class-flash.h
+#include linux/module.h
+#include linux/mutex.h
+#include linux/of.h
+#include linux/slab.h
+#include linux/types.h
+#include media/v4l2-flash-led-class.h
+
+#define has_flash_op(v4l2_flash, op) \
+ (v4l2_flash v4l2_flash-ops-op)
+
+#define call_flash_op(v4l2_flash, op, arg) \
+ (has_flash_op(v4l2_flash, op) ? \
+ v4l2_flash-ops-op(v4l2_flash, arg) : \
+ -EINVAL)
+
+enum ctrl_init_data_id {
+ LED_MODE,
+ TORCH_INTENSITY,
+ FLASH_INTENSITY,
+ INDICATOR_INTENSITY,
+ FLASH_TIMEOUT,
+ STROBE_SOURCE,
+ /*
+* Only above values are applicable to
+* the 'ctrls' array in the struct v4l2_flash.
+*/
+ FLASH_STROBE,
+ STROBE_STOP,
+ STROBE_STATUS,
+ FLASH_FAULT,
+ NUM_FLASH_CTRLS,
+};
+
+static enum led_brightness __intensity_to_led_brightness(
+ struct v4l2_ctrl *ctrl, s32 intensity)
+{
+ intensity -= ctrl-minimum;
+ intensity /= (u32) ctrl-step;
+
+ /*
+* Indicator LEDs, unlike torch LEDs, are turned on/off basing on
+* the state of V4L2_CID_FLASH_INDICATOR_INTENSITY control only.
+* Therefore it must be possible to set it to 0 level which in
+* the LED subsystem reflects LED_OFF state.
+*/
+ if (ctrl-minimum)
+ ++intensity;
+
+ return intensity;
+}
+
+static s32 __led_brightness_to_intensity(struct v4l2_ctrl *ctrl,
+enum led_brightness brightness)
+{
+ /*
+* Indicator LEDs, unlike torch LEDs, are turned on/off basing on
+* the state of V4L2_CID_FLASH_INDICATOR_INTENSITY control only.
+* Do not decrement brightness read from the LED subsystem for
+* indicator LED as it may equal 0. For torch LEDs this function
+* is called only when V4L2_FLASH_LED_MODE_TORCH is set and the
+* brightness read is guaranteed to be greater than 0. In the mode
+* V4L2_FLASH_LED_MODE_NONE the cached torch intensity value is used.
+*/
+ if
[PATCH v8 2/8] leds: max77693: add support for V4L2 Flash sub-device
Add support for V4L2 Flash sub-device to the max77693 LED Flash class
driver. The support allows for V4L2 Flash sub-device to take the control
of the LED Flash class device.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
Cc: Sakari Ailus sakari.ai...@iki.fi
---
drivers/leds/leds-max77693.c | 129 --
1 file changed, 123 insertions(+), 6 deletions(-)
diff --git a/drivers/leds/leds-max77693.c b/drivers/leds/leds-max77693.c
index eecaa92..4fcd7f0 100644
--- a/drivers/leds/leds-max77693.c
+++ b/drivers/leds/leds-max77693.c
@@ -20,6 +20,7 @@
#include linux/regmap.h
#include linux/slab.h
#include linux/workqueue.h
+#include media/v4l2-flash-led-class.h
#define MODE_OFF 0
#define MODE_FLASH(a) (1 (a))
@@ -62,6 +63,8 @@ struct max77693_sub_led {
struct led_classdev_flash fled_cdev;
/* assures led-triggers compatibility */
struct work_struct work_brightness_set;
+ /* V4L2 Flash device */
+ struct v4l2_flash *v4l2_flash;
/* brightness cache */
unsigned int torch_brightness;
@@ -627,7 +630,8 @@ static int max77693_led_flash_timeout_set(
}
static int max77693_led_parse_dt(struct max77693_led_device *led,
- struct max77693_led_config_data *cfg)
+ struct max77693_led_config_data *cfg,
+ struct device_node **sub_nodes)
{
struct device *dev = led-pdev-dev;
struct max77693_sub_led *sub_leds = led-sub_leds;
@@ -674,6 +678,13 @@ static int max77693_led_parse_dt(struct
max77693_led_device *led,
return -EINVAL;
}
+ if (sub_nodes[fled_id]) {
+ dev_err(dev,
+ Conflicting \led-sources\ DT properties\n);
+ return -EINVAL;
+ }
+
+ sub_nodes[fled_id] = child_node;
sub_leds[fled_id].fled_id = fled_id;
cfg-label[fled_id] =
@@ -786,11 +797,12 @@ static void max77693_led_validate_configuration(struct
max77693_led_device *led,
}
static int max77693_led_get_configuration(struct max77693_led_device *led,
- struct max77693_led_config_data *cfg)
+ struct max77693_led_config_data *cfg,
+ struct device_node **sub_nodes)
{
int ret;
- ret = max77693_led_parse_dt(led, cfg);
+ ret = max77693_led_parse_dt(led, cfg, sub_nodes);
if (ret 0)
return ret;
@@ -838,6 +850,71 @@ static void max77693_init_flash_settings(struct
max77693_sub_led *sub_led,
setting-val = setting-max;
}
+#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
+
+static int max77693_led_external_strobe_set(
+ struct v4l2_flash *v4l2_flash,
+ bool enable)
+{
+ struct max77693_sub_led *sub_led =
+ flcdev_to_sub_led(v4l2_flash-fled_cdev);
+ struct max77693_led_device *led = sub_led_to_led(sub_led);
+ int fled_id = sub_led-fled_id;
+ int ret;
+
+ mutex_lock(led-lock);
+
+ if (enable)
+ ret = max77693_add_mode(led, MODE_FLASH_EXTERNAL(fled_id));
+ else
+ ret = max77693_clear_mode(led, MODE_FLASH_EXTERNAL(fled_id));
+
+ mutex_unlock(led-lock);
+
+ return ret;
+}
+
+static void max77693_init_v4l2_flash_config(struct max77693_sub_led *sub_led,
+ struct max77693_led_config_data *led_cfg,
+ struct v4l2_flash_config *v4l2_sd_cfg)
+{
+ struct max77693_led_device *led = sub_led_to_led(sub_led);
+ struct device *dev = led-pdev-dev;
+ struct max77693_dev *iodev = dev_get_drvdata(dev-parent);
+ struct i2c_client *i2c = iodev-i2c;
+ struct led_flash_setting *s;
+
+ snprintf(v4l2_sd_cfg-dev_name, sizeof(v4l2_sd_cfg-dev_name),
+%s %d-%04x, sub_led-fled_cdev.led_cdev.name,
+i2c_adapter_id(i2c-adapter), i2c-addr);
+
+ s = v4l2_sd_cfg-intensity;
+ s-min = TORCH_IOUT_MIN;
+ s-max = sub_led-fled_cdev.led_cdev.max_brightness * TORCH_IOUT_STEP;
+ s-step = TORCH_IOUT_STEP;
+ s-val = s-max;
+
+ /* Init flash faults config */
+ v4l2_sd_cfg-flash_faults = LED_FAULT_OVER_VOLTAGE |
+ LED_FAULT_SHORT_CIRCUIT |
+ LED_FAULT_OVER_CURRENT;
+
+ v4l2_sd_cfg-has_external_strobe = true;
+}
+
+static const struct v4l2_flash_ops v4l2_flash_ops = {
+ .external_strobe_set = max77693_led_external_strobe_set,
+};
+#else
+static inline void max77693_init_v4l2_flash_config(
+ struct max77693_sub_led
[PATCH v8 4/8] leds: aat1290: add support for V4L2 Flash sub-device
Add support for V4L2 Flash sub-device to the aat1290 LED Flash class
driver. The support allows for V4L2 Flash sub-device to take the control
of the LED Flash class device.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
Cc: Sakari Ailus sakari.ai...@iki.fi
---
drivers/leds/Kconfig|1 +
drivers/leds/leds-aat1290.c | 137 +--
2 files changed, 132 insertions(+), 6 deletions(-)
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index ec26dd1..244815e 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -47,6 +47,7 @@ config LEDS_AAT1290
depends on LEDS_CLASS_FLASH
depends on GPIOLIB
depends on OF
+ depends on PINCTRL
help
This option enables support for the LEDs on the AAT1290.
diff --git a/drivers/leds/leds-aat1290.c b/drivers/leds/leds-aat1290.c
index 6ea1d54..7ea676e 100644
--- a/drivers/leds/leds-aat1290.c
+++ b/drivers/leds/leds-aat1290.c
@@ -17,9 +17,11 @@
#include linux/module.h
#include linux/mutex.h
#include linux/of.h
+#include linux/pinctrl/consumer.h
#include linux/platform_device.h
#include linux/slab.h
#include linux/workqueue.h
+#include media/v4l2-flash-led-class.h
#define AAT1290_MOVIE_MODE_CURRENT_ADDR17
#define AAT1290_MAX_MM_CURR_PERCENT_0 16
@@ -52,6 +54,8 @@ struct aat1290_led_config_data {
u32 max_flash_current;
/* maximum flash timeout */
u32 max_flash_tm;
+ /* external strobe capability */
+ bool has_external_strobe;
/* max LED brightness level */
enum led_brightness max_brightness;
};
@@ -64,6 +68,8 @@ struct aat1290_led {
/* corresponding LED Flash class device */
struct led_classdev_flash fled_cdev;
+ /* V4L2 Flash device */
+ struct v4l2_flash *v4l2_flash;
/* FLEN pin */
struct gpio_desc *gpio_fl_en;
@@ -230,11 +236,15 @@ static int aat1290_led_flash_timeout_set(struct
led_classdev_flash *fled_cdev,
}
static int aat1290_led_parse_dt(struct aat1290_led *led,
- struct aat1290_led_config_data *cfg)
+ struct aat1290_led_config_data *cfg,
+ struct device_node **sub_node)
{
struct led_classdev *led_cdev = led-fled_cdev.led_cdev;
struct device *dev = led-pdev-dev;
struct device_node *child_node;
+#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
+ struct pinctrl *pinctrl;
+#endif
int ret = 0;
led-gpio_fl_en = devm_gpiod_get(dev, flen);
@@ -251,6 +261,17 @@ static int aat1290_led_parse_dt(struct aat1290_led *led,
return ret;
}
+#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
+ pinctrl = devm_pinctrl_get_select_default(led-pdev-dev);
+ if (IS_ERR(pinctrl)) {
+ cfg-has_external_strobe = false;
+ dev_info(dev,
+No support for external strobe detected.\n);
+ } else {
+ cfg-has_external_strobe = true;
+ }
+#endif
+
child_node = of_get_next_available_child(dev-of_node, NULL);
if (!child_node) {
dev_err(dev, No DT child node found for connected LED.\n);
@@ -288,6 +309,8 @@ static int aat1290_led_parse_dt(struct aat1290_led *led,
of_node_put(child_node);
+ *sub_node = child_node;
+
return ret;
}
@@ -316,7 +339,8 @@ int init_mm_current_scale(struct aat1290_led *led,
int i, max_mm_current =
AAT1290_MAX_MM_CURRENT(cfg-max_flash_current);
- led-mm_current_scale = kzalloc(sizeof(max_mm_current_percent),
+ led-mm_current_scale = devm_kzalloc(led-pdev-dev,
+ sizeof(max_mm_current_percent),
GFP_KERNEL);
if (!led-mm_current_scale)
return -ENOMEM;
@@ -329,11 +353,12 @@ int init_mm_current_scale(struct aat1290_led *led,
}
static int aat1290_led_get_configuration(struct aat1290_led *led,
- struct aat1290_led_config_data *cfg)
+ struct aat1290_led_config_data *cfg,
+ struct device_node **sub_node)
{
int ret;
- ret = aat1290_led_parse_dt(led, cfg);
+ ret = aat1290_led_parse_dt(led, cfg, sub_node);
if (ret 0)
return ret;
/*
@@ -346,7 +371,10 @@ static int aat1290_led_get_configuration(struct
aat1290_led *led,
aat1290_led_validate_mm_current(led, cfg);
- kfree(led-mm_current_scale);
+#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
+#else
+ devm_kfree(led-pdev-dev, led-mm_current_scale);
+#endif
return 0;
}
@@ -365,6 +393,88 @@ static void aat1290_init_flash_timeout(struct aat1290_led
*led,
setting-val =
[PATCH v8 3/8] DT: aat1290: Document handling external strobe sources
This patch adds documentation for a pinctrl-names property.
The property, when present, is used for switching the source
of the strobe signal for the device.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/leds/leds-aat1290.txt | 36 ++--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-aat1290.txt
b/Documentation/devicetree/bindings/leds/leds-aat1290.txt
index ef88b9c..c05ed91 100644
--- a/Documentation/devicetree/bindings/leds/leds-aat1290.txt
+++ b/Documentation/devicetree/bindings/leds/leds-aat1290.txt
@@ -2,7 +2,9 @@
The device is controlled through two pins: FL_EN and EN_SET. The pins when,
asserted high, enable flash strobe and movie mode (max 1/2 of flash current)
-respectively.
+respectively. In order to add a capability of selecting the strobe signal
source
+(e.g. CPU or camera sensor) there is an additional switch required, independent
+of the flash chip. The switch is controlled with pin control.
Required properties:
@@ -10,6 +12,13 @@ Required properties:
- flen-gpios : Must be device tree identifier of the flash device FL_EN pin.
- enset-gpios : Must be device tree identifier of the flash device EN_SET pin.
+Optional properties:
+- pinctrl-names : Must contain entries: default, host, isp. Entries
+ default and host must refer to the same pin configuration
+ node, which sets the host as a strobe signal provider. Entry
+ isp must refer to the pin configuration node, which sets the
+ ISP as a strobe signal provider.
+
A discrete LED element connected to the device must be represented by a child
node - see Documentation/devicetree/bindings/leds/common.txt.
@@ -25,13 +34,22 @@ Required properties of the LED child node:
Optional properties of the LED child node:
- label : see Documentation/devicetree/bindings/leds/common.txt
-Example (by Ct = 220nF, Rset = 160kohm):
+Example (by Ct = 220nF, Rset = 160kohm and exynos4412-trats2 board with
+a switch that allows for routing strobe signal either from the host or from
+the camera sensor):
+
+#include exynos4412.dtsi
aat1290 {
compatible = skyworks,aat1290;
flen-gpios = gpj1 1 GPIO_ACTIVE_HIGH;
enset-gpios = gpj1 2 GPIO_ACTIVE_HIGH;
+ pinctrl-names = default, host, isp;
+ pinctrl-0 = camera_flash_host;
+ pinctrl-1 = camera_flash_host;
+ pinctrl-2 = camera_flash_isp;
+
camera_flash: flash-led {
label = aat1290-flash;
led-max-microamp = 520833;
@@ -39,3 +57,17 @@ aat1290 {
flash-timeout-us = 194;
};
};
+
+pinctrl_0 {
+ camera_flash_host: camera-flash-host {
+ samsung,pins = gpj1-0;
+ samsung,pin-function = 1;
+ samsung,pin-val = 0;
+ };
+
+ camera_flash_isp: camera-flash-isp {
+ samsung,pins = gpj1-0;
+ samsung,pin-function = 1;
+ samsung,pin-val = 1;
+ };
+};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] v4l: async: Add a pointer to of_node to struct v4l2_subdev, match it
On 05/20/2015 01:04 AM, Sakari Ailus wrote:
V4L2 async sub-devices are currently matched (OF case) based on the struct
device_node pointer in struct device. LED devices may have more than one
LED, and in that case the OF node to match is not directly the device's
node, but a LED's node.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/v4l2-core/v4l2-async.c | 34 +
drivers/media/v4l2-core/v4l2-device.c |3 +++
include/media/v4l2-subdev.h |2 ++
3 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c
index 85a6a34..bcdd140 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -22,10 +22,10 @@
#include media/v4l2-device.h
#include media/v4l2-subdev.h
-static bool match_i2c(struct device *dev, struct v4l2_async_subdev *asd)
+static bool match_i2c(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
#if IS_ENABLED(CONFIG_I2C)
- struct i2c_client *client = i2c_verify_client(dev);
+ struct i2c_client *client = i2c_verify_client(sd-dev);
return client
asd-match.i2c.adapter_id == client-adapter-nr
asd-match.i2c.address == client-addr;
@@ -34,14 +34,27 @@ static bool match_i2c(struct device *dev, struct
v4l2_async_subdev *asd)
#endif
}
-static bool match_devname(struct device *dev, struct v4l2_async_subdev *asd)
+static bool match_devname(struct v4l2_subdev *sd,
+ struct v4l2_async_subdev *asd)
{
- return !strcmp(asd-match.device_name.name, dev_name(dev));
+ return !strcmp(asd-match.device_name.name, dev_name(sd-dev));
}
-static bool match_of(struct device *dev, struct v4l2_async_subdev *asd)
+static bool match_of(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
- return dev-of_node == asd-match.of.node;
+ struct device_node *of_node =
+ sd-of_node ? sd-of_node : sd-dev-of_node;
+
+ return of_node == asd-match.of.node;
+}
+
+static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
+{
+ if (!asd-match.custom.match)
+ /* Match always */
+ return true;
+
+ return asd-match.custom.match(sd-dev, asd);
}
static LIST_HEAD(subdev_list);
@@ -51,17 +64,14 @@ static DEFINE_MUTEX(list_lock);
static struct v4l2_async_subdev *v4l2_async_belongs(struct
v4l2_async_notifier *notifier,
struct v4l2_subdev *sd)
{
+ bool (*match)(struct v4l2_subdev *, struct v4l2_async_subdev *);
struct v4l2_async_subdev *asd;
- bool (*match)(struct device *, struct v4l2_async_subdev *);
list_for_each_entry(asd, notifier-waiting, list) {
/* bus_type has been verified valid before */
switch (asd-match_type) {
case V4L2_ASYNC_MATCH_CUSTOM:
- match = asd-match.custom.match;
- if (!match)
- /* Match always */
- return asd;
+ match = match_custom;
break;
case V4L2_ASYNC_MATCH_DEVNAME:
match = match_devname;
@@ -79,7 +89,7 @@ static struct v4l2_async_subdev *v4l2_async_belongs(struct
v4l2_async_notifier *
}
/* match cannot be NULL here */
- if (match(sd-dev, asd))
+ if (match(sd, asd))
return asd;
}
diff --git a/drivers/media/v4l2-core/v4l2-device.c
b/drivers/media/v4l2-core/v4l2-device.c
index 5b0a30b..a741c6c 100644
--- a/drivers/media/v4l2-core/v4l2-device.c
+++ b/drivers/media/v4l2-core/v4l2-device.c
@@ -157,6 +157,9 @@ int v4l2_device_register_subdev(struct v4l2_device
*v4l2_dev,
/* Warn if we apparently re-register a subdev */
WARN_ON(sd-v4l2_dev != NULL);
+ if (!sd-of_node sd-dev)
+ sd-of_node = sd-dev-of_node;
+
/*
* The reason to acquire the module here is to avoid unloading
* a module of sub-device which is registered to a media
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 8f5da73..5c51987 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -603,6 +603,8 @@ struct v4l2_subdev {
struct video_device *devnode;
/* pointer to the physical device, if any */
struct device *dev;
+ /* A device_node of the sub-device, iff not dev-of_node. */
+ struct device_node *of_node;
/* Links this subdev to a global subdev_list or @notifier-done list. */
struct list_head async_list;
/* Pointer to respective struct v4l2_async_subdev. */
I've tested it with V4L2_ASYNC_MATCH_OF matching
Re: [Y2038] [PATCH v2] [media] dvb-frontend: Replace timeval with ktime_t
On Tuesday 19 May 2015 13:52:10 Tina Ruchandani wrote: struct timeval uses a 32-bit seconds representation which will overflow in the year 2038 and beyond. This patch replaces the usage of struct timeval with ktime_t which is a 64-bit timestamp and is year 2038 safe. This patch is part of a larger attempt to remove all instances of 32-bit timekeeping variables (timeval, timespec, time_t) which are not year 2038 safe, from the kernel. Ok. The patch is a work-in-progress - correctness of the following changes is unclear: (a) Usage of timeval_usec_diff - The function seems to subtract usec values without caring about the difference of the seconds field. There may be an implicit assumption in the original code that the time delta is always of the order of microseconds. The patch replaces the usage of timeval_usec_diff with ktime_to_us(ktime_sub()) which computes the real timestamp difference, not just the difference in the usec field. Yes, I'm sure this is a safe assumption. When you change the code to ktime_us_delta, please also update the comment here. (b) printk diffing the tv[i] and tv[i-1] values. The original printk statement seems to get the order wrong. This patch preserves that order. I also think that's ok, but it would be nice to split this out as a separate patch that gets applied first, so just swap out the arguments in the timeval_usec_diff() definition as preparation and add an explanation why you think it was wrong. @@ -2489,7 +2469,7 @@ static int dvb_frontend_ioctl_legacy(struct file *file, printk(%s(%d): switch delay (should be 32k followed by all 8k\n, __func__, fe-dvb-num); for (i = 1; i 10; i++) - printk(%d: %d\n, i, timeval_usec_diff(tv[i-1] , tv[i])); + printk(%d: %d\n, i, (int) ktime_to_us(ktime_sub(tv[i-1], tv[i]))); This can still be simplified using ktime_us_delta(). stv0299_writeregI (state, 0x0c, reg0x0c | (last ? lv_mask : 0x50)); @@ -443,7 +444,7 @@ static int stv0299_send_legacy_dish_cmd (struct dvb_frontend* fe, unsigned long printk (%s(%d): switch delay (should be 32k followed by all 8k\n, __func__, fe-dvb-num); for (i = 1; i 10; i++) - printk (%d: %d\n, i, timeval_usec_diff(tv[i-1] , tv[i])); + printk(%d: %d\n, i, (int) ktime_to_us(ktime_sub(tv[i-1], tv[i]))); } This, too. The patch looks correct to me now, so just do the cosmetic changes I suggested above and submit a version 3. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 5/8] exynos4-is: Add support for v4l2-flash subdevs
This patch adds support for external v4l2-flash devices.
The support includes parsing samsung,flash-led DT property
and asynchronous subdevice registration.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
---
drivers/media/platform/exynos4-is/media-dev.c | 39 +++--
drivers/media/platform/exynos4-is/media-dev.h | 13 -
2 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/media-dev.c
b/drivers/media/platform/exynos4-is/media-dev.c
index f315ef9..80cecd8 100644
--- a/drivers/media/platform/exynos4-is/media-dev.c
+++ b/drivers/media/platform/exynos4-is/media-dev.c
@@ -451,6 +451,28 @@ rpm_put:
return ret;
}
+static void fimc_md_register_flash_entities(struct fimc_md *fmd)
+{
+ int i;
+
+ fmd-num_flashes = 0;
+
+ for (i = 0; i fmd-num_sensors; i++) {
+ const struct device_node *np =
+ fmd-sensor[i].asd.match.of.node;
+ const int nf = fmd-num_flashes;
+
+ np = of_parse_phandle(np, samsung,flash-led, 0);
+ if (!np)
+ continue;
+
+ fmd-flash[nf].asd.match_type = V4L2_ASYNC_MATCH_OF;
+ fmd-flash[nf].asd.match.of.node = np;
+ fmd-async_subdevs[fmd-num_sensors + nf] = fmd-flash[nf].asd;
+ fmd-num_flashes++;
+ }
+}
+
static int __of_get_csis_id(struct device_node *np)
{
u32 reg = 0;
@@ -1275,6 +1297,15 @@ static int subdev_notifier_bound(struct
v4l2_async_notifier *notifier,
struct fimc_sensor_info *si = NULL;
int i;
+ /* Register flash subdev if detected any */
+ for (i = 0; i ARRAY_SIZE(fmd-flash); i++) {
+ if (fmd-flash[i].asd.match.of.node == subdev-of_node) {
+ fmd-flash[i].subdev = subdev;
+ fmd-num_flashes++;
+ return 0;
+ }
+ }
+
/* Find platform data for this sensor subdev */
for (i = 0; i ARRAY_SIZE(fmd-sensor); i++)
if (fmd-sensor[i].asd.match.of.node == subdev-dev-of_node)
@@ -1385,6 +1416,8 @@ static int fimc_md_probe(struct platform_device *pdev)
goto err_m_ent;
}
+ fimc_md_register_flash_entities(fmd);
+
mutex_unlock(fmd-media_dev.graph_mutex);
ret = device_create_file(pdev-dev, dev_attr_subdev_conf_mode);
@@ -1401,12 +1434,14 @@ static int fimc_md_probe(struct platform_device *pdev)
goto err_attr;
}
- if (fmd-num_sensors 0) {
+ if (fmd-num_sensors 0 || fmd-num_flashes 0) {
fmd-subdev_notifier.subdevs = fmd-async_subdevs;
- fmd-subdev_notifier.num_subdevs = fmd-num_sensors;
+ fmd-subdev_notifier.num_subdevs = fmd-num_sensors +
+ fmd-num_flashes;
fmd-subdev_notifier.bound = subdev_notifier_bound;
fmd-subdev_notifier.complete = subdev_notifier_complete;
fmd-num_sensors = 0;
+ fmd-num_flashes = 0;
ret = v4l2_async_notifier_register(fmd-v4l2_dev,
fmd-subdev_notifier);
diff --git a/drivers/media/platform/exynos4-is/media-dev.h
b/drivers/media/platform/exynos4-is/media-dev.h
index 0321454..d4eed34 100644
--- a/drivers/media/platform/exynos4-is/media-dev.h
+++ b/drivers/media/platform/exynos4-is/media-dev.h
@@ -34,6 +34,8 @@
#define FIMC_MAX_SENSORS 4
#define FIMC_MAX_CAMCLKS 2
+#define FIMC_MAX_FLASHES 4
+#define FIMC_MAX_ASYNC_SUBDEVS (FIMC_MAX_SENSORS + FIMC_MAX_FLASHES)
#define DEFAULT_SENSOR_CLK_FREQ2400U
/* LCD/ISP Writeback clocks (PIXELASYNCMx) */
@@ -93,6 +95,11 @@ struct fimc_sensor_info {
struct fimc_dev *host;
};
+struct fimc_flash_info {
+ struct v4l2_subdev *subdev;
+ struct v4l2_async_subdev asd;
+};
+
struct cam_clk {
struct clk_hw hw;
struct fimc_md *fmd;
@@ -104,6 +111,8 @@ struct cam_clk {
* @csis: MIPI CSIS subdevs data
* @sensor: array of registered sensor subdevs
* @num_sensors: actual number of registered sensors
+ * @flash: array of registered flash subdevs
+ * @num_flashes: actual number of registered flashes
* @camclk: external sensor clock information
* @fimc: array of registered fimc devices
* @fimc_is: fimc-is data structure
@@ -123,6 +132,8 @@ struct fimc_md {
struct fimc_csis_info csis[CSIS_MAX_ENTITIES];
struct fimc_sensor_info sensor[FIMC_MAX_SENSORS];
int num_sensors;
+ struct fimc_flash_info flash[FIMC_MAX_FLASHES];
+ int num_flashes;
struct fimc_camclk_info camclk[FIMC_MAX_CAMCLKS];
struct clk *wbclk[FIMC_MAX_WBCLKS];
struct fimc_lite
[PATCH v8 6/8] DT: s5c73m3: Add documentation for samsung,flash-led property
This patch adds a description of 'samsung,flash-led' property
to the samsung-s5c73m3.txt.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/media/samsung-s5c73m3.txt |5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
b/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
index 2c85c45..8a413c0 100644
--- a/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
+++ b/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
@@ -32,6 +32,10 @@ Optional properties:
- clock-frequency : the frequency at which the cis_extclk clock should be
configured to operate, in Hz; if this property is not
specified default 24 MHz value will be used.
+- samsung,flash-led : phandle to the flash LED associated with this sensor.
+ Flash LED is represented by the child node of a flash LED
+ device
+ (see Documentation/devicetree/bindings/leds/common.txt).
The common video interfaces bindings (see video-interfaces.txt) should be used
to specify link from the S5C73M3 to an external image data receiver. The
S5C73M3
@@ -78,6 +82,7 @@ i2c@138A00 {
clock-names = cis_extclk;
reset-gpios = gpf1 3 1;
standby-gpios = gpm0 1 1;
+ samsung,flash-led = camera1_flash;
port {
s5c73m3_ep: endpoint {
remote-endpoint = csis0_ep;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 8/8] DT: samsung-fimc: Add examples for samsung,flash-led property
This patch adds examples for samsung,flash-led property to the
samsung-fimc.txt.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/media/samsung-fimc.txt |4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/samsung-fimc.txt
index 922d6f8..57edffa 100644
--- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
@@ -126,6 +126,8 @@ Example:
clocks = camera 1;
clock-names = mclk;
+ samsung,flash-led = front_cam_flash;
+
port {
s5k6aa_ep: endpoint {
remote-endpoint = fimc0_ep;
@@ -147,6 +149,8 @@ Example:
clocks = camera 0;
clock-names = mclk;
+ samsung,flash-led = rear_cam_flash;
+
port {
s5c73m3_1: endpoint {
data-lanes = 1 2 3 4;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 7/8] DT: s5k6a3: Add documentation for samsung,flash-led property
This patch adds a description of 'samsung,flash-led' property to the samsung-s5k6a3.txt. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: devicet...@vger.kernel.org --- .../devicetree/bindings/media/samsung-s5k6a3.txt |4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt b/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt index cce01e8..25f2e82 100644 --- a/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt +++ b/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt @@ -22,6 +22,10 @@ Optional properties: - clock-frequency : the frequency at which the extclk clock should be configured to operate, in Hz; if this property is not specified default 24 MHz value will be used. +- samsung,flash-led : phandle to the flash LED associated with this sensor. + Flash LED is represented by the child node of a flash LED + device + (see Documentation/devicetree/bindings/leds/common.txt). The common video interfaces bindings (see video-interfaces.txt) should be used to specify link to the image data receiver. The S5K6A3(YX) device -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] e4000: Fix rangehigh value
As reported by smatch:
drivers/media/tuners/e4000.c:287:32: warning: constant 220800 is so big it
is long long
drivers/media/tuners/e4000.c:287:32: warning: decimal constant 220800 is
between LONG_MAX and ULONG_MAX. For C99 that means long long, C90 compilers are
very likely to produce unsigned long (and a warning) here
drivers/media/tuners/e4000.c:287:3: warning: this decimal constant is unsigned
only in ISO C90
.rangehigh = 220800,
^
Cc: Antti Palosaari cr...@iki.fi
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
index 3b49a4550bd3..fdf07ce4177a 100644
--- a/drivers/media/tuners/e4000.c
+++ b/drivers/media/tuners/e4000.c
@@ -284,7 +284,7 @@ static const struct v4l2_frequency_band bands[] = {
.index = 1,
.capability = V4L2_TUNER_CAP_1HZ | V4L2_TUNER_CAP_FREQ_BANDS,
.rangelow = 124900,
- .rangehigh = 220800,
+ .rangehigh = 220800L,
},
};
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/7] rc: rc-ir-raw: Add scancode encoder callback
On 19 May 2015 at 23:38, David Härdeman da...@hardeman.nu wrote:
On Tue, Mar 31, 2015 at 08:48:06PM +0300, Antti Seppälä wrote:
From: James Hogan ja...@albanarts.com
Add a callback to raw ir handlers for encoding and modulating a scancode
to a set of raw events. This could be used for transmit, or for
converting a wakeup scancode filter to a form that is more suitable for
raw hardware wake up filters.
Signed-off-by: James Hogan ja...@albanarts.com
Signed-off-by: Antti Seppälä a.sepp...@gmail.com
Cc: David Härdeman da...@hardeman.nu
---
Notes:
Changes in v3:
- Ported to apply against latest media-tree
Changes in v2:
- Alter encode API to return -ENOBUFS when there isn't enough buffer
space. When this occurs all buffer contents must have been written
with the partial encoding of the scancode. This is to allow drivers
such as nuvoton-cir to provide a shorter buffer and still get a
useful partial encoding for the wakeup pattern.
drivers/media/rc/rc-core-priv.h | 2 ++
drivers/media/rc/rc-ir-raw.c| 37 +
include/media/rc-core.h | 3 +++
3 files changed, 42 insertions(+)
diff --git a/drivers/media/rc/rc-core-priv.h b/drivers/media/rc/rc-core-priv.h
index b68d4f76..122c25f 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -25,6 +25,8 @@ struct ir_raw_handler {
u64 protocols; /* which are handled by this handler */
int (*decode)(struct rc_dev *dev, struct ir_raw_event event);
+ int (*encode)(u64 protocols, const struct rc_scancode_filter *scancode,
+struct ir_raw_event *events, unsigned int max);
/* These two should only be used by the lirc decoder */
int (*raw_register)(struct rc_dev *dev);
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index b732ac6..dd47fe5 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -246,6 +246,43 @@ static int change_protocol(struct rc_dev *dev, u64
*rc_type)
return 0;
}
+/**
+ * ir_raw_encode_scancode() - Encode a scancode as raw events
+ *
+ * @protocols:permitted protocols
+ * @scancode: scancode filter describing a single scancode
+ * @events: array of raw events to write into
+ * @max: max number of raw events
+ *
+ * Attempts to encode the scancode as raw events.
+ *
+ * Returns: The number of events written.
+ *-ENOBUFS if there isn't enough space in the array to fit the
+ *encoding. In this case all @max events will have been written.
+ *-EINVAL if the scancode is ambiguous or invalid, or if no
+ *compatible encoder was found.
+ */
+int ir_raw_encode_scancode(u64 protocols,
Why a bitmask of protocols and not a single protocol enum? What's the
use case for encoding a given scancode according to one out of a number
of protocols (and not even knowing which one)??
I think bitmask was used simply for consistency reasons. Most of the
rc-core handles protocols in a bitmask (u64 protocols or some variant
of it). Especially in the decoders the dev-enabled_protocols is used
to mean decode any of these protocols but I don't care which one and
the encoders were written to follow that logic.
From ir driver point of view it was also kind of nice to use the u64
enabled_wakeup_protocols from struct rc_dev which already exists and
is manipulated with the same sysfs code as the enabled_protocols
bitmask.
--
Antti
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 4/6] [media] rc: lirc is not a protocol or a keymap
On Wed, May 20, 2015 at 11:06:06AM +0200, David Härdeman wrote: On 2015-05-20 11:01, Mauro Carvalho Chehab wrote: Em Wed, 20 May 2015 10:49:34 +0200 David Härdeman da...@hardeman.nu escreveu: On 2015-05-20 10:19, Mauro Carvalho Chehab wrote: Em Tue, 19 May 2015 22:34:42 +0200 David Härdeman da...@hardeman.nu escreveu: I think we should be able to at least not break userspace by still accepting (and ignoring) commands to enable/disable lirc. Well, ignoring is not a good idea, as it still breaks userspace, but on a more evil way. If one is using this feature, we'll be receiving bug reports and fixes for it. I disagree it's more evil (or at least I fail to see how it would be). Because the Kernel would be lying to userspace. If one tells the Kernel to disable something, it should do it, or otherwise return an error explaining why disabling was not possible. Would really you be happier with a patch so that writing -lirc to the sysfs file returns an error? Actually that would be very weird in case userspace writes e.g. rc5 to the sysfs file (since that implies disabling lirc which would then return an error as well). So, that won't work. I still think just ignoring +lirc and -lirc is the best solution...(and the usecase you suggested of disabling lirc so that lircd won't get any events while an app reads only decoded events...seems very far-fetched)...do you have any other suggestion? -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/7] rc: rc-ir-raw: Add scancode encoder callback
On Wed, May 20, 2015 at 10:26:54PM +0300, Antti Seppälä wrote:
On 20 May 2015 at 21:29, David Härdeman da...@hardeman.nu wrote:
On Wed, May 20, 2015 at 07:46:21PM +0300, Antti Seppälä wrote:
On 19 May 2015 at 23:38, David Härdeman da...@hardeman.nu wrote:
On Tue, Mar 31, 2015 at 08:48:06PM +0300, Antti Seppälä wrote:
From: James Hogan ja...@albanarts.com
Add a callback to raw ir handlers for encoding and modulating a scancode
to a set of raw events. This could be used for transmit, or for
converting a wakeup scancode filter to a form that is more suitable for
raw hardware wake up filters.
Signed-off-by: James Hogan ja...@albanarts.com
Signed-off-by: Antti Seppälä a.sepp...@gmail.com
Cc: David Härdeman da...@hardeman.nu
---
Notes:
Changes in v3:
- Ported to apply against latest media-tree
Changes in v2:
- Alter encode API to return -ENOBUFS when there isn't enough buffer
space. When this occurs all buffer contents must have been written
with the partial encoding of the scancode. This is to allow drivers
such as nuvoton-cir to provide a shorter buffer and still get a
useful partial encoding for the wakeup pattern.
drivers/media/rc/rc-core-priv.h | 2 ++
drivers/media/rc/rc-ir-raw.c| 37 +
include/media/rc-core.h | 3 +++
3 files changed, 42 insertions(+)
diff --git a/drivers/media/rc/rc-core-priv.h
b/drivers/media/rc/rc-core-priv.h
index b68d4f76..122c25f 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -25,6 +25,8 @@ struct ir_raw_handler {
u64 protocols; /* which are handled by this handler */
int (*decode)(struct rc_dev *dev, struct ir_raw_event event);
+ int (*encode)(u64 protocols, const struct rc_scancode_filter
*scancode,
+struct ir_raw_event *events, unsigned int max);
/* These two should only be used by the lirc decoder */
int (*raw_register)(struct rc_dev *dev);
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index b732ac6..dd47fe5 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -246,6 +246,43 @@ static int change_protocol(struct rc_dev *dev, u64
*rc_type)
return 0;
}
+/**
+ * ir_raw_encode_scancode() - Encode a scancode as raw events
+ *
+ * @protocols:permitted protocols
+ * @scancode: scancode filter describing a single scancode
+ * @events: array of raw events to write into
+ * @max: max number of raw events
+ *
+ * Attempts to encode the scancode as raw events.
+ *
+ * Returns: The number of events written.
+ *-ENOBUFS if there isn't enough space in the array to fit the
+ *encoding. In this case all @max events will have been
written.
+ *-EINVAL if the scancode is ambiguous or invalid, or if no
+ *compatible encoder was found.
+ */
+int ir_raw_encode_scancode(u64 protocols,
Why a bitmask of protocols and not a single protocol enum? What's the
use case for encoding a given scancode according to one out of a number
of protocols (and not even knowing which one)??
I think bitmask was used simply for consistency reasons. Most of the
rc-core handles protocols in a bitmask (u64 protocols or some variant
of it).
Yes, all the parts where multiple protocols make sense use a bitmap of
protocols. If there's any part which uses a bitmap where only one
protocol makes sense that'd be a bug...
Especially in the decoders the dev-enabled_protocols is used
to mean decode any of these protocols but I don't care which one and
the encoders were written to follow that logic.
The fact that you might want to be able to receive and decode more than
one protocol has no bearing on encoding when you're supposed to know
what it is you want to encode
From ir driver point of view it was also kind of nice to use the u64
enabled_wakeup_protocols from struct rc_dev which already exists and
is manipulated with the same sysfs code as the enabled_protocols
bitmask.
But it makes no sense? here's a scancode...I have no idea what it means
since only knowing the protocol allows you to make any sense of the
scancode...but please encode it to something...anything
Well it made sense from code simplicity point of view :)
But yes current use cases will most likely be valid when encoding only
to a single specific protocol at a time. However having a flexible api
allows for future expansion though if a new use case is needed to be
supported. And like I said earlier using bitmask is also consistent
with what rc-core already has.
* drivers/media/rc/img-ir/img-ir-hw.c
only seems to support one protocol at a time
* drivers/media/rc/rc-loopback.c
doesn't care
* drivers/media/rc/winbond-cir.c
seems hardware-wise very similar to nuvoton-cir.c, was not converted to
use the in-kernel encoders...has a private implementation
* drivers/media/rc/nuvoton-cir.c
Re: [RFC PATCH 4/6] [media] rc: lirc is not a protocol or a keymap
On Wed, May 20, 2015 at 09:16:32PM +0200, David Härdeman wrote: On Wed, May 20, 2015 at 11:06:06AM +0200, David Härdeman wrote: On 2015-05-20 11:01, Mauro Carvalho Chehab wrote: Em Wed, 20 May 2015 10:49:34 +0200 David Härdeman da...@hardeman.nu escreveu: On 2015-05-20 10:19, Mauro Carvalho Chehab wrote: Em Tue, 19 May 2015 22:34:42 +0200 David Härdeman da...@hardeman.nu escreveu: I think we should be able to at least not break userspace by still accepting (and ignoring) commands to enable/disable lirc. Well, ignoring is not a good idea, as it still breaks userspace, but on a more evil way. If one is using this feature, we'll be receiving bug reports and fixes for it. I disagree it's more evil (or at least I fail to see how it would be). Because the Kernel would be lying to userspace. If one tells the Kernel to disable something, it should do it, or otherwise return an error explaining why disabling was not possible. Would really you be happier with a patch so that writing -lirc to the sysfs file returns an error? Actually that would be very weird in case userspace writes e.g. rc5 to the sysfs file (since that implies disabling lirc which would then return an error as well). So, that won't work. I still think just ignoring +lirc and -lirc is the best solution...(and the usecase you suggested of disabling lirc so that lircd won't get any events while an app reads only decoded events...seems very far-fetched)...do you have any other suggestion? I've done some more checking. Not changing protocols even though user-space asked for it is actually already part of the rc-core API. struct rc_dev contains: int (*change_protocol)(struct rc_dev *dev, u64 *rc_type); The reason rc_type is a pointer is that it is used to pass the requested protocols to the change_protocol function and the function can then update it to reflect what the actual result was. Examples: drivers/media/usb/em28xx/em28xx-input.c drivers/media/rc/img-ir/img-ir-hw.c Both of these drivers will pick *one* protocol to enable...so if you'd write +rc5 +nec to their sysfs protocols file, it'd just enable one protocol (and the file would read e.g. [rc5] nec afterwards). With that in mind, userspace could never expect the list of enabled protocols to match what it just wrote, even if no error was returned. -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/20] media: soc_camera pad-aware driver initialisation
Hello.
On 05/20/2015 07:39 PM, William Towle wrote:
Add detection of source pad number for drivers aware of the media
controller API, so that soc_camera/rcar_vin can create device nodes
to support a driver such as adv7604.c (for HDMI on Lager) underneath.
Signed-off-by: William Towle william.to...@codethink.co.uk
Reviewed-by: Rob Taylor rob.tay...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c |4
drivers/media/platform/soc_camera/soc_camera.c | 27 +++-
include/media/soc_camera.h |1 +
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 0f67646..b4e9b43 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
[...]
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index d708df4..126d645 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
[...]
@@ -1311,7 +1312,25 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
}
/* At this point client .probe() should have run already */
- ret = soc_camera_init_user_formats(icd);
+ ret = media_entity_init(icd-vdev-entity, 1, icd-pad, 0);
+ if (!ret) {
+ for (src_pad_idx = 0; src_pad_idx sd-entity.num_pads;
+ src_pad_idx++)
+ if (sd-entity.pads[src_pad_idx].flags
+ == MEDIA_PAD_FL_SOURCE)
+ break;
+
+ if (src_pad_idx sd-entity.num_pads) {
+ if (!media_entity_create_link(
+ icd-vdev-entity, 0,
+ sd-entity, src_pad_idx,
+ MEDIA_LNK_FL_IMMUTABLE |
+ MEDIA_LNK_FL_ENABLED)) {
Please either start the continuation lines under ! on the first line or
indent them more to the right, so that's easier on the eyes.
+ ret = soc_camera_init_user_formats(icd);
+ }
+ }
+ }
+
if (ret 0)
goto eusrfmt;
@@ -1322,6 +1341,7 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
goto evidstart;
/* Try to improve our guess of a reasonable window format */
+ fmt.pad = src_pad_idx;
if (!v4l2_subdev_call(sd, pad, get_fmt, NULL, fmt)) {
icd-user_width = mf-width;
icd-user_height = mf-height;
@@ -1335,6 +1355,7 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
evidstart:
soc_camera_free_user_formats(icd);
eusrfmt:
+ media_entity_cleanup(icd-vdev-entity);
soc_camera_remove_device(icd);
return ret;
@@ -1856,6 +1877,10 @@ static int soc_camera_remove(struct soc_camera_device
*icd)
if (icd-num_user_formats)
soc_camera_free_user_formats(icd);
+ if (icd-vdev-entity.num_pads) {
+ media_entity_cleanup(icd-vdev-entity);
+ }
+
Brackets not needed here, and checkpatch.pl should have complained about
that.
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dma-buf: Minor coding style fixes
- WARNING: Missing a blank line after declarations
- WARNING: line over 80 characters
- WARNING: please, no space before tabs
Signed-off-by: Jagan Teki jt...@openedev.com
Cc: Sumit Semwal sumit.sem...@linaro.org
---
drivers/dma-buf/dma-buf.c | 9 +++--
drivers/dma-buf/reservation.c | 9 ++---
drivers/dma-buf/seqno-fence.c | 8 +++-
3 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index c5a9138..30a099c 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -285,6 +285,7 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
struct reservation_object *resv = exp_info-resv;
struct file *file;
size_t alloc_size = sizeof(struct dma_buf);
+
if (!exp_info-resv)
alloc_size += sizeof(struct reservation_object);
else
@@ -545,7 +546,8 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t
start, size_t len,
return -EINVAL;
if (dmabuf-ops-begin_cpu_access)
- ret = dmabuf-ops-begin_cpu_access(dmabuf, start, len,
direction);
+ ret = dmabuf-ops-begin_cpu_access(dmabuf, start,
+ len, direction);
return ret;
}
@@ -649,7 +651,7 @@ EXPORT_SYMBOL_GPL(dma_buf_kunmap);
* @dmabuf:[in]buffer that should back the vma
* @vma: [in]vma for the mmap
* @pgoff: [in]offset in pages where this mmap should start within the
- * dma-buf buffer.
+ * dma-buf buffer.
*
* This function adjusts the passed in vma so that it points at the file of the
* dma_buf operation. It also adjusts the starting pgoff and does bounds
@@ -826,6 +828,7 @@ static int dma_buf_describe(struct seq_file *s)
static int dma_buf_show(struct seq_file *s, void *unused)
{
void (*func)(struct seq_file *) = s-private;
+
func(s);
return 0;
}
@@ -847,7 +850,9 @@ static struct dentry *dma_buf_debugfs_dir;
static int dma_buf_init_debugfs(void)
{
int err = 0;
+
dma_buf_debugfs_dir = debugfs_create_dir(dma_buf, NULL);
+
if (IS_ERR(dma_buf_debugfs_dir)) {
err = PTR_ERR(dma_buf_debugfs_dir);
dma_buf_debugfs_dir = NULL;
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 39920d7..c0bd572 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -337,7 +337,8 @@ retry:
rcu_read_lock();
if (wait_all) {
- struct reservation_object_list *fobj =
rcu_dereference(obj-fence);
+ struct reservation_object_list *fobj =
+ rcu_dereference(obj-fence);
if (fobj)
shared_count = fobj-shared_count;
@@ -429,7 +430,8 @@ retry:
if (test_all) {
unsigned i;
- struct reservation_object_list *fobj =
rcu_dereference(obj-fence);
+ struct reservation_object_list *fobj =
+ rcu_dereference(obj-fence);
if (fobj)
shared_count = fobj-shared_count;
@@ -462,7 +464,8 @@ retry:
goto unlock_retry;
if (fence_excl) {
- ret =
reservation_object_test_signaled_single(fence_excl);
+ ret = reservation_object_test_signaled_single(
+ fence_excl);
if (ret 0)
goto unlock_retry;
}
diff --git a/drivers/dma-buf/seqno-fence.c b/drivers/dma-buf/seqno-fence.c
index 7d12a39..71127f8 100644
--- a/drivers/dma-buf/seqno-fence.c
+++ b/drivers/dma-buf/seqno-fence.c
@@ -24,24 +24,28 @@
static const char *seqno_fence_get_driver_name(struct fence *fence)
{
struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+
return seqno_fence-ops-get_driver_name(fence);
}
static const char *seqno_fence_get_timeline_name(struct fence *fence)
{
struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+
return seqno_fence-ops-get_timeline_name(fence);
}
static bool seqno_enable_signaling(struct fence *fence)
{
struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+
return seqno_fence-ops-enable_signaling(fence);
}
static bool seqno_signaled(struct fence *fence)
{
struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+
return seqno_fence-ops-signaled seqno_fence-ops-signaled(fence);
}
@@ -56,9 +60,11 @@ static void seqno_release(struct fence *fence)
fence_free(f-base);
}
-static signed long seqno_wait(struct fence *fence, bool intr, signed long
timeout)
+static signed long seqno_wait(struct fence *fence, bool intr,
+
Re: [PATCH v8 2/8] leds: max77693: add support for V4L2 Flash sub-device
On Wed, May 20, 2015 at 04:10:09PM +0200, Jacek Anaszewski wrote: Add support for V4L2 Flash sub-device to the max77693 LED Flash class driver. The support allows for V4L2 Flash sub-device to take the control of the LED Flash class device. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Sakari Ailus sakari.ai...@iki.fi Acked-by: Sakari Ailus sakari.ai...@linux.intel.com -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] rc-core: use the full 32 bits for NEC scancodes
On Thu, May 14, 2015 at 05:57:39PM -0300, Mauro Carvalho Chehab wrote:
Em Mon, 06 Apr 2015 13:23:08 +0200
David Härdeman da...@hardeman.nu escreveu:
Using the full 32 bits for all kinds of NEC scancodes simplifies rc-core
and the nec decoder without any loss of functionality. At the same time
it ensures that scancodes for NEC16/NEC24/NEC32 do not overlap and
removes any ambiguity.
For example, before this patch, consider these two NEC messages:
NEC16 message to address 0x05, command 0x03
NEC24 message to address 0x0005, command 0x03
They'll both have scancode 0x0503, and there's no way to tell which
message was received.
In order to maintain backwards compatibility, some heuristics are added
in rc-main.c to convert scancodes to NEC32 as necessary when userspace
adds entries to the keytable using the regular input ioctls.
No conversion will be made for the newer rc_keymap_entry based ioctls
(see the next patch).
Signed-off-by: David Härdeman da...@hardeman.nu
Checkpatch has something to say about this patch:
WARNING: else is not generally useful after a break or return
#140: FILE: drivers/media/rc/rc-main.c:357:
+ return b3 24 | b2 16 | b1 8 | ((u8)~b1);
+ else
That seems like a bogus warning?...the return line is after an else if...
WARNING: line over 80 characters
#259: FILE: drivers/media/usb/dvb-usb-v2/af9035.c:1778:
+ RC_SCANCODE_NEC32(b[0] 24 | b[1] 16 | b[2] 8 |
b[3]),
That file isn't 80 chars per line clean anyway (and 80 char lines do
not seem to be a hard rule?). Anyway, I've changed it in my local
version...
ERROR: space prohibited after that open parenthesis '('
#479: FILE: include/media/rc-map.h:79:
+ ((( (addr) 0xff) 24) | \
ERROR: space prohibited after that open parenthesis '('
#481: FILE: include/media/rc-map.h:81:
+ (( (cmd) 0xff) 8 ) | \
ERROR: space prohibited before that close parenthesis ')'
#481: FILE: include/media/rc-map.h:81:
+ (( (cmd) 0xff) 8 ) | \
ERROR: space prohibited before that close parenthesis ')'
#482: FILE: include/media/rc-map.h:82:
+ ((~(cmd) 0xff) 0 ))
ERROR: space prohibited after that open parenthesis '('
#484: FILE: include/media/rc-map.h:84:
+ ((( (addr) 0x) 16) | \
ERROR: space prohibited after that open parenthesis '('
#485: FILE: include/media/rc-map.h:85:
+ (( (cmd) 0x00ff) 8) | \
I don't think fixing any of these help readability, but I've changed
them in my local version.
---
drivers/media/rc/ir-nec-decoder.c| 26 ++
drivers/media/rc/rc-main.c | 54
+-
drivers/media/usb/dvb-usb-v2/af9015.c| 22 ++--
drivers/media/usb/dvb-usb-v2/af9035.c| 25 +++---
drivers/media/usb/dvb-usb-v2/az6007.c| 16 ++---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 20 +++
drivers/media/usb/dvb-usb/dib0700_core.c | 24 +++--
drivers/media/usb/em28xx/em28xx-input.c | 37 +
include/media/rc-map.h | 16 +++--
9 files changed, 102 insertions(+), 138 deletions(-)
diff --git a/drivers/media/rc/ir-nec-decoder.c
b/drivers/media/rc/ir-nec-decoder.c
index 7b81fec..16907c1 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -50,7 +50,6 @@ static int ir_nec_decode(struct rc_dev *dev, struct
ir_raw_event ev)
struct nec_dec *data = dev-raw-nec;
u32 scancode;
u8 address, not_address, command, not_command;
-bool send_32bits = false;
if (!(dev-enabled_protocols RC_BIT_NEC))
return 0;
@@ -163,28 +162,9 @@ static int ir_nec_decode(struct rc_dev *dev, struct
ir_raw_event ev)
command = bitrev8((data-bits 8) 0xff);
not_command = bitrev8((data-bits 0) 0xff);
-if ((command ^ not_command) != 0xff) {
-IR_dprintk(1, NEC checksum error: received 0x%08x\n,
- data-bits);
-send_32bits = true;
-}
-
-if (send_32bits) {
-/* NEC transport, but modified protocol, used by at
- * least Apple and TiVo remotes */
-scancode = data-bits;
-IR_dprintk(1, NEC (modified) scancode 0x%08x\n,
scancode);
-} else if ((address ^ not_address) != 0xff) {
-/* Extended NEC */
-scancode = address 16 |
- not_address 8 |
- command;
-IR_dprintk(1, NEC (Ext) scancode 0x%06x\n, scancode);
-} else {
-/* Normal NEC */
-scancode = address 8 | command;
-IR_dprintk(1, NEC scancode 0x%04x\n, scancode);
-}
+scancode = RC_SCANCODE_NEC32(address 24 |
Re: imx53 IPU support on 4.0.4
On Wed, May 20, 2015 at 03:05:41PM +0200, Enrico Weigelt, metux IT consult wrote: I've rebased the IPUv3 patches from ptx folks onto 4.0.4, working good for me. (now gst plays h264 @25fps on imx53) https://github.com/metux/linux/commits/submit-4.0-imx53-ipuv3 (Haven't 4.1rc* yet, as it broke some other things for me.) While it's useful to broadcast your work, please have some consideration for the forum(s) you're doing that to. The way kernel development works is that patches are sent to mailing lists for review. Kernel developers review the patches and provide comments back. The comments are discussed and actioned, and a new set of patches posted for further review. This cycle repeats. When everyone is happy, the patches can be applied, or pulled from a non-github git tree. (Kernel people generally don't like github.) This is so that upstream kernel developers don't get too overloaded with work that really should be done by downstream folk (imagine if they had to rewrite every patch that came their way...) Thanks. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 8/8] DT: samsung-fimc: Add examples for samsung,flash-led property
Hi Jacek,
On Wed, May 20, 2015 at 04:10:15PM +0200, Jacek Anaszewski wrote:
This patch adds examples for samsung,flash-led property to the
samsung-fimc.txt.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: devicet...@vger.kernel.org
---
.../devicetree/bindings/media/samsung-fimc.txt |4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt
b/Documentation/devicetree/bindings/media/samsung-fimc.txt
index 922d6f8..57edffa 100644
--- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
@@ -126,6 +126,8 @@ Example:
clocks = camera 1;
clock-names = mclk;
+ samsung,flash-led = front_cam_flash;
+
port {
s5k6aa_ep: endpoint {
remote-endpoint = fimc0_ep;
@@ -147,6 +149,8 @@ Example:
clocks = camera 0;
clock-names = mclk;
+ samsung,flash-led = rear_cam_flash;
+
port {
s5c73m3_1: endpoint {
data-lanes = 1 2 3 4;
Oops. I missed this property would have ended to the sensor's DT node. I
don't think we should have properties here that are parsed by another
driver --- let's discuss this tomorrow.
There are two main options that I can think of --- either put the property
under the bridge (ISP) driver's device node as a temporary solution that
works on a few ISP drivers, or think how sensor modules should be modelled,
in which case we'd have some idea how lens device would be taken into
account.
Cc Sebastian.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL patches for 4.2]: New camera support for gspca sn9c2028 driver (v2)
Hi Mauro, Here is a new pull-req for the new camera support for the gspca sn9c2028 driver, now with my S-o-b added and the copyright change dropped. The following changes since commit 2a80f296422a01178d0a993479369e94f5830127: [media] dvb-core: fix 32-bit overflow during bandwidth calculation (2015-05-20 14:01:46 -0300) are available in the git repository at: git://linuxtv.org/hgoede/gspca.git media-for_v4.2 for you to fetch changes up to b4ede115fd1a37714e05e1180c399169e0e8d680: gspca: sn9c2028: Add gain and autogain controls Genius Videocam Live v2 (2015-05-20 19:47:11 +0200) Vasily Khoruzhick (2): gspca: sn9c2028: Add support for Genius Videocam Live v2 gspca: sn9c2028: Add gain and autogain controls Genius Videocam Live v2 drivers/media/usb/gspca/sn9c2028.c | 241 - drivers/media/usb/gspca/sn9c2028.h | 18 ++- 2 files changed, 255 insertions(+), 4 deletions(-) Thanks Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ATI TV Wonder regression since at least 3.19.6
On 05/15/2015 05:12 PM, Patrice Levesque wrote: Hi Hans, Function isn't used; when compiling I get: That makes no sense. This function is most definitely used. Idiot guy here did not follow simple instructions and didn't patch the right kernel source. He just did, and function is used. Did you start a capturing video first before running dmesg? I want to see if capturing video will generate messages in dmesg. Sending you again my (truncated) dmesg, but here's the annotated salient bit: Starting video capture first time: [Fri May 15 11:01:43 2015] restart_video_queue [Fri May 15 11:01:44 2015] restart_video_queue [Fri May 15 11:01:55 2015] restart_video_queue [Fri May 15 11:01:56 2015] restart_video_queue [Fri May 15 11:01:56 2015] restart_video_queue [Fri May 15 11:02:00 2015] restart_video_queue [Fri May 15 11:02:05 2015] restart_video_queue [Fri May 15 11:02:06 2015] restart_video_queue [Fri May 15 11:02:06 2015] restart_video_queue [Fri May 15 11:02:06 2015] restart_video_queue [Fri May 15 11:02:07 2015] restart_video_queue [Fri May 15 11:02:07 2015] restart_video_queue [Fri May 15 11:02:07 2015] restart_video_queue [Fri May 15 11:02:09 2015] restart_video_queue Stopping video capture: [Fri May 15 11:03:26 2015] restart_video_queue Re-Starting video capture: [Fri May 15 11:03:40 2015] restart_video_queue Stopping video capture: [Fri May 15 11:04:18 2015] restart_video_queue Changing channels didn't provoke restart_video_queue events. FYI: I've bought this card on ebay and I am waiting for it to arrive. Hopefully I can reproduce it and then I'll fix it. It's a fair bit of work, unfortunately. The fact that this function is called means that the DMA stalls every so often, and I'd like to know why that happens. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] gspca: sn9c2028: Add support for Genius Videocam Live v2
Hi,
On 20-05-15 14:12, Mauro Carvalho Chehab wrote:
Em Fri, 24 Apr 2015 10:04:03 +0300
Vasily Khoruzhick anars...@gmail.com escreveu:
This cam seems to return different values on long commands, so make status check
in sn9c2028_long_command() more tolerant. Anyway, read value isn't used anywhere
later.
Signed-off-by: Vasily Khoruzhick anars...@gmail.com
Hans,
You forgot to add your SOB on those two patches on your pull request.
Weird I always use git am -s, ah well. I'll send a new pull-req fixing this.
Regards,
Hans
---
v2: update commit message to explain change in sn9c2028_long_command()
drivers/media/usb/gspca/sn9c2028.c | 120 -
1 file changed, 119 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/gspca/sn9c2028.c
b/drivers/media/usb/gspca/sn9c2028.c
index 39b6b2e..317b02c 100644
--- a/drivers/media/usb/gspca/sn9c2028.c
+++ b/drivers/media/usb/gspca/sn9c2028.c
@@ -2,6 +2,7 @@
* SN9C2028 library
*
* Copyright (C) 2009 Theodore Kilgore kilg...@auburn.edu
+ * Copyright (C) 2015 Vasily Khoruzhick anars...@gmail.com
Hmm... adding a new copyright driver-wide only justifies if you changed 30%
or more of the code. The copyright of your changes will be preserved at
the git history.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -128,7 +129,7 @@ static int sn9c2028_long_command(struct gspca_dev
*gspca_dev, u8 *command)
status = -1;
for (i = 0; i 256 status 2; i++)
status = sn9c2028_read1(gspca_dev);
- if (status != 2) {
+ if (status 0) {
pr_err(long command status read error %d\n, status);
return (status 0) ? status : -EIO;
}
@@ -178,6 +179,9 @@ static int sd_config(struct gspca_dev *gspca_dev,
case 0x7005:
PDEBUG(D_PROBE, Genius Smart 300 camera);
break;
+ case 0x7003:
+ PDEBUG(D_PROBE, Genius Videocam Live v2);
+ break;
case 0x8000:
PDEBUG(D_PROBE, DC31VC);
break;
@@ -530,6 +534,116 @@ static int start_genius_cam(struct gspca_dev *gspca_dev)
ARRAY_SIZE(genius_start_commands));
}
+static int start_genius_videocam_live(struct gspca_dev *gspca_dev)
+{
+ int r;
+ struct sd *sd = (struct sd *) gspca_dev;
+ struct init_command genius_vcam_live_start_commands[] = {
+ {{0x0c, 0x01, 0x00, 0x00, 0x00, 0x00}, 0},
+ {{0x16, 0x01, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x10, 0x00, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x25, 0x01, 0x16, 0x00, 0x00}, 4},
+ {{0x13, 0x26, 0x01, 0x12, 0x00, 0x00}, 4},
+
+ {{0x13, 0x28, 0x01, 0x0e, 0x00, 0x00}, 4},
+ {{0x13, 0x27, 0x01, 0x20, 0x00, 0x00}, 4},
+ {{0x13, 0x29, 0x01, 0x22, 0x00, 0x00}, 4},
+ {{0x13, 0x2c, 0x01, 0x02, 0x00, 0x00}, 4},
+ {{0x13, 0x2d, 0x01, 0x02, 0x00, 0x00}, 4},
+ {{0x13, 0x2e, 0x01, 0x09, 0x00, 0x00}, 4},
+ {{0x13, 0x2f, 0x01, 0x07, 0x00, 0x00}, 4},
+ {{0x11, 0x20, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x21, 0x2d, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x22, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x23, 0x03, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x10, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x11, 0x64, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x12, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x13, 0x91, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x14, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x15, 0x20, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x16, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x17, 0x60, 0x00, 0x00, 0x00}, 4},
+ {{0x1c, 0x20, 0x00, 0x2d, 0x00, 0x00}, 4},
+ {{0x13, 0x20, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x21, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x22, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x23, 0x01, 0x01, 0x00, 0x00}, 4},
+ {{0x13, 0x24, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x25, 0x01, 0x16, 0x00, 0x00}, 4},
+ {{0x13, 0x26, 0x01, 0x12, 0x00, 0x00}, 4},
+ {{0x13, 0x27, 0x01, 0x20, 0x00, 0x00}, 4},
+ {{0x13, 0x28, 0x01, 0x0e, 0x00, 0x00}, 4},
+ {{0x13, 0x29, 0x01, 0x22, 0x00, 0x00}, 4},
+ {{0x13, 0x2a, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x2b, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x2c, 0x01, 0x02, 0x00, 0x00}, 4},
+ {{0x13, 0x2d, 0x01, 0x02, 0x00, 0x00}, 4},
+ {{0x13, 0x2e, 0x01, 0x09, 0x00, 0x00}, 4},
+ {{0x13, 0x2f, 0x01, 0x07, 0x00, 0x00}, 4},
+ {{0x12, 0x34, 0x01,
Re: [PATCH v3 1/7] rc: rc-ir-raw: Add scancode encoder callback
On 20 May 2015 at 21:29, David Härdeman da...@hardeman.nu wrote:
On Wed, May 20, 2015 at 07:46:21PM +0300, Antti Seppälä wrote:
On 19 May 2015 at 23:38, David Härdeman da...@hardeman.nu wrote:
On Tue, Mar 31, 2015 at 08:48:06PM +0300, Antti Seppälä wrote:
From: James Hogan ja...@albanarts.com
Add a callback to raw ir handlers for encoding and modulating a scancode
to a set of raw events. This could be used for transmit, or for
converting a wakeup scancode filter to a form that is more suitable for
raw hardware wake up filters.
Signed-off-by: James Hogan ja...@albanarts.com
Signed-off-by: Antti Seppälä a.sepp...@gmail.com
Cc: David Härdeman da...@hardeman.nu
---
Notes:
Changes in v3:
- Ported to apply against latest media-tree
Changes in v2:
- Alter encode API to return -ENOBUFS when there isn't enough buffer
space. When this occurs all buffer contents must have been written
with the partial encoding of the scancode. This is to allow drivers
such as nuvoton-cir to provide a shorter buffer and still get a
useful partial encoding for the wakeup pattern.
drivers/media/rc/rc-core-priv.h | 2 ++
drivers/media/rc/rc-ir-raw.c| 37 +
include/media/rc-core.h | 3 +++
3 files changed, 42 insertions(+)
diff --git a/drivers/media/rc/rc-core-priv.h
b/drivers/media/rc/rc-core-priv.h
index b68d4f76..122c25f 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -25,6 +25,8 @@ struct ir_raw_handler {
u64 protocols; /* which are handled by this handler */
int (*decode)(struct rc_dev *dev, struct ir_raw_event event);
+ int (*encode)(u64 protocols, const struct rc_scancode_filter
*scancode,
+struct ir_raw_event *events, unsigned int max);
/* These two should only be used by the lirc decoder */
int (*raw_register)(struct rc_dev *dev);
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index b732ac6..dd47fe5 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -246,6 +246,43 @@ static int change_protocol(struct rc_dev *dev, u64
*rc_type)
return 0;
}
+/**
+ * ir_raw_encode_scancode() - Encode a scancode as raw events
+ *
+ * @protocols:permitted protocols
+ * @scancode: scancode filter describing a single scancode
+ * @events: array of raw events to write into
+ * @max: max number of raw events
+ *
+ * Attempts to encode the scancode as raw events.
+ *
+ * Returns: The number of events written.
+ *-ENOBUFS if there isn't enough space in the array to fit the
+ *encoding. In this case all @max events will have been
written.
+ *-EINVAL if the scancode is ambiguous or invalid, or if no
+ *compatible encoder was found.
+ */
+int ir_raw_encode_scancode(u64 protocols,
Why a bitmask of protocols and not a single protocol enum? What's the
use case for encoding a given scancode according to one out of a number
of protocols (and not even knowing which one)??
I think bitmask was used simply for consistency reasons. Most of the
rc-core handles protocols in a bitmask (u64 protocols or some variant
of it).
Yes, all the parts where multiple protocols make sense use a bitmap of
protocols. If there's any part which uses a bitmap where only one
protocol makes sense that'd be a bug...
Especially in the decoders the dev-enabled_protocols is used
to mean decode any of these protocols but I don't care which one and
the encoders were written to follow that logic.
The fact that you might want to be able to receive and decode more than
one protocol has no bearing on encoding when you're supposed to know
what it is you want to encode
From ir driver point of view it was also kind of nice to use the u64
enabled_wakeup_protocols from struct rc_dev which already exists and
is manipulated with the same sysfs code as the enabled_protocols
bitmask.
But it makes no sense? here's a scancode...I have no idea what it means
since only knowing the protocol allows you to make any sense of the
scancode...but please encode it to something...anything
Well it made sense from code simplicity point of view :)
But yes current use cases will most likely be valid when encoding only
to a single specific protocol at a time. However having a flexible api
allows for future expansion though if a new use case is needed to be
supported. And like I said earlier using bitmask is also consistent
with what rc-core already has.
That being said I don't object if you wish to propose a patch to
refactor the bitmask to be an enumeration instead.
--
Antti
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/7] rc: rc-ir-raw: Add scancode encoder callback
On Wed, May 20, 2015 at 07:46:21PM +0300, Antti Seppälä wrote:
On 19 May 2015 at 23:38, David Härdeman da...@hardeman.nu wrote:
On Tue, Mar 31, 2015 at 08:48:06PM +0300, Antti Seppälä wrote:
From: James Hogan ja...@albanarts.com
Add a callback to raw ir handlers for encoding and modulating a scancode
to a set of raw events. This could be used for transmit, or for
converting a wakeup scancode filter to a form that is more suitable for
raw hardware wake up filters.
Signed-off-by: James Hogan ja...@albanarts.com
Signed-off-by: Antti Seppälä a.sepp...@gmail.com
Cc: David Härdeman da...@hardeman.nu
---
Notes:
Changes in v3:
- Ported to apply against latest media-tree
Changes in v2:
- Alter encode API to return -ENOBUFS when there isn't enough buffer
space. When this occurs all buffer contents must have been written
with the partial encoding of the scancode. This is to allow drivers
such as nuvoton-cir to provide a shorter buffer and still get a
useful partial encoding for the wakeup pattern.
drivers/media/rc/rc-core-priv.h | 2 ++
drivers/media/rc/rc-ir-raw.c| 37 +
include/media/rc-core.h | 3 +++
3 files changed, 42 insertions(+)
diff --git a/drivers/media/rc/rc-core-priv.h
b/drivers/media/rc/rc-core-priv.h
index b68d4f76..122c25f 100644
--- a/drivers/media/rc/rc-core-priv.h
+++ b/drivers/media/rc/rc-core-priv.h
@@ -25,6 +25,8 @@ struct ir_raw_handler {
u64 protocols; /* which are handled by this handler */
int (*decode)(struct rc_dev *dev, struct ir_raw_event event);
+ int (*encode)(u64 protocols, const struct rc_scancode_filter
*scancode,
+struct ir_raw_event *events, unsigned int max);
/* These two should only be used by the lirc decoder */
int (*raw_register)(struct rc_dev *dev);
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index b732ac6..dd47fe5 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -246,6 +246,43 @@ static int change_protocol(struct rc_dev *dev, u64
*rc_type)
return 0;
}
+/**
+ * ir_raw_encode_scancode() - Encode a scancode as raw events
+ *
+ * @protocols:permitted protocols
+ * @scancode: scancode filter describing a single scancode
+ * @events: array of raw events to write into
+ * @max: max number of raw events
+ *
+ * Attempts to encode the scancode as raw events.
+ *
+ * Returns: The number of events written.
+ *-ENOBUFS if there isn't enough space in the array to fit the
+ *encoding. In this case all @max events will have been written.
+ *-EINVAL if the scancode is ambiguous or invalid, or if no
+ *compatible encoder was found.
+ */
+int ir_raw_encode_scancode(u64 protocols,
Why a bitmask of protocols and not a single protocol enum? What's the
use case for encoding a given scancode according to one out of a number
of protocols (and not even knowing which one)??
I think bitmask was used simply for consistency reasons. Most of the
rc-core handles protocols in a bitmask (u64 protocols or some variant
of it).
Yes, all the parts where multiple protocols make sense use a bitmap of
protocols. If there's any part which uses a bitmap where only one
protocol makes sense that'd be a bug...
Especially in the decoders the dev-enabled_protocols is used
to mean decode any of these protocols but I don't care which one and
the encoders were written to follow that logic.
The fact that you might want to be able to receive and decode more than
one protocol has no bearing on encoding when you're supposed to know
what it is you want to encode
From ir driver point of view it was also kind of nice to use the u64
enabled_wakeup_protocols from struct rc_dev which already exists and
is manipulated with the same sysfs code as the enabled_protocols
bitmask.
But it makes no sense? here's a scancode...I have no idea what it means
since only knowing the protocol allows you to make any sense of the
scancode...but please encode it to something...anything
--
David Härdeman
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] gspca: sn9c2028: Add support for Genius Videocam Live v2
Hi Mauro, On Wed, May 20, 2015 at 3:12 PM, Mauro Carvalho Chehab mche...@osg.samsung.com wrote: Em Fri, 24 Apr 2015 10:04:03 +0300 Vasily Khoruzhick anars...@gmail.com escreveu: diff --git a/drivers/media/usb/gspca/sn9c2028.c b/drivers/media/usb/gspca/sn9c2028.c index 39b6b2e..317b02c 100644 --- a/drivers/media/usb/gspca/sn9c2028.c +++ b/drivers/media/usb/gspca/sn9c2028.c @@ -2,6 +2,7 @@ * SN9C2028 library * * Copyright (C) 2009 Theodore Kilgore kilg...@auburn.edu + * Copyright (C) 2015 Vasily Khoruzhick anars...@gmail.com Hmm... adding a new copyright driver-wide only justifies if you changed 30% or more of the code. The copyright of your changes will be preserved at the git history. OK, not a problem. Regards, Vasily -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu May 21 04:00:17 CEST 2015 git branch: test git hash: 2a80f296422a01178d0a993479369e94f5830127 gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-3.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin-bf561: ERRORS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: WARNINGS linux-3.12.23-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0-i686: WARNINGS linux-4.1-rc1-i686: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: WARNINGS linux-3.12.23-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0-x86_64: WARNINGS linux-4.1-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: ERRORS ABI WARNING: change for blackfin-bf561 ABI WARNING: change for mips smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/20] media: soc_camera pad-aware driver initialisation
On 05/20/2015 06:39 PM, William Towle wrote:
Add detection of source pad number for drivers aware of the media
controller API, so that soc_camera/rcar_vin can create device nodes
to support a driver such as adv7604.c (for HDMI on Lager) underneath.
Signed-off-by: William Towle william.to...@codethink.co.uk
Reviewed-by: Rob Taylor rob.tay...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c |4
drivers/media/platform/soc_camera/soc_camera.c | 27
+++-
include/media/soc_camera.h |1 +
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 0f67646..b4e9b43 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -1364,8 +1364,12 @@ static int rcar_vin_get_formats(struct
soc_camera_device *icd, unsigned int idx,
struct v4l2_mbus_framefmt *mf = fmt.format;
struct v4l2_rect rect;
struct device *dev = icd-parent;
+ struct media_pad *remote_pad;
int shift;
+ remote_pad = media_entity_remote_pad(
+ icd-vdev-entity.pads[0]);
+ fmt.pad = remote_pad-index;
This won't work if CONFIG_MEDIA_CONTROLLER isn't defined. All these media calls
would all
have to be under #ifdef CONFIG_MEDIA_CONTROLLER.
Unfortunately, if it is not defined, then you still have no way of finding the
source pad.
Laurent, do you think if it would make sense to add a new subdev core op that
will return
the default source pad (I'm saying 'default' in case there are more) of a
subdev? That way
it can be used in non-MC drivers. We never needed the source pad before, but
now we do,
and this op only needs to be implemented if the default source pad != 0.
Regards,
Hans
ret = v4l2_subdev_call(sd, pad, get_fmt, NULL, fmt);
if (ret 0)
return ret;
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index d708df4..126d645 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -1293,6 +1293,7 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
struct v4l2_mbus_framefmt *mf = fmt.format;
+ int src_pad_idx = -1;
int ret;
sd-grp_id = soc_camera_grp_id(icd);
@@ -1311,7 +1312,25 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
}
/* At this point client .probe() should have run already */
- ret = soc_camera_init_user_formats(icd);
+ ret = media_entity_init(icd-vdev-entity, 1, icd-pad, 0);
+ if (!ret) {
+ for (src_pad_idx = 0; src_pad_idx sd-entity.num_pads;
+ src_pad_idx++)
+ if (sd-entity.pads[src_pad_idx].flags
+ == MEDIA_PAD_FL_SOURCE)
+ break;
+
+ if (src_pad_idx sd-entity.num_pads) {
+ if (!media_entity_create_link(
+ icd-vdev-entity, 0,
+ sd-entity, src_pad_idx,
+ MEDIA_LNK_FL_IMMUTABLE |
+ MEDIA_LNK_FL_ENABLED)) {
+ ret = soc_camera_init_user_formats(icd);
+ }
+ }
+ }
+
if (ret 0)
goto eusrfmt;
@@ -1322,6 +1341,7 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
goto evidstart;
/* Try to improve our guess of a reasonable window format */
+ fmt.pad = src_pad_idx;
if (!v4l2_subdev_call(sd, pad, get_fmt, NULL, fmt)) {
icd-user_width = mf-width;
icd-user_height= mf-height;
@@ -1335,6 +1355,7 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
evidstart:
soc_camera_free_user_formats(icd);
eusrfmt:
+ media_entity_cleanup(icd-vdev-entity);
soc_camera_remove_device(icd);
return ret;
@@ -1856,6 +1877,10 @@ static int soc_camera_remove(struct soc_camera_device
*icd)
if (icd-num_user_formats)
soc_camera_free_user_formats(icd);
+ if (icd-vdev-entity.num_pads) {
+ media_entity_cleanup(icd-vdev-entity);
+ }
+
if (icd-clk) {
/* For the synchronous case */
v4l2_clk_unregister(icd-clk);
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 2f6261f..f0c5238 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -42,6 +42,7 @@ struct soc_camera_device {
Re: [PATCH 13/20] media: soc_camera: v4l2-compliance fixes for querycap
On 05/20/2015 06:39 PM, William Towle wrote: Fill in bus_info field and zero reserved field. Signed-off-by: Rob Taylor rob.tay...@codethink.co.uk Reviewed-by: William Towle william.to...@codethink.co.uk --- drivers/media/platform/soc_camera/soc_camera.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/soc_camera/soc_camera.c b/drivers/media/platform/soc_camera/soc_camera.c index fd7497e..583c5e6 100644 --- a/drivers/media/platform/soc_camera/soc_camera.c +++ b/drivers/media/platform/soc_camera/soc_camera.c @@ -954,6 +954,8 @@ static int soc_camera_querycap(struct file *file, void *priv, WARN_ON(priv != file-private_data); strlcpy(cap-driver, ici-drv_name, sizeof(cap-driver)); + strlcpy(cap-bus_info, platform:soc_camera, sizeof(cap-bus_info)); + memset(cap-reserved, 0, sizeof(cap-reserved)); Why the memset? That shouldn't be needed. Regards, Hans return ici-ops-querycap(ici, cap); } -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/20] media: rcar_vin: Use correct pad number in try_fmt
On 05/20/2015 06:39 PM, William Towle wrote:
From: Rob Taylor rob.tay...@codethink.co.uk
Fix rcar_vin_try_fmt to use the correct pad number when calling the
subdev set_fmt. Previously pad number 0 was always used, resulting in
EINVAL if the subdev cares about the pad number (e.g. ADV7612).
Signed-off-by: William Towle Taylor rob.tay...@codethink.co.uk
Reviewed-by: Rob Taylor rob.tay...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c | 29
+-
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index b4e9b43..571ab20 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -1707,12 +1707,13 @@ static int rcar_vin_try_fmt(struct soc_camera_device
*icd,
const struct soc_camera_format_xlate *xlate;
struct v4l2_pix_format *pix = f-fmt.pix;
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
- struct v4l2_subdev_pad_config pad_cfg;
+ struct v4l2_subdev_pad_config pad_cfg[sd-entity.num_pads];
Same problem: this relies on the presence of CONFIG_MEDIA_CONTROLLER.
This array can also get large which is bad when it is on the stack.
Laurent, I remember that you had plans to add an op that would allocate
and initialize this for you. Any progress on that?
Regards,
Hans
struct v4l2_subdev_format format = {
.which = V4L2_SUBDEV_FORMAT_TRY,
};
struct v4l2_mbus_framefmt *mf = format.format;
__u32 pixfmt = pix-pixelformat;
+ struct media_pad *remote_pad;
int width, height;
int ret;
@@ -1744,17 +1745,24 @@ static int rcar_vin_try_fmt(struct soc_camera_device
*icd,
mf-code = xlate-code;
mf-colorspace = pix-colorspace;
- ret = v4l2_device_call_until_err(sd-v4l2_dev, soc_camera_grp_id(icd),
- pad, set_fmt, pad_cfg, format);
+ remote_pad = media_entity_remote_pad(
+ icd-vdev-entity.pads[0]);
+ format.pad = remote_pad-index;
+
+ ret = v4l2_device_call_until_err(sd-v4l2_dev,
+ soc_camera_grp_id(icd), pad,
+ set_fmt, pad_cfg,
+ format);
if (ret 0)
return ret;
- /* Adjust only if VIN cannot scale */
- if (pix-width mf-width * 2)
- pix-width = mf-width * 2;
- if (pix-height mf-height * 3)
- pix-height = mf-height * 3;
-
+ /* In case the driver has adjusted 'fmt' to match the
+ * resolution of the live stream, 'pix' needs to pass this
+ * change out so that the buffer userland creates for the
+ * captured image/video has these dimensions
+ */
+ pix-width = mf-width;
+ pix-height = mf-height;
pix-field = mf-field;
pix-colorspace = mf-colorspace;
@@ -1769,9 +1777,10 @@ static int rcar_vin_try_fmt(struct soc_camera_device
*icd,
*/
mf-width = VIN_MAX_WIDTH;
mf-height = VIN_MAX_HEIGHT;
+ format.pad = remote_pad-index;
ret = v4l2_device_call_until_err(sd-v4l2_dev,
soc_camera_grp_id(icd),
- pad, set_fmt, pad_cfg,
+ pad, set_fmt, pad_cfg,
format);
if (ret 0) {
dev_err(icd-parent,
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] leds: aat1290: Pass dev and dev-of_node to v4l2_flash_init()
Hi Jacek, On Wed, May 20, 2015 at 03:47:25PM +0200, Jacek Anaszewski wrote: ... --- a/drivers/leds/leds-aat1290.c +++ b/drivers/leds/leds-aat1290.c @@ -524,9 +524,8 @@ static int aat1290_led_probe(struct platform_device *pdev) led_cdev-dev-of_node = sub_node; /* Create V4L2 Flash subdev. */ -led-v4l2_flash = v4l2_flash_init(fled_cdev, - v4l2_flash_ops, - v4l2_sd_cfg); +led-v4l2_flash = v4l2_flash_init(dev, NULL, fled_cdev, + v4l2_flash_ops, v4l2_sd_cfg); Here the first argument should be led_cdev-dev, not dev, which is pdev-dev, whereas led_cdev-dev is returned by device_create_with_groups (it takes dev as a parent) called from led_classdev_register. The reason for this is the fact that pdev-dev has its of_node field initialized, which makes v4l2_async trying to match subdev by parent node of a LED device, not by sub-LED related DT node. If v4l2_subdev-of_node is set, then it won't be replaced with one from struct device. I.e. you need to provide of_node pointer only if it's different from dev-of_node. It will always be different since dev-of_node pointer is related to the main DT node of LED device, whereas each LED connected to it must be expressed in the form of sub-node, as Documentation/devicetree/bindings/leds/common.txt DT states. You can still refer to the device's root device_node using a phandle. Say, if you have a LED flash controller with an indicator. It's intended to be used together with the flash LED, and the existing as3645a driver exposes it through the same sub-device. I think that'd make sense with LED class driver as well (i.e. you'd have two LED class devices but a single sub-device). Small changes to the wrapper would be needed. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cx24120: Assume ucb registers is a counter
The ucblocks register is probably a counter and not a rate; assume
it is so and change the calculations as required.
Signed-off-by: Jemma Denson jden...@gmail.com
---
drivers/media/dvb-frontends/cx24120.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/media/dvb-frontends/cx24120.c
b/drivers/media/dvb-frontends/cx24120.c
index a14d0f1..10a948e 100644
--- a/drivers/media/dvb-frontends/cx24120.c
+++ b/drivers/media/dvb-frontends/cx24120.c
@@ -154,7 +154,7 @@ struct cx24120_state {
u32 bitrate;
u32 berw_usecs;
u32 ber_prev;
- u32 per_prev;
+ u32 ucb_offset;
unsigned long ber_jiffies_stats;
unsigned long per_jiffies_stats;
};
@@ -698,8 +698,12 @@ static void cx24120_get_stats(struct cx24120_state *state)
ucb |= cx24120_readreg(state, CX24120_REG_UCB_L);
dev_dbg(state-i2c-dev, ucblocks = %d\n, ucb);
+ /* handle reset */
+ if (ucb state-ucb_offset)
+ state-ucb_offset = c-block_error.stat[0].uvalue;
+
c-block_error.stat[0].scale = FE_SCALE_COUNTER;
- c-block_error.stat[0].uvalue += ucb;
+ c-block_error.stat[0].uvalue = ucb + state-ucb_offset;
c-block_count.stat[0].scale = FE_SCALE_COUNTER;
c-block_count.stat[0].uvalue += state-bitrate / 8 / 208;
@@ -1541,8 +1545,7 @@ static int cx24120_read_ucblocks(struct dvb_frontend *fe,
u32 *ucblocks)
return 0;
}
- *ucblocks = c-block_error.stat[0].uvalue - state-per_prev;
- state-per_prev = c-block_error.stat[0].uvalue;
+ *ucblocks = c-block_error.stat[0].uvalue - state-ucb_offset;
return 0;
}
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 2/8] leds: max77693: add support for V4L2 Flash sub-device
On Wed, May 20, 2015 at 04:10:09PM +0200, Jacek Anaszewski wrote: Add support for V4L2 Flash sub-device to the max77693 LED Flash class driver. The support allows for V4L2 Flash sub-device to take the control of the LED Flash class device. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Sakari Ailus sakari.ai...@iki.fi Acked-by: Sakari Ailus sakari.ai...@linux.intel.com -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 1/8] media: Add registration helpers for V4L2 flash sub-devices
Hi Jacek,
On Wed, May 20, 2015 at 04:10:08PM +0200, Jacek Anaszewski wrote:
...
+struct v4l2_flash *v4l2_flash_init(
+ struct device *dev, struct device_node *of_node,
+ struct led_classdev_flash *fled_cdev, const struct v4l2_flash_ops *ops,
+ struct v4l2_flash_config *config)
+{
+ struct v4l2_flash *v4l2_flash;
+ struct led_classdev *led_cdev = fled_cdev-led_cdev;
+ struct v4l2_subdev *sd;
+ int ret;
+
+ if (!fled_cdev || !ops || !config)
+ return ERR_PTR(-EINVAL);
+
+ v4l2_flash = devm_kzalloc(led_cdev-dev, sizeof(*v4l2_flash),
+ GFP_KERNEL);
+ if (!v4l2_flash)
+ return ERR_PTR(-ENOMEM);
+
+ sd = v4l2_flash-sd;
+ v4l2_flash-fled_cdev = fled_cdev;
+ v4l2_flash-ops = ops;
+ sd-dev = dev;
+ sd-of_node = of_node;
+ v4l2_subdev_init(sd, v4l2_flash_subdev_ops);
+ sd-internal_ops = v4l2_flash_subdev_internal_ops;
+ sd-flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
+ strlcpy(sd-name, config-dev_name, sizeof(sd-name));
+
+ ret = media_entity_init(sd-entity, 0, NULL, 0);
+ if (ret 0)
+ return ERR_PTR(ret);
+
+ sd-entity.type = MEDIA_ENT_T_V4L2_SUBDEV_FLASH;
+
+ ret = v4l2_flash_init_controls(v4l2_flash, config);
+ if (ret 0)
+ goto err_init_controls;
+
+ of_node_get(led_cdev-dev-of_node);
+
+ ret = v4l2_async_register_subdev(sd);
+ if (ret 0)
+ goto err_async_register_sd;
+
+ return v4l2_flash;
+
+err_async_register_sd:
+ of_node_put(led_cdev-dev-of_node);
+ v4l2_ctrl_handler_free(sd-ctrl_handler);
+err_init_controls:
+ media_entity_cleanup(sd-entity);
+
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(v4l2_flash_init);
+
+void v4l2_flash_release(struct v4l2_flash *v4l2_flash)
+{
+ struct v4l2_subdev *sd;
+ struct led_classdev *led_cdev;
+
+ if (IS_ERR(v4l2_flash))
I propose to use IS_ERR_OR_NULL() instead. Then this can be safely called
without calling v4l2_flash_init() first, making error handling easier.
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
+ return;
+
+ sd = v4l2_flash-sd;
+ led_cdev = v4l2_flash-fled_cdev-led_cdev;
+
+ v4l2_async_unregister_subdev(sd);
+ of_node_put(led_cdev-dev-of_node);
+ v4l2_ctrl_handler_free(sd-ctrl_handler);
+ media_entity_cleanup(sd-entity);
+}
+EXPORT_SYMBOL_GPL(v4l2_flash_release);
...
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
