Re
Hello Friend', I have a transaction which is of mutual benefits and I would like to share with you. if interested for more information please get back to me via email.Thank you.Yours sincerely,Mr.Tong Hao. ** Disclaimer: This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. Unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. If you have received this e-mail in error, please notify the sender and delete the e-mail and any copies of it.Please note that Central Restaurants Group Co.,Ltd,is able to, and reserves the right to, monitor e-mail communications passing through its network. ** -- 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 2/2] v4l: Add v4l2 subdev driver for S5K6AAFX sensor
On Fri, Sep 23, 2011 at 12:12:58PM +0200, Sylwester Nawrocki wrote:
Hi Sakari,
Hi Sylwester,
On 09/23/2011 12:02 AM, Sakari Ailus wrote:
Hi Sylwester,
I have a few additional comments below, they don't depend on my earlier
ones.
Thanks a lot for your follow up review!
On Wed, Sep 21, 2011 at 07:45:07PM +0200, Sylwester Nawrocki wrote:
This driver exposes preview mode operation of the S5K6AAFX sensor with
embedded SoC ISP. It uses one of the five user predefined configuration
register sets. There is yet no support for capture (snapshot) operation.
Following controls are supported:
manual/auto exposure and gain, power line frequency (anti-flicker),
saturation, sharpness, brightness, contrast, white balance temperature,
color effects, horizontal/vertical image flip, frame interval.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
...
+
+struct s5k6aa_pixfmt {
+ enum v4l2_mbus_pixelcode code;
+ u32 colorspace;
+ /* REG_P_FMT(x) register value */
+ u16 reg_p_fmt;
+};
+
+struct s5k6aa_preset {
+ struct v4l2_frmsize_discrete out_size;
+ struct v4l2_rect in_win;
+ const struct s5k6aa_pixfmt *pixfmt;
+ unsigned int inv_hflip:1;
+ unsigned int inv_vflip:1;
+ u8 frame_rate_type;
+ u8 index;
+};
+
[clip]
+/* Set initial values for all preview presets */
+static void s5k6aa_presets_data_init(struct s5k6aa *s5k6aa,
+ int hflip, int vflip)
+{
+ struct s5k6aa_preset *preset = s5k6aa-presets[0];
+ int i;
+
+ for (i = 0; i S5K6AA_MAX_PRESETS; i++) {
+ preset-pixfmt = s5k6aa_formats[0];
+ preset-frame_rate_type = FR_RATE_DYNAMIC;
+ preset-inv_hflip = hflip;
+ preset-inv_vflip = vflip;
+ preset-out_size.width = S5K6AA_OUT_WIDTH_DEF;
+ preset-out_size.height = S5K6AA_OUT_HEIGHT_DEF;
+ preset-in_win.width= S5K6AA_WIN_WIDTH_MAX;
+ preset-in_win.height = S5K6AA_WIN_HEIGHT_MAX;
+ preset-in_win.left = 0;
+ preset-in_win.top = 0;
Much of this data is static, why is it copied to the presets struct?
What is the intended purpose of these presets?
I agree there is no need to keep inv_hflip/inv_vflip there. It's more a
leftover from previous driver version. I'll move it to struct s5k6aa.
And I try to keep copy of each platform_data attribute in driver's
private struct to make future transition to DT driver probing easier.
inv_[hv]flip variables are used to indicate physical layout of the sensor,
as it varies across multiple machines. So indeed they're global, not per
the configuration set.
Preset are there in the s5k6aafx register interface to allow fast transition
between, for instance, low resolution preview and high resolution snapshot.
I'm planning to use this driver as an experimental rabbit for the future
snapshot mode API.
It sounds like that a snapshot mode would be an use case that presets
could support in a way, but what I'd really like to ask is how much
advantage one can get by using this mode, say, vs. re-programming the same
settings over the I2C bus? The bus transfers (I assume) roughly 40 kB/s, so
I imagine a few tens of register writes can be avoided by most, taking
somewhere in the range of a few milliseconds.
I would rather measure and attempt to optimise the register writes in the
driver first before adding complexity to user space interface.
Or do the presets provide other advantages than just storing configurations?
in_win field is there for cropping support. So for now it's static data,
but this will change. I've covered pretty much functionality of the device
in this driver and I'd like to have it in mainline at this stage.
I've spent pretty much time on this driver, trying to figure out some
things on trial and error basis.
[clip]
+
+/* Set horizontal and vertical image flipping */
+static int s5k6aa_set_mirror(struct s5k6aa *s5k6aa, int horiz_flip)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(s5k6aa-sd);
+ struct s5k6aa_preset *preset = s5k6aa-preset;
+
+ unsigned int vflip = s5k6aa-ctrls.vflip-val ^ preset-inv_vflip;
+ unsigned int hflip = horiz_flip ^ preset-inv_hflip;
I don't see a need to store inv_hflip to presets. Instead, you might just
have a mirror bit in the platform data.
Agreed, except I'd like to keep that in driver's private data structure,
not to rely on the platform data after the driver probing.
There's no reason to avoid using platform data after probing that I am aware
of.
+ return s5k6aa_write(client, REG_P_PREV_MIRROR(preset-index),
+ hflip | (vflip 1));
+}
+
...
+
+static int __s5k6aa_power_enable(struct s5k6aa *s5k6aa)
+{
+ int ret;
+
+ ret = regulator_bulk_enable(S5K6AA_NUM_SUPPLIES, s5k6aa-supplies);
+
Re: [PATCH 1/17]DVB:Siano drivers - Adding LKM for handling SPI connected devices.
On Fri, 2011-09-23 at 17:20 -0300, Mauro Carvalho Chehab wrote: Em 20-09-2011 07:30, Doron Cohen escreveu: Hi, It took a long time to merge all the changes in kernel.org with Siano sources which were updated in a different repository for the last couple of years. I have made all the changes in small steps seperated to functional reasons. First patch is actually adding new kernel object which handles SPI connection and used the spidrv of the kernel. module is used mainly in android platforms but is a pure LKM works with siano modules stack. Thanks, Doron Cohen - From 9115d85edbafc38e48ed1fc5f1218da81b7c5a2e Mon Sep 17 00:00:00 2001 From: Doron Cohen dor...@siano-ms.com Date: Mon, 12 Sep 2011 17:41:29 +0300 Subject: [PATCH 02/21] Add support in generic SPI driver for Siano SPI connected devices --- drivers/media/dvb/siano/Kconfig| 45 drivers/media/dvb/siano/smsspicommon.c | 408 drivers/media/dvb/siano/smsspicommon.h | 96 +++ drivers/media/dvb/siano/smsspidrv.c| 455 drivers/media/dvb/siano/smsspiphy.c| 246 + drivers/media/dvb/siano/smsspiphy.h| 36 +++ 6 files changed, 1286 insertions(+), 0 deletions(-) create mode 100644 drivers/media/dvb/siano/smsspicommon.c create mode 100644 drivers/media/dvb/siano/smsspicommon.h create mode 100644 drivers/media/dvb/siano/smsspidrv.c create mode 100644 drivers/media/dvb/siano/smsspiphy.c create mode 100644 drivers/media/dvb/siano/smsspiphy.h diff --git a/drivers/media/dvb/siano/Kconfig b/drivers/media/dvb/siano/Kconfig index bc6456e..aeca46f 100644 --- a/drivers/media/dvb/siano/Kconfig +++ b/drivers/media/dvb/siano/Kconfig @@ -17,6 +17,37 @@ config SMS_SIANO_MDTV if SMS_SIANO_MDTV menu Siano module components +# Kernel sub systems support + +config SMS_DVB3_SUBSYS + bool DVB v.3 Subsystem support + depends on DVB_CORE + default y if DVB_CORE + ---help--- + Choose if you would like to have DVB v.3 kernel sub-system support. + +config SMS_DVB5_S2API_SUBSYS + bool DVB v.5 (S2 API) Subsystem support + default n + ---help--- + Choose if you would like to have DVB v.5 (S2 API) kernel sub-system support. NACK. The driver should be able to handle a call for programs that use either DVB v3 or DVB v5 calls, and this feature is mandatory for all DVB drivers. + +config SMS_HOSTLIB_SUBSYS + bool Host Library Subsystem support + default n + ---help--- + Choose if you would like to have Siano's host library kernel sub-system support. NACK. Proprietary/alternative API support shouldn't be added at the Linux Kernel. There's only one API defined to talk with a DTV device, and all drivers should implement it only. If you detect that some API features are missing at the DVB API, please discuss what is missing and let's work to add those features at the API. + +if SMS_HOSTLIB_SUBSYS + +config SMS_NET_SUBSYS + tristate Siano Network Adapter + depends on NET + default n + ---help--- + Choose if you would like to have Siano's network adapter support. +endif # SMS_HOSTLIB_SUBSYS + # Hardware interfaces support config SMS_USB_DRV @@ -30,5 +61,19 @@ config SMS_SDIO_DRV depends on DVB_CORE MMC ---help--- Choose if you would like to have Siano's support for SDIO interface + +config SMS_SPI_DRV + tristate SPI interface support + depends on SPI + default y if SPI + ---help--- + Choose if you would like to have Siano's support for PXA 310 SPI interface + +config SMS_I2C_DRV + tristate I2C interface support + depends on DVB_CORE I2C + ---help--- + Choose if you would like to have Siano's support for I2C interface + endmenu endif # SMS_SIANO_MDTV diff --git a/drivers/media/dvb/siano/smsspicommon.c b/drivers/media/dvb/siano/smsspicommon.c new file mode 100644 index 000..d4ef3f8 --- /dev/null +++ b/drivers/media/dvb/siano/smsspicommon.c @@ -0,0 +1,408 @@ +/ + +Siano Mobile Silicon, Inc. +MDTV receiver kernel modules. +Copyright (C) 2006-2008, Uri Shkolnik + +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. + + This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program.
Re: [PATCH 4/5] ispccdc: Configure CCDC_SYN_MODE register for UYVY8_2X8 and YUYV8_2X8 formats
On Wed, Sep 21, 2011 at 11:06:41AM +0200, Laurent Pinchart wrote:
Hi Deepthy,
Hi,
(Dropped most of people and lists from cc. I don't think Andrew Morton, for
example, has immediate interest towards this topic. Feel free to prome me
wrong.)
On Wednesday 21 September 2011 07:32:44 Ravi, Deepthy wrote:
On Wednesday, September 21, 2011 4:56 AM Laurent Pinchart wrote:
On Tuesday 20 September 2011 16:56:51 Deepthy Ravi wrote:
Configure INPMOD and PACK8 fileds of CCDC_SYN_MODE
register for UYVY8_2X8 and YUYV8_2X8 formats.
Signed-off-by: Deepthy Ravi deepthy.r...@ti.com
---
drivers/media/video/omap3isp/ispccdc.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispccdc.c
b/drivers/media/video/omap3isp/ispccdc.c index 418ba65..1dcf180 100644
--- a/drivers/media/video/omap3isp/ispccdc.c
+++ b/drivers/media/video/omap3isp/ispccdc.c
@@ -985,8 +985,12 @@ static void ccdc_config_sync_if(struct
isp_ccdc_device
*ccdc,
syn_mode = ~ISPCCDC_SYN_MODE_INPMOD_MASK;
if (format-code == V4L2_MBUS_FMT_YUYV8_2X8 ||
- format-code == V4L2_MBUS_FMT_UYVY8_2X8)
- syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8;
+ format-code == V4L2_MBUS_FMT_UYVY8_2X8){
+ if (pdata pdata-bt656)
+ syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR8;
+ else
+ syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
+ }
else if (format-code == V4L2_MBUS_FMT_YUYV8_1X16 ||
format-code == V4L2_MBUS_FMT_UYVY8_1X16)
syn_mode |= ISPCCDC_SYN_MODE_INPMOD_YCBCR16;
@@ -1172,7 +1176,8 @@ static void ccdc_configure(struct isp_ccdc_device
*ccdc) syn_mode = ~ISPCCDC_SYN_MODE_SDR2RSZ;
/* Use PACK8 mode for 1byte per pixel formats. */
- if (omap3isp_video_format_info(format-code)-width = 8)
+ if ((omap3isp_video_format_info(format-code)-width = 8)
+ (omap3isp_video_format_info(format-code)-bpp =
8))
I'm not sure to follow you. This will clear the PACK8 bit for the
YUYV8_2X8 formats. Those formats are 8 bits wide, shouldn't PACK8 be set
to store samples on 8 bits instead of 16 bits ?
Is this patch intended to support YUYV8_2X8 sensors in non BT.656 mode
with the bridge enabled ? In that case, what would you think about setting
the CCDC input format to YUYV8_1X16 instead ? This would better reflect
the reality, as the bridge converts YUYV8_2X8 to YUYV8_1X16, and the CCDC
is then fed with YUYV8_1X16.
Yes this is intended for YUYV8_2X8 sensors in non BT.656 with 8 to 16 bit
bridge enabled. So the data has to be stored as 16 bits per sample. Thats
why PACK8 is cleared . I am not sure about using YUYV8_1X16.
My original idea when I wrote the YV support patches was to implement this
use
case with YUYV8_2X8 at the sensor output and YUYV8_1X16 at the CCDC input.
The
ISP driver could then enable the bridge automatically. I'm not sure if that's
the best solution though, it might be confusing for the users. What I would
like to keep, however, is the idea of enabling the bridge automatically.
Sakari, any opinion on this ?
Are there any complications from the CCDC also listing the 2X8 formats as
supported in its sink pad? I'd rather support them since doing it the other
way might be somewhat confusing to the users. This would also mean media-ctl
users would have to set both sink and source formats rather than just the
source format when configuring the format for the link.
syn_mode |= ISPCCDC_SYN_MODE_PACK8;
else
syn_mode = ~ISPCCDC_SYN_MODE_PACK8;
--
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
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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/17]DVB:Siano drivers - Adding LKM for handling SPI connected devices.
Em 25-09-2011 07:25, Doron Cohen escreveu: On Fri, 2011-09-23 at 17:20 -0300, Mauro Carvalho Chehab wrote: Em 20-09-2011 07:30, Doron Cohen escreveu: Hi, It took a long time to merge all the changes in kernel.org with Siano sources which were updated in a different repository for the last couple of years. I have made all the changes in small steps seperated to functional reasons. First patch is actually adding new kernel object which handles SPI connection and used the spidrv of the kernel. module is used mainly in android platforms but is a pure LKM works with siano modules stack. Thanks, Doron Cohen Hi Mauro, Thanks for your response. I am going over your comments and changing my patches according to your comments. Also running the checkpatch script and remove all errors and warnings. Thanks! Please advice what would be the right way to continue: 1. Reply each patch and put the new corrected patch below the old commented patch. or 2. Open a new thread with the corrected patch. What most developers do is to argument against my review when needed, using the existing thread. Then, they open a [PATCH v2] thread with the new patchset. 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: Status of the patches under review at LMML (28 patches)
Em 24-09-2011 15:11, Manu Abraham escreveu: On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Everything at patchwork were reviewed by me, and I've applied all patches that I didn't notice any review by the drivers maintainers. Driver maintainers: Please review the remaining patches. == Patches for Manu Abraham abraham.m...@gmail.com review == Jun,11 2010: stb0899: Removed an extra byte sent at init on DiSEqC bus http://patchwork.linuxtv.org/patch/3639 Florent AUDEBERT florent.audeb...@anevia.com A single byte doesn't make much of a difference, but well it is still a difference. The DiSEqC has some known issues and has some tricky workarounds for different Silicon cuts. This patch *might* be good on some chips while have an adverse effect. But that said I have not tested this patch. If general users would like to have this patch and is proven good on different versions, I have no objection for this patch to go in. In which case; Acked-by: Manu Abraham m...@linuxtv.org Ok. Well, let's apply it and see the feedbacks if any. Thanks for reviewing it! 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
Problems cloning the git repostories
Hello there, I tried to follow the steps for cloning both the media_tree.git and media_build.git repositories, and received errors for both. The media_tree repository failed on the first line git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v4l-dvb which I'm assuming is because kernel.org is down. The media_build.git repository fails on the first line also git clone git://linuxtv.org/media_build.git with a fatal: read error: Connection reset by peer. Is it possible to clone either (or both) repositories at this time, or are they down? And in the absence of cloning the kernel for the media_tree.git repository, is it possible to simply clone the git://linuxtv.org/media_tree.git repository and work from that? My interest in this is to install some patches created by Devin Heitmueller for the Pinnacle PCTV 80e USB tuner (at least the ATSC portion of the tuner). Once I'm able to determine exactly what changes are made, I would like to either submit the patches to the repository, or send them to someone who has more experience in patching the files for submission. One other question (totally unrelated to this post though): When I send emails, normally they are GPG signed. Should I disable that for this list, or is it acceptable? Thank you for any information, and have a great day:) 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
Re: Status of the patches under review at LMML (28 patches)
Em 24-09-2011 15:29, Manu Abraham escreveu: On Sat, Sep 24, 2011 at 6:04 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Everything at patchwork were reviewed by me, and I've applied all patches that I didn't notice any review by the drivers maintainers. Driver maintainers: Please review the remaining patches. == Patches for Manu Abraham abraham.m...@gmail.com review == Ok, status updated at all patches, and added the ones that were acked/reviewed. Jun, 8 2011: Add remote control support for mantis http://patchwork.linuxtv.org/patch/7217 Christoph Pinkl christoph.pi...@gmail.com Haven't tested this patch. Please hold on with this patch. Ok. FYI, this patch looks correct on my eyes, with respect to RC core usage. Thanks, 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 v3] EM28xx - fix deadlock when unplugging and replugging a DVB adapter
Em 24-09-2011 17:54, Chris Rankin escreveu: This fixes the deadlock that occurs with either multiple PCTV 290e adapters or when a single PCTV 290e adapter is replugged. For DVB devices, the device lock must now *not* be held when adding/removing either a device or an extension to the respective lists. (Because em28xx_init_dvb() will want to take the lock instead). Conversely, for Audio-Only devices, the device lock *must* be held when adding/removing either a device or an extension to the respective lists. Signed-off-by: Chris Rankin ranki...@yahoo.com Ok, I've applied it, but it doesn't sound a good idea to me to do: + mutex_unlock(dev-lock); em28xx_init_extension(dev); + mutex_lock(dev-lock); I'll later test it with some hardware and see how well this behaves in practice. Thanks, 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 v3] EM28xx - fix deadlock when unplugging and replugging a DVB adapter
Em 24-09-2011 17:54, Chris Rankin escreveu:
This fixes the deadlock that occurs with either multiple PCTV 290e adapters
or when a single PCTV 290e adapter is replugged.
For DVB devices, the device lock must now *not* be held when adding/removing
either a device or an extension to the respective lists. (Because
em28xx_init_dvb() will want to take the lock instead).
Conversely, for Audio-Only devices, the device lock *must* be held when
adding/removing either a device or an extension to the respective lists.
Signed-off-by: Chris Rankin ranki...@yahoo.com
Hmm... This would probably work better (not tested). Could you please test it
on your hardware?
From: Mauro Carvalho Chehab mche...@redhat.com
Date: Sat, 24 Sep 2011 16:54:58 -0300
Subject: [media] em28xx: fix deadlock when unplugging and replugging a DVB
adapter
This fixes the deadlock that occurs with either multiple PCTV 290e
adapters or when a single PCTV 290e adapter is replugged.
For DVB devices, the device lock must now *not* be held when
adding/removing either a device or an extension to the respective lists.
(Because em28xx_init_dvb() will want to take the lock instead).
Conversely, for Audio-Only devices, the device lock *must* be held when
adding/removing either a device or an extension to the respective lists.
Based on a patch from Chris Rankin ranki...@yahoo.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 7297d90..c92c177 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -3005,7 +3005,8 @@ static int em28xx_init_dev(struct em28xx **devhandle,
struct usb_device *udev,
goto fail;
}
- em28xx_init_extension(dev);
+ /* dev-lock needs to be holded */
+ __em28xx_init_extension(dev);
/* Save some power by putting tuner to sleep */
v4l2_device_call_all(dev-v4l2_dev, 0, core, s_power, 0);
@@ -3301,10 +3302,10 @@ static void em28xx_usb_disconnect(struct usb_interface
*interface)
em28xx_release_resources(dev);
}
- em28xx_close_extension(dev);
-
mutex_unlock(dev-lock);
+ em28xx_close_extension(dev);
+
if (!dev-users) {
kfree(dev-alt_max_pkt_size);
kfree(dev);
diff --git a/drivers/media/video/em28xx/em28xx-core.c
b/drivers/media/video/em28xx/em28xx-core.c
index 804a4ab..afddfea 100644
--- a/drivers/media/video/em28xx/em28xx-core.c
+++ b/drivers/media/video/em28xx/em28xx-core.c
@@ -1218,16 +1218,22 @@ void em28xx_unregister_extension(struct em28xx_ops *ops)
}
EXPORT_SYMBOL(em28xx_unregister_extension);
-void em28xx_init_extension(struct em28xx *dev)
+/* Need to take the mutex lock before calling it */
+void __em28xx_init_extension(struct em28xx *dev)
{
const struct em28xx_ops *ops = NULL;
- mutex_lock(em28xx_devlist_mutex);
list_add_tail(dev-devlist, em28xx_devlist);
list_for_each_entry(ops, em28xx_extension_devlist, next) {
if (ops-init)
ops-init(dev);
}
+}
+
+void em28xx_init_extension(struct em28xx *dev)
+{
+ mutex_lock(em28xx_devlist_mutex);
+ __em28xx_init_extension(dev);
mutex_unlock(em28xx_devlist_mutex);
}
diff --git a/drivers/media/video/em28xx/em28xx.h
b/drivers/media/video/em28xx/em28xx.h
index 1626e4a..a5c1ba2 100644
--- a/drivers/media/video/em28xx/em28xx.h
+++ b/drivers/media/video/em28xx/em28xx.h
@@ -682,6 +682,7 @@ void em28xx_remove_from_devlist(struct em28xx *dev);
void em28xx_add_into_devlist(struct em28xx *dev);
int em28xx_register_extension(struct em28xx_ops *dev);
void em28xx_unregister_extension(struct em28xx_ops *dev);
+void __em28xx_init_extension(struct em28xx *dev);
void em28xx_init_extension(struct em28xx *dev);
void em28xx_close_extension(struct em28xx *dev);
--
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] EM28xx - fix deadlock when unplugging and replugging a DVB adapter
On 25/09/11 13:49, Mauro Carvalho Chehab wrote: Ok, I've applied it, but it doesn't sound a good idea to me to do: + mutex_unlock(dev-lock); em28xx_init_extension(dev); + mutex_lock(dev-lock); I'll later test it with some hardware and see how well this behaves in practice. No, I don't like it either. But since a kernel mutex isn't recursive, I can't think of a better solution at the moment. Cheers, Chris -- 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] EM28xx - fix deadlock when unplugging and replugging a DVB adapter
On 25/09/11 14:00, Mauro Carvalho Chehab wrote:
Hmm... This would probably work better (not tested). Could you please test it
on your hardware?
Hmm, I don't understand this. The deadlock isn't about taking
em28xx_devlist_mutex, but happens because em28xx_dvb_init() tries to retake
dev-lock when em28xx_usb_probe() is already holding it. That's why I unlocked
dev-lock before calling em28xx_init_extension().
So why are you avoiding locking em28xx_devlist_mutex?
Cheers,
Chris
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 7297d90..c92c177 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -3005,7 +3005,8 @@ static int em28xx_init_dev(struct em28xx **devhandle,
struct usb_device *udev,
goto fail;
}
- em28xx_init_extension(dev);
+ /* dev-lock needs to be holded */
+ __em28xx_init_extension(dev);
/* Save some power by putting tuner to sleep */
v4l2_device_call_all(dev-v4l2_dev, 0, core, s_power, 0);
@@ -3301,10 +3302,10 @@ static void em28xx_usb_disconnect(struct usb_interface
*interface)
em28xx_release_resources(dev);
}
- em28xx_close_extension(dev);
-
mutex_unlock(dev-lock);
+ em28xx_close_extension(dev);
+
if (!dev-users) {
kfree(dev-alt_max_pkt_size);
kfree(dev);
diff --git a/drivers/media/video/em28xx/em28xx-core.c
b/drivers/media/video/em28xx/em28xx-core.c
index 804a4ab..afddfea 100644
--- a/drivers/media/video/em28xx/em28xx-core.c
+++ b/drivers/media/video/em28xx/em28xx-core.c
@@ -1218,16 +1218,22 @@ void em28xx_unregister_extension(struct em28xx_ops *ops)
}
EXPORT_SYMBOL(em28xx_unregister_extension);
-void em28xx_init_extension(struct em28xx *dev)
+/* Need to take the mutex lock before calling it */
+void __em28xx_init_extension(struct em28xx *dev)
{
const struct em28xx_ops *ops = NULL;
- mutex_lock(em28xx_devlist_mutex);
list_add_tail(dev-devlist,em28xx_devlist);
list_for_each_entry(ops,em28xx_extension_devlist, next) {
if (ops-init)
ops-init(dev);
}
+}
+
+void em28xx_init_extension(struct em28xx *dev)
+{
+ mutex_lock(em28xx_devlist_mutex);
+ __em28xx_init_extension(dev);
mutex_unlock(em28xx_devlist_mutex);
}
diff --git a/drivers/media/video/em28xx/em28xx.h
b/drivers/media/video/em28xx/em28xx.h
index 1626e4a..a5c1ba2 100644
--- a/drivers/media/video/em28xx/em28xx.h
+++ b/drivers/media/video/em28xx/em28xx.h
@@ -682,6 +682,7 @@ void em28xx_remove_from_devlist(struct em28xx *dev);
void em28xx_add_into_devlist(struct em28xx *dev);
int em28xx_register_extension(struct em28xx_ops *dev);
void em28xx_unregister_extension(struct em28xx_ops *dev);
+void __em28xx_init_extension(struct em28xx *dev);
void em28xx_init_extension(struct em28xx *dev);
void em28xx_close_extension(struct em28xx *dev);
--
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] EM28xx - remove unused prototypes
Mauro, This patch just removes the prototypes for the two functions that I've already deleted in my previous patches. Cheers, Chris Signed-off-by: Chris Rankin ranki...@yahoo.com --- linux/drivers/media/video/em28xx/em28xx.h.orig 2011-09-25 14:46:02.0 +0100 +++ linux/drivers/media/video/em28xx/em28xx.h 2011-09-25 14:46:10.0 +0100 @@ -678,8 +678,6 @@ int em28xx_set_mode(struct em28xx *dev, enum em28xx_mode set_mode); int em28xx_gpio_set(struct em28xx *dev, struct em28xx_reg_seq *gpio); void em28xx_wake_i2c(struct em28xx *dev); -void em28xx_remove_from_devlist(struct em28xx *dev); -void em28xx_add_into_devlist(struct em28xx *dev); int em28xx_register_extension(struct em28xx_ops *dev); void em28xx_unregister_extension(struct em28xx_ops *dev); void em28xx_init_extension(struct em28xx *dev);
Re: Problems cloning the git repostories
On Sun, Sep 25, 2011 at 8:33 AM, Patrick Dickey pdickeyb...@gmail.com wrote: Hello there, I tried to follow the steps for cloning both the media_tree.git and media_build.git repositories, and received errors for both. The media_tree repository failed on the first line git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v4l-dvb which I'm assuming is because kernel.org is down. The media_build.git repository fails on the first line also git clone git://linuxtv.org/media_build.git with a fatal: read error: Connection reset by peer. Is it possible to clone either (or both) repositories at this time, or are they down? And in the absence of cloning the kernel for the media_tree.git repository, is it possible to simply clone the git://linuxtv.org/media_tree.git repository and work from that? My interest in this is to install some patches created by Devin Heitmueller for the Pinnacle PCTV 80e USB tuner (at least the ATSC portion of the tuner). Once I'm able to determine exactly what changes are made, I would like to either submit the patches to the repository, or send them to someone who has more experience in patching the files for submission. One other question (totally unrelated to this post though): When I send emails, normally they are GPG signed. Should I disable that for this list, or is it acceptable? Thank you for any information, and have a great day:) Patrick. Hi Patrick, As I said on the blog, the issue isn't getting the driver to work against current kernels. Merging the driver against the current tree is a trivial exercise (the patch series should apply trivially against the current code, with only a few minor conflicts related to board numbers, etc). The bigger issue though is once you do that and have the driver running, you now have a body of code 10,000 lines which doesn't meet the coding standards. Doing such a refactoring is a relatively straightforward exercise but very time consuming (you already have a working driver, so you just have to make sure you don't break anything). The more I think about this, the more it annoys me. I did all the hard parts: * I worked with the product vendor to get the details for the design * I got Hauppauge/PCTV to compel the chipset vendor to release the reference code under a GPL compatible license * I worked out redistribution terms on the firmware * I ported the driver to Linux * I integrated the driver and debugged it to achieve signal lock And why is it not in the mainline? Because none of the above matters if I didn't waste a bunch of my time removing a bunch of #ifdef WINDOWS lines and converting whitespace from tabs to spaces. It's crap like this that's the reason why some of the best LinuxTV driver authors still have a bunch of stuff that isn't merged upstream. We just don't have time for this sort of bullshit that any monkey could do if he/she was willing to invest the effort. We're just too busy doing *actual* driver work. Five years ago the hard part was finding competent developers, getting access to datasheets, getting access to reference driver code, and getting access to the details for a hardware design. Now most of those problems are not the issue - we have access to all the data but we want to waste the time of the few competent developers out there making them do coding style cleanup before perfectly good code gets merged upstream. There has been more than one case where I've considered doing a driver for a new board and decided against it because the barrier to getting it upstream is not worth my time. Want to see more device support upstream? Optimize the process to make it easy for the people who know the hardware and how to write the drivers to get code upstream, and leave it to the janitors to work out the codingstyle issues. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.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: Problems cloning the git repostories
On Sun, Sep 25, 2011 at 3:33 PM, Patrick Dickey pdickeyb...@gmail.com wrote: Hello there, I tried to follow the steps for cloning both the media_tree.git and media_build.git repositories, and received errors for both. The media_tree repository failed on the first line git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v4l-dvb which I'm assuming is because kernel.org is down. The media_build.git repository fails on the first line also git clone git://linuxtv.org/media_build.git with a fatal: read error: Connection reset by peer. The linux tree is at: https://github.com/torvalds/linux git clone git://github.com/torvalds/linux.git The Mauro's media tree is at: http://git.linuxtv.org/mchehab/media-next.git -- 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] Fix to qt1010 tuner frequency selection (media/dvb)
I haven't gotten any feedback, and didn't see any comments on the lists (though I've checked them only occasionally), so I think you're probably right it fell between the cracks. Jyrki 25.09.2011 19:13, Carlos Corbacho kirjoitti: On Monday 22 Aug 2011 20:19:42 Jyrki Kuoppala wrote: The patch fixes frequency selection for some UHF frequencies e.g. channel 32 (562 MHz) on the qt1010 tuner. The tuner is used e.g. in the MSI Mega Sky dvb-t stick (MSI Mega Sky 55801 DVB-T USB2.0) One example of problem reports of the bug this fixes can be read at http://www.freak-search.com/de/thread/330303/linux-dvb_tuning_problem_with_s ome_frequencies_qt1010,_dvb Applies to kernel versions 2.6.38.8, 2.6.39.4, 3.0.3 and 3.1-rc2. Signed-off-by: Jyrki Kuoppalaj...@iki.fi Cc: sta...@kernel.org Tested-by: Carlos Corbachocar...@strangeworlds.co.uk This patch means I can now finally tune to all the BBC channels (which are on channel 31 (554 MHz) in my area). This should definitely go to stable, as I've also seen other similar reports for users who can't tune to various channels in the affected ranges here using qt1010. Mauro - I don't see this one in your git tree in the 3.2 branch, or in the temporary linuxtv patchwork, so I'm assuming this one fell between the cracks? -Carlos diff -upr linux-source-2.6.38.orig/drivers/media/common/tuners/qt1010.c linux-source-2.6.38/drivers/media/common/tuners/qt1010.c --- linux-source-2.6.38.orig/drivers/media/common/tuners/qt1010.c 2011-03-15 03:20:32.0 +0200 +++ linux-source-2.6.38/drivers/media/common/tuners/qt1010.c 2011-08-21 23:16:38.209580365 +0300 @@ -198,9 +198,10 @@ static int qt1010_set_params(struct dvb_ /* 22 */ if (freq 45000) rd[15].val = 0xd0; /* 450 MHz */ -else if (freq 48200) rd[15].val = 0xd1; /* 482 MHz */ +else if (freq 48200) rd[15].val = 0xd2; /* 482 MHz */ else if (freq 51400) rd[15].val = 0xd4; /* 514 MHz */ -else if (freq 54600) rd[15].val = 0xd7; /* 546 MHz */ +else if (freq 54600) rd[15].val = 0xd6; /* 546 MHz */ +else if (freq 57800) rd[15].val = 0xd8; /* 578 MHz */ else if (freq 61000) rd[15].val = 0xda; /* 610 MHz */ else rd[15].val = 0xd0; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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:Sun Sep 25 19:00:15 CEST 2011 git hash:d7222e7d6fb06ca3e7aa7a1ab07f8e6c6adb1d22 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.0-4.slh.3-amd64 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-rc1-i686: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-rc1-x86_64: ERRORS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification 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: af9015/tda18218: Multiples (separates) usb devices errors/conflicts
2011/9/24 Jin Kazama jin...@skynet.fr: On 9/24/11 12:06 AM, Antti Palosaari wrote: On 09/24/2011 12:06 AM, Jin Kazama wrote: Hello, I've been testing af9015/tda18218 based usb DVB-T tuners on a 2.6.39.4 kernel with the latest v4l drivers avaiable (from git). When I'm using a single USB module, (listed as /dev/dvb/adapter0), everything works fine. When I'm plugging another module, at first it looks like everything's ok (/dev/dvb/adapter1) and if I try to use this module while the adapter0 is not been used, it works - but if try to use both modules at the same time, I get garbage output on both cards (error: warning: discontinuity for PID... with dvblast on both cards. Does anyone have any idea on how to fix this problem? Feel free to fix it. I am too busy currently. Well, it looks like if I put 2 devices on different USB buses (on the same machine), they work fine, but if they're on the same USB bus, I get the problem... I think the driver may get raw data from the USB bus - and the way it identifies the device is not the proper way (I have 2 exactly identical devices) = when both devices send data, the driver catches all the data from the bus, which is a corrupt mix of both streams...) Unfortunately, I don't think that I'm capable of fixing the problem by myself, I don't even know which part of the driver to look for... if someone can give me a hint, I might *try* to *attempt* to fix 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 Hello, I have similar problem, I have a dual tuner and they don't work together: # i2cdetect -l i2c-0 smbus SMBus nForce2 adapter at 4d00 SMBus adapter i2c-1 i2c cx23885[0] I2C adapter i2c-2 i2c cx23885[0] I2C adapter i2c-3 i2c cx23885[0] I2C adapter i2c-4 i2c NVIDIA i2c adapter 0 at 3:00.0 I2C adapter i2c-5 i2c NVIDIA i2c adapter 2 at 3:00.0 I2C adapter i2c-6 i2c NVIDIA i2c adapter 3 at 3:00.0 I2C adapter i2c-7 i2c KWorld PlusTV Dual DVB-T Stick (DVB-T 399U) I2C adapter i2c-8 i2c KWorld PlusTV Dual DVB-T Stick (DVB-T 399U) I2C adapter I can not change the USB bus, because they are on the same physical device.I have no idea how to fix it but I am ready to test all fixes. I read some Antti posts on how to is designed the af9015 dual demod: http://www.mail-archive.com/linux-media@vger.kernel.org/msg36821.html http://palosaari.fi/linux/v4l-dvb/controlling_tuner_af9015_dual_demod.txt Is there any tool to check the i2c errors? Thanks for all your work and best regards. -- Josu Lazkano -- 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] EM28xx - fix deadlock when unplugging and replugging a DVB adapter
Em 25-09-2011 10:32, Chris Rankin escreveu:
On 25/09/11 14:00, Mauro Carvalho Chehab wrote:
Hmm... This would probably work better (not tested). Could you please test it
on your hardware?
Hmm, I don't understand this.
The deadlock isn't about taking em28xx_devlist_mutex, but happens because
em28xx_dvb_init() tries to retake dev-lock when em28xx_usb_probe() is
already holding it. That's why I unlocked dev-lock before calling
em28xx_init_extension().
So why are you avoiding locking em28xx_devlist_mutex?
Yeah, I realized it just after sending it. I didn't have time to re-post another
email, as I was about to leave.
I'm still not comfortable on releasing the mutex too early, as this may cause
driver
hungup, due to udev early access. I'll try to do some tests with it here, and
think on
a better solution.
Cheers,
Chris
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index 7297d90..c92c177 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -3005,7 +3005,8 @@ static int em28xx_init_dev(struct em28xx **devhandle,
struct usb_device *udev,
goto fail;
}
-em28xx_init_extension(dev);
+/* dev-lock needs to be holded */
+__em28xx_init_extension(dev);
/* Save some power by putting tuner to sleep */
v4l2_device_call_all(dev-v4l2_dev, 0, core, s_power, 0);
@@ -3301,10 +3302,10 @@ static void em28xx_usb_disconnect(struct
usb_interface *interface)
em28xx_release_resources(dev);
}
-em28xx_close_extension(dev);
-
mutex_unlock(dev-lock);
+em28xx_close_extension(dev);
+
if (!dev-users) {
kfree(dev-alt_max_pkt_size);
kfree(dev);
diff --git a/drivers/media/video/em28xx/em28xx-core.c
b/drivers/media/video/em28xx/em28xx-core.c
index 804a4ab..afddfea 100644
--- a/drivers/media/video/em28xx/em28xx-core.c
+++ b/drivers/media/video/em28xx/em28xx-core.c
@@ -1218,16 +1218,22 @@ void em28xx_unregister_extension(struct em28xx_ops
*ops)
}
EXPORT_SYMBOL(em28xx_unregister_extension);
-void em28xx_init_extension(struct em28xx *dev)
+/* Need to take the mutex lock before calling it */
+void __em28xx_init_extension(struct em28xx *dev)
{
const struct em28xx_ops *ops = NULL;
-mutex_lock(em28xx_devlist_mutex);
list_add_tail(dev-devlist,em28xx_devlist);
list_for_each_entry(ops,em28xx_extension_devlist, next) {
if (ops-init)
ops-init(dev);
}
+}
+
+void em28xx_init_extension(struct em28xx *dev)
+{
+mutex_lock(em28xx_devlist_mutex);
+__em28xx_init_extension(dev);
mutex_unlock(em28xx_devlist_mutex);
}
diff --git a/drivers/media/video/em28xx/em28xx.h
b/drivers/media/video/em28xx/em28xx.h
index 1626e4a..a5c1ba2 100644
--- a/drivers/media/video/em28xx/em28xx.h
+++ b/drivers/media/video/em28xx/em28xx.h
@@ -682,6 +682,7 @@ void em28xx_remove_from_devlist(struct em28xx *dev);
void em28xx_add_into_devlist(struct em28xx *dev);
int em28xx_register_extension(struct em28xx_ops *dev);
void em28xx_unregister_extension(struct em28xx_ops *dev);
+void __em28xx_init_extension(struct em28xx *dev);
void em28xx_init_extension(struct em28xx *dev);
void em28xx_close_extension(struct em28xx *dev);
--
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] EM28xx - fix deadlock when unplugging and replugging a DVB adapter
Em 25-09-2011 16:28, Chris Rankin escreveu: --- On Sun, 25/9/11, Mauro Carvalho Chehab mche...@redhat.com wrote: Ok, I've applied it, but it doesn't sound a good idea to me to do: +mutex_unlock(dev-lock); em28xx_init_extension(dev); +mutex_lock(dev-lock); Yes, I suppose it's the logical equivalent of moving the em28xx_init_extension(dev) call from em28xx_init_dev(), and placing it immediately after the final mutex_unlock(dev-lock) call in em28xx_usb_probe() instead. Which would be cleaner, quite frankly. Which stage of the v4l2 initialisation triggers the race with udev? v4l2_device_register()? Yes. Just after creating a device, udev tries to access it. This bug is more sensitive on multi-CPU machines, as udev may run on another CPU. Cheers, Chris -- 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: Status of the patches under review at LMML (28 patches)
Hi Mauro,
On Sat, Sep 24, 2011 at 05:34, Mauro Carvalho Chehab mche...@redhat.com wrote:
Everything at patchwork were reviewed by me, and I've applied all patches
that I didn't notice any review by the drivers maintainers.
Driver maintainers:
Please review the remaining patches.
(...)
== Waiting for Pawel Osiak pa...@osciak.com review ==
Jul,12 2011: v4l: mem2mem: add wait_{prepare,finish} ops to m2m_testdev
http://patchwork.linuxtv.org/patch/7431 Michael Olbrich
m.olbr...@pengutronix.de
This is an ack from me.
--
Best regards,
Pawel Osciak
--
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] EM28xx - replug locking cleanup
Mauro, This patch simplifies the locking by moving the em28xx_init_extension() call until em28xx_usb_probe() has finished with the dev-lock mutex. It therefore makes the second and subsequent plugging events logically identical to the first plugging event when the em28xx-dvb and em28xx-alsa modules must be loaded (i.e. registered). Basically, em28xx_usb_probe() requests that em28xx-dvb be loaded and also triggers udev to initialise the V4L2 devices. These two events are serialised by the dev-lock mutex but the order that they happen in is undefined. But this has always been the case anyway. Signed-off-by: Chris Rankin ranki...@yahoo.com Cheers, Chris --- linux/drivers/media/video/em28xx/em28xx-cards.c.orig 2011-09-25 22:51:59.0 +0100 +++ linux/drivers/media/video/em28xx/em28xx-cards.c 2011-09-25 23:24:06.0 +0100 @@ -3005,10 +3005,6 @@ goto fail; } - mutex_unlock(dev-lock); - em28xx_init_extension(dev); - mutex_lock(dev-lock); - /* Save some power by putting tuner to sleep */ v4l2_device_call_all(dev-v4l2_dev, 0, core, s_power, 0); @@ -3243,6 +3239,13 @@ */ mutex_unlock(dev-lock); + /* + * These extensions can be modules. If the modules are already + * loaded then we can initialise the device now, otherwise we + * will initialise it when the modules load instead. + */ + em28xx_init_extension(dev); + return 0; err:
Re: Problems cloning the git repostories
Em 25-09-2011 15:03, Johannes Stezenbach escreveu: On Sun, Sep 25, 2011 at 07:33:57AM -0500, Patrick Dickey wrote: I tried to follow the steps for cloning both the media_tree.git and media_build.git repositories, and received errors for both. The media_tree repository failed on the first line git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v4l-dvb which I'm assuming is because kernel.org is down. The media_build.git repository fails on the first line also git clone git://linuxtv.org/media_build.git with a fatal: read error: Connection reset by peer. The git error should be fixed now. But please don't clone from linuxtv.org, intead use git clone git://github.com/torvalds/linux.git and then add linuxtv to your repo like described on http://git.linuxtv.org/media_tree.git I've updated the instructions together with the git tree to point to the github tree. Btw, the media_build had an issue due to the move of tm6000 and altera-stapl out of staging. I've fixed it. At least here with 3.0 kernel, everything is compiling fine. Cheers, Mauro Johannes -- 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 -- 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: Problems cloning the git repostories
Em 25-09-2011 10:55, Devin Heitmueller escreveu: On Sun, Sep 25, 2011 at 8:33 AM, Patrick Dickey pdickeyb...@gmail.com wrote: Hello there, I tried to follow the steps for cloning both the media_tree.git and media_build.git repositories, and received errors for both. The media_tree repository failed on the first line git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git v4l-dvb which I'm assuming is because kernel.org is down. The media_build.git repository fails on the first line also git clone git://linuxtv.org/media_build.git with a fatal: read error: Connection reset by peer. Is it possible to clone either (or both) repositories at this time, or are they down? And in the absence of cloning the kernel for the media_tree.git repository, is it possible to simply clone the git://linuxtv.org/media_tree.git repository and work from that? My interest in this is to install some patches created by Devin Heitmueller for the Pinnacle PCTV 80e USB tuner (at least the ATSC portion of the tuner). Once I'm able to determine exactly what changes are made, I would like to either submit the patches to the repository, or send them to someone who has more experience in patching the files for submission. One other question (totally unrelated to this post though): When I send emails, normally they are GPG signed. Should I disable that for this list, or is it acceptable? Thank you for any information, and have a great day:) Patrick. Hi Patrick, As I said on the blog, the issue isn't getting the driver to work against current kernels. Merging the driver against the current tree is a trivial exercise (the patch series should apply trivially against the current code, with only a few minor conflicts related to board numbers, etc). The bigger issue though is once you do that and have the driver running, you now have a body of code 10,000 lines which doesn't meet the coding standards. Doing such a refactoring is a relatively straightforward exercise but very time consuming (you already have a working driver, so you just have to make sure you don't break anything). The more I think about this, the more it annoys me. I did all the hard parts: * I worked with the product vendor to get the details for the design * I got Hauppauge/PCTV to compel the chipset vendor to release the reference code under a GPL compatible license * I worked out redistribution terms on the firmware * I ported the driver to Linux * I integrated the driver and debugged it to achieve signal lock And why is it not in the mainline? Because none of the above matters if I didn't waste a bunch of my time removing a bunch of #ifdef WINDOWS lines and converting whitespace from tabs to spaces. It's crap like this that's the reason why some of the best LinuxTV driver authors still have a bunch of stuff that isn't merged upstream. We just don't have time for this sort of bullshit that any monkey could do if he/she was willing to invest the effort. We're just too busy doing *actual* driver work. Five years ago the hard part was finding competent developers, getting access to datasheets, getting access to reference driver code, and getting access to the details for a hardware design. Now most of those problems are not the issue - we have access to all the data but we want to waste the time of the few competent developers out there making them do coding style cleanup before perfectly good code gets merged upstream. There has been more than one case where I've considered doing a driver for a new board and decided against it because the barrier to getting it upstream is not worth my time. I fail to see any trial from your side to send the patches upstream: no pull requests and no patches for this driver were _ever_ sent to the ML. I can only guess that maybe submitting it upstream were not part of your contract with the vendor. Coding Style fixes are generally trivial, and they can be done very quickly with some scripting. I took only a few hours to convert drx-d and drx-k to the Linux Coding Style, on my spare time. The scripts I wrote for that are together with the commits (they're generally a few lines perl scripting doing some replacements). I usually do this with other drivers, when people submit me them with those troubles and I have some time, and never asked or earned a single penny for doing that. Also, as I've told you several times before, code with broken coding styles can be submitted as-is, without any changes to drivers/staging, where they're fixed by kernel newbies with more time to work on that. So, please don't use weak arguments like that as an excuse for you to not submit your drivers. Want to see more device support upstream? Optimize the process to make it easy for the people who know the hardware and how to write the drivers to get code upstream, and leave it to the janitors to work out the codingstyle issues. The
Re: [PATCH 2/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr
Hi, On Wednesday 21 September 2011 04:15 PM, Taneja, Archit wrote: Hi, On Wednesday 21 September 2011 03:35 PM, Hiremath, Vaibhav wrote: -Original Message- From: Taneja, Archit Sent: Friday, September 16, 2011 3:31 PM To: Hiremath, Vaibhav Cc: Valkeinen, Tomi; linux-o...@vger.kernel.org; Semwal, Sumit; linux- me...@vger.kernel.org; Taneja, Archit Subject: [PATCH 2/5] [media]: OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr Currently, there is a lot of redundant code is between DPI and VENC panels, this can be made common by moving out field/interlace specific code to a separate function called omapvid_handle_interlace_display(). There is no functional change made. Signed-off-by: Archit Tanejaarc...@ti.com --- drivers/media/video/omap/omap_vout.c | 172 - - [Hiremath, Vaibhav] Have you tested TV out functionality? I haven't checked it yet to be totally honest. Its hard to find a VENC TV! I wanted to anyway get some kind of Ack from you before starting to test this. Since you also feel that this clean up is needed, I'll start testing this out :) I tested the TV out functionality. It works fine. I have left the extra fid == 0 check so that the code is more clear. Will post out the new patch soon. Archit -- 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
