MyGica T119 (siano sms) ir sensor is not recognized
Hello, I have an usb MyGica T119 using the firmware dvb_nova_12mhz_b0.inp and modules smsdvb and smsmdtv from Siano. The IR is not being detected. I have googled and looked in this email, I have only found some old patches but I could not find a solution. Is there any way to make it recognized? dmesg shows this when the device is plugged: [18359.699863] sms_ir_exit: [18373.290788] usb 2-2: new high-speed USB device number 4 using ehci_hcd [18373.986598] smscore_set_device_mode: firmware download success: dvb_nova_12mhz_b0.inp [18373.989903] DVB: registering new adapter (Siano Nova B Digital Receiver) [18373.990269] DVB: registering adapter 0 frontend 0 (Siano Mobile Digital MDTV Receiver)... lsmod | grep sms smsusb 13808 0 smsdvb 18536 0 dvb_core 110619 1 smsdvb smsmdtv37242 2 smsusb,smsdvb rc_core26412 8 ir_lirc_codec,ir_mce_kbd_decoder,ir_sony_decoder,ir_jvc_decoder,ir_rc6_decoder,ir_rc5_decoder,ir_nec_decoder,smsmdtv lsmod | grep irda irda 201324 0 crc_ccitt 12667 1 irda grep FIR /sys/bus/acpi/devices/*/path No result lsusb Bus 002 Device 004: ID 187f:0201 Siano Mobile Silicon Nova B Any help would be much appreciated. Thanks in advance. -- 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: mt9t031 driver support on OMAP3 system
Hi Pete On Sat, 22 Sep 2012, P Jackson wrote: > I'm trying to incorporate an MT9T031-based sensor into a commercial > small form-factor OMAP3 DM3730-based system which is supplied with > sources for a 2.6.37 kernel and is somewhat out-dated.The application > I'm working on requires a single image to be acquired from the sensor > every once in a while which is then processed off-line by another > algorithm on the OMAP3 > > I'd appreciate any advice from the list as to what the most suitable up > to-date compatible kernel I should use would be and what other work I > need to do in order to get things sorted. I would certainly advise to use a current kernel (e.g., 3.5). As for "how," I know, that Laurent has worked on a similar tasks, you can find his posts in mailing list archives, or maybe he'll be able to advise you more specifically. > Thanks, Pete Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.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
Re: [RFC] Timestamps and V4L2
On Sat, Sep 22, 2012 at 07:12:52PM +0200, Sylwester Nawrocki wrote: > If we ever need the clock selection API I would vote for an IOCTL. > The controls API is a bad choice for something such fundamental as > type of clock for buffer timestamping IMHO. Let's stop making the > controls API a dumping ground for almost everything in V4L2! ;) > Perhaps VIDIOC_QUERYBUF and VIDIOC_DQBUF should be reporting > timestamps type only for the time they are being called. Not per buffer, > per device. And applications would be checking the flags any time they > want to find out what is the buffer timestamp type. Or every time if it > don't have full control over the device (S/G_PRIORITY). I'm all for adding an IOCTL, but if we think about adding a VIDIOC_S_TIMESTAMP_TYPE in the future, we might as well add a VIDIOC_G_TIMESTAMP_TYPE right now. Old drivers will return ENOSYS, so the application knows it will have to guess the type (or take own timestamps). I can't imagine anything useful coming from an app that has to process timestamps that change their source every now and then and I seriously doubt anyone will go to such an extent that they check the timestamp type on every buffer. If they don't set their priority high enough to prevent others from changing the timestamp type, they also run the risk of someone else changing the image format. It should be enough to forbid changing the timestamp type while I/O is in progress, as it is done for VIDIOC_S_FMT. Daniel -- 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:Sat Sep 22 19:00:20 CEST 2012 git hash:4313902ebe33155209472215c62d2f29d117be29 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: ERRORS linux-git-x86_64: WARNINGS 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: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-rc2-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: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-rc2-i686: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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: RFC: single+multiplanar API in one driver: possible or not?
Hello Hans, On 09/21/2012 01:07 PM, Hans Verkuil wrote: > Hi all, > > I've been looking into multiplanar support recently, and I ran into some API > ambiguities. > > In the examples below I stick to the capture case, but the same applies to > output and m2m. > > There are two capabilities: V4L2_CAP_VIDEO_CAPTURE and > V4L2_CAP_VIDEO_CAPTURE_MPLANE. > These caps tell the application whether the single and/or multiplanar API is > implemented by the driver. > > If the hardware only supports single planar formats, then only > V4L2_CAP_VIDEO_CAPTURE > is present. If the hardware only supports multiplanar formats, then only > V4L2_CAP_VIDEO_CAPTURE_MPLANE is present. The problems occurs when the > hardware > supports both single and multiplanar formats. > > The first question is if we want to allow drivers to implement both. The > advantages of that are: > > - easy to implement: if the hardware supports one or more multiplanar formats, >then the driver must implement only the multiplanar API. Applications will >only see V4L2_CAP_VIDEO_CAPTURE or V4L2_CAP_VIDEO_CAPTURE_MPLANE and never >both. > - no confusion: what should be done if a multiplanar format is set up >and an application asks for the current single planar format? Return a >fake format? Some error? This is currently undefined. > > The disadvantages are: > > - it won't work with most/all existing applications since they only understand >single planar at the moment. However, all multiplanar drivers are for > Samsung >embedded SoCs, so is this a real problem? Probably not a big deal. To support standard applications the conversions can be done in libv4l2. But I must admit that the original idea was to have the conversion done in kernel and this problem would not exist. Sounds like we need to get the related libv4l2 work done to solve this issue. > If we would want to allow mixing the two, then we need to solve two problems: > > - Determine the behavior when calling G_FMT for a single planar buffer type >when the current format is a multiplanar format. > - We probably want to make a bunch of helper functions that do the job of >handling the single planar case without requiring the driver to actually >implement both. > > The first is actually a major problem. Returning an error here is completely > unexpected behavior. The only reasonable solution I see is to remember the > last > single planar format and return that. But then G_FMT for a single or a > multiplanar > format will return different things. > > The second problem is also difficult, in particular when dealing with the > streaming I/O ioctls. It's doable, but a fair amount of work. This has been done in the past, the single/multi-plane conversion code is included in that patch for instance: http://www.mail-archive.com/linux-media@vger.kernel.org/msg25994.html But it was decided to do the conversion only in libv4l2. > A conversion from multiplanar to singleplanar might be something that can be > done in libv4l2. But that too is a substantial amount of work. Some works on that were started already http://www.mail-archive.com/linux-media@vger.kernel.org/msg34078.html > I am inclined to disallow mixing of single and multiplanar APIs in a driver. > Let's keep things simple. Mixing those APIs in single driver doesn't make much sense. Multi-planar was supposed to be a superset of single-planar. I'm just not sure about all these in tree drivers that were added before multi-planar API existed and which could take an advantage of it as well. -- Regards, Sylwester -- 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
mt9t031 driver support on OMAP3 system
I'm trying to incorporate an MT9T031-based sensor into a commercial small form-factor OMAP3 DM3730-based system which is supplied with sources for a 2.6.37 kernel and is somewhat out-dated.The application I'm working on requires a single image to be acquired from the sensor every once in a while which is then processed off-line by another algorithm on the OMAP3 I'd appreciate any advice from the list as to what the most suitable up to-date compatible kernel I should use would be and what other work I need to do in order to get things sorted. Thanks, Pete -- 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: tda18271 driver power consumption
On 09/20/2012 08:49 PM, Michael Krufky wrote: On Thu, Sep 20, 2012 at 1:47 PM, Michael Krufky wrote: On Mon, Aug 6, 2012 at 3:13 PM, Antti Palosaari wrote: On 08/06/2012 09:57 PM, Michael Krufky wrote: On Mon, Aug 6, 2012 at 2:35 PM, Devin Heitmueller wrote: On Mon, Aug 6, 2012 at 2:19 PM, Antti Palosaari wrote: You should understand from DVB driver model: * attach() called only once when driver is loaded * init() called to wake-up device * sleep() called to sleep device What I would like to say is that there is very big risk to shoot own leg when doing some initialization on attach(). For example resuming from the suspend could cause device reset and if you rely some settings that are done during attach() you will likely fail as Kernel / USB-host controller has reset your device. See reset_resume from Kernel documentation: Documentation/usb/power-management.txt Be forewarned: there is a very high likelihood that this patch will cause regressions on hybrid devices due to known race conditions related to dvb_frontend sleeping the tuner asynchronously on close. This is a hybrid tuner, and unless code is specifically added to the bridge or tuner driver, going from digital to analog mode too quickly will cause the tuner to be shutdown while it's actively in analog mode. (I discovered this the hard way when working on problems MythTV users reported against the HVR-950q). Description of race: 1. User opens DVB frontend tunes 2. User closes DVB frontend 3. User *immediately* opens V4L device using same tuner 4. User performs tuning request for analog 5. DVB frontend issues sleep() call to tuner, causing analog tuning to fail. This class of problem isn't seen on DVB only devices or those that have dedicated digital tuners not shared for analog usage. And in some cases it isn't noticed because a delay between closing the DVB device and opening the analog devices causes the sleep() call to happen before the analog tune (in which case you don't hit the race). I'm certainly not against improved power management, but it will require the race conditions to be fixed first in order to avoid regressions. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com Devin's right. I'm sorry, please *don't* merge the patch, Mauro. Antti, you should just call sleep from your driver after attach(), as I had previously suggested. We can revisit this some time in the future after we can be sure that these race conditions wont occur. OK, maybe it is safer then. I have no any hybrid hardware to test... Anyhow, I wonder how many years it will take to resolve that V4L2/DVB API hybrid usage pŕoblem. I ran thinking that recently when looked how to implement DVB SDR for V4L2 API... I could guess problem will not disappear near future even analog TV disappears, because there is surely coming new nasty features which spreads over both V4L2 and DVB APIs. Guys, Please take another look at this branch and test if possible -- I pushed an additional patch that takes Devin's concerns into account. After applying these patches, the tda18271 driver will behave as it always has, but it will sleep the tuner after attaching the first instance. If there is only one instance, then this works exactly as Antti desires. If there are more instances, then the tuner will only be woken up again during attach if the tda18271_need_cal_on_startup() returns non-zero. The driver does not attempt to re-sleep the hardware again during successive attach() calls. I have not tested this yet myself, but I believe it resolves the matter -- please comment. Regards, Mike Krufky ...in case the URL got lost: The following changes since commit 0c7d5a6da75caecc677be1fda207b7578936770d: Linux 3.5-rc5 (2012-07-03 22:57:41 +0300) are available in the git repository at: git://linuxtv.org/mkrufky/tuners tda18271 for you to fetch changes up to 4e46c5d1bbb920165fecfe7de18b2c01d9787230: tda18271: make 'low-power standby mode after attach' multi-instance safe (2012-09-20 13:34:29 -0400) Michael Krufky (2): tda18271: enter low-power standby mode at the end of tda18271_attach() tda18271: make 'low-power standby mode after attach' multi-instance safe drivers/media/common/tuners/tda18271-fe.c |4 1 file changed, 4 insertions(+) Best regards, Mike Tested-by: Antti Palosaari Tested with PCTV 290e, but I cannot test multi-instance. I tried to plug PCTV 520e as a second stick, but it crashed as there is now that DRX-K firmware download problem regards Antti -- http://palosaari.fi/ -- 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] Timestamps and V4L2
On 09/22/2012 02:38 PM, Sakari Ailus wrote: >> You are missing one other option: >> >> Using v4l2_buffer flags to report the clock >> --- >> >> By defining flags like this: >> >> V4L2_BUF_FLAG_CLOCK_MASK 0x7000 >> /* Possible Clocks */ >> V4L2_BUF_FLAG_CLOCK_UNKNOWN 0x /* system or monotonic, we don't >> know */ >> V4L2_BUF_FLAG_CLOCK_MONOTONIC 0x1000 >> >> you could tell the application which clock is used. >> >> This does allow for more clocks to be added in the future and clock >> selection >> would then be done by a control or possibly an ioctl. For now there >> are no >> plans to do such things, so this flag should be sufficient. And it can be >> implemented very efficiently. It works with existing drivers as well, >> since >> they will report CLOCK_UNKNOWN. >> >> I am very much in favor of this approach. +1 I think I like this idea best, it's relatively simple (even with adding support for reporting flags in VIDIOC_QUERYBUF) for the purpose. If we ever need the clock selection API I would vote for an IOCTL. The controls API is a bad choice for something such fundamental as type of clock for buffer timestamping IMHO. Let's stop making the controls API a dumping ground for almost everything in V4L2! ;) > Thanks for adding this. I knew I was forgetting something but didn't > remember what --- I swear it was unintentional! :-) > > If we'd add more clocks without providing an ability to choose the clock > from the user space, how would the clock be selected? It certainly isn't > the driver's job, nor I think it should be system-specific either > (platform data on embedded systems). > > It's up to the application and its needs. That would suggest we should > always provide monotonic timestamps to applications (besides a potential > driver-specific timestamp), and for that purpose the capability flag --- > I admit I disliked the idea at first --- is enough. > > What comes to buffer flags, the application would also have to receive > the first buffer from the device to even know what kind of timestamps > the device uses, or at least call QUERYBUF. And in principle the flag > should be checked on every buffer, unless we also specify the flag is > the same for all buffers. And at certain point this will stop to make > any sense... Good point. Perhaps VIDIOC_QUERYBUF and VIDIOC_DQBUF should be reporting timestamps type only for the time they are being called. Not per buffer, per device. And applications would be checking the flags any time they want to find out what is the buffer timestamp type. Or every time if it don't have full control over the device (S/G_PRIORITY). > A capability flag is cleaner solution from this perspective, and it can > be amended by a control (or an ioctl) later on: the flag can be > disregarded by applications whenever the control is present. If the > application doesn't know about the control it can still rely on the > flag. (I think this would be less clean than to go for the control right > from the beginning, but better IMO.) But with the capability flag we would only be able to report one type of clock, right ? >>> Device-dependent timestamp >>> -- >>> >>> Should we agree on selectable timestamps, the existing timestamp >>> field (or a >>> union with another field of different type) could be used for the >>> device-dependent timestamps. >> >> No. Device timestamps should get their own field. You want to be able >> to relate >> device timestamps with the monotonic timestamps, so you need both. >> >>> Alternatively we can choose to re-use the >>> existing timecode field. >>> >>> At the moment there's no known use case for passing device-dependent >>> timestamps at the same time with monotonic timestamps. >> >> Well, the use case is there, but there is no driver support. The device >> timestamps should be 64 bits to accomodate things like PTS and DTS from >> MPEG streams. Since timecode is 128 bits we might want to use two u64 >> fields >> or perhaps 4 u32 fields. > > That should be an union for different kinds (or rather types) of > device-dependent timestamps. On uvcvideo I think this is u32, not u64. > We should be also able to tell what kind device dependent timestamp > there is --- should buffer flags be used for that as well? Timecode has 'type' and 'flags' fields, couldn't it be accommodated for reporting device-dependant timestamps as well ? -- Regards, Sylwester -- 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 1/5] fc2580: small improvements for chip id check
* better readability
* make checkpatch.pl happy
* few bytes smaller binary footprint
Cc: Oliver Schinagl
Signed-off-by: Antti Palosaari
---
drivers/media/tuners/fc2580.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
index 51bc39c..7db32ec 100644
--- a/drivers/media/tuners/fc2580.c
+++ b/drivers/media/tuners/fc2580.c
@@ -498,7 +498,11 @@ struct dvb_frontend *fc2580_attach(struct dvb_frontend *fe,
dev_dbg(&priv->i2c->dev, "%s: chip_id=%02x\n", __func__, chip_id);
- if ((chip_id != 0x56) && (chip_id != 0x5a)) {
+ switch (chip_id) {
+ case 0x56:
+ case 0x5a:
+ break;
+ default:
goto err;
}
--
1.7.11.4
--
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 2/5] dvb_usb_v2: fix error handling for .tuner_attach()
fe was not set NULL after it was destroyed in tuner attach fail
error case. Due to that it was destroyed again and Kernel oopsed.
Reported-by: Oliver Schinagl
Signed-off-by: Antti Palosaari
---
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
index f990159..9859d2a 100644
--- a/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
+++ b/drivers/media/usb/dvb-usb-v2/dvb_usb_core.c
@@ -612,8 +612,10 @@ err_dvb_unregister_frontend:
err_dvb_frontend_detach:
for (i = MAX_NO_OF_FE_PER_ADAP - 1; i >= 0; i--) {
- if (adap->fe[i])
+ if (adap->fe[i]) {
dvb_frontend_detach(adap->fe[i]);
+ adap->fe[i] = NULL;
+ }
}
err:
--
1.7.11.4
--
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 3/5] fc2580: fix crash when attach fails
Callbacks were set even attach failed. This leads calling .release() in error case and resulted crash. Reported-by: Oliver Schinagl Signed-off-by: Antti Palosaari --- drivers/media/tuners/fc2580.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c index 7db32ec..ec7965d 100644 --- a/drivers/media/tuners/fc2580.c +++ b/drivers/media/tuners/fc2580.c @@ -487,9 +487,6 @@ struct dvb_frontend *fc2580_attach(struct dvb_frontend *fe, priv->cfg = cfg; priv->i2c = i2c; - fe->tuner_priv = priv; - memcpy(&fe->ops.tuner_ops, &fc2580_tuner_ops, - sizeof(struct dvb_tuner_ops)); /* check if the tuner is there */ ret = fc2580_rd_reg(priv, 0x01, &chip_id); @@ -510,6 +507,10 @@ struct dvb_frontend *fc2580_attach(struct dvb_frontend *fe, "%s: FCI FC2580 successfully identified\n", KBUILD_MODNAME); + fe->tuner_priv = priv; + memcpy(&fe->ops.tuner_ops, &fc2580_tuner_ops, + sizeof(struct dvb_tuner_ops)); + if (fe->ops.i2c_gate_ctrl) fe->ops.i2c_gate_ctrl(fe, 0); -- 1.7.11.4 -- 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 5/5] anysee: do not remove CI when it is not attached
Signed-off-by: Antti Palosaari
---
drivers/media/usb/dvb-usb-v2/anysee.c | 8
drivers/media/usb/dvb-usb-v2/anysee.h | 1 +
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/anysee.c
b/drivers/media/usb/dvb-usb-v2/anysee.c
index 6705d81..ec540140 100644
--- a/drivers/media/usb/dvb-usb-v2/anysee.c
+++ b/drivers/media/usb/dvb-usb-v2/anysee.c
@@ -1217,6 +1217,8 @@ static int anysee_ci_init(struct dvb_usb_device *d)
if (ret)
return ret;
+ state->ci_attached = true;
+
return 0;
}
@@ -1225,7 +1227,7 @@ static void anysee_ci_release(struct dvb_usb_device *d)
struct anysee_state *state = d_to_priv(d);
/* detach CI */
- if (state->has_ci)
+ if (state->ci_attached)
dvb_ca_en50221_release(&state->ci);
return;
@@ -1257,10 +1259,8 @@ static int anysee_init(struct dvb_usb_device *d)
/* attach CI */
if (state->has_ci) {
ret = anysee_ci_init(d);
- if (ret) {
- state->has_ci = false;
+ if (ret)
return ret;
- }
}
return 0;
diff --git a/drivers/media/usb/dvb-usb-v2/anysee.h
b/drivers/media/usb/dvb-usb-v2/anysee.h
index 4ab4676..c1a4273 100644
--- a/drivers/media/usb/dvb-usb-v2/anysee.h
+++ b/drivers/media/usb/dvb-usb-v2/anysee.h
@@ -56,6 +56,7 @@ struct anysee_state {
u8 seq;
u8 fe_id:1; /* frondend ID */
u8 has_ci:1;
+ u8 ci_attached:1;
struct dvb_ca_en50221 ci;
unsigned long ci_cam_ready; /* jiffies */
};
--
1.7.11.4
--
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 4/5] e4000: fix crash when attach fails
Callbacks were set even attach failed. This leads calling .release() in error case and resulted crash. Reported-by: Oliver Schinagl Signed-off-by: Antti Palosaari --- drivers/media/tuners/e4000.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c index ffaa482..1b33ed3 100644 --- a/drivers/media/tuners/e4000.c +++ b/drivers/media/tuners/e4000.c @@ -366,9 +366,6 @@ struct dvb_frontend *e4000_attach(struct dvb_frontend *fe, priv->cfg = cfg; priv->i2c = i2c; - fe->tuner_priv = priv; - memcpy(&fe->ops.tuner_ops, &e4000_tuner_ops, - sizeof(struct dvb_tuner_ops)); /* check if the tuner is there */ ret = e4000_rd_reg(priv, 0x02, &chip_id); @@ -389,6 +386,10 @@ struct dvb_frontend *e4000_attach(struct dvb_frontend *fe, "%s: Elonics E4000 successfully identified\n", KBUILD_MODNAME); + fe->tuner_priv = priv; + memcpy(&fe->ops.tuner_ops, &e4000_tuner_ops, + sizeof(struct dvb_tuner_ops)); + if (fe->ops.i2c_gate_ctrl) fe->ops.i2c_gate_ctrl(fe, 0); -- 1.7.11.4 -- 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: s5p-tv/mixer_video.c weirdness
Hi Hans, On 09/21/2012 12:07 PM, Hans Verkuil wrote: > Hi Marek, Sylwester, > > I've been investigating how multiplanar is used in various drivers, and I > came across this driver that is a bit weird. > > querycap sets both single and multiple planar output caps: > > cap->capabilities = V4L2_CAP_STREAMING | > V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_VIDEO_OUTPUT_MPLANE; > > This suggests that both the single and multiplanar APIs are supported. Thanks for spotting this. Somehow this driver wasn't fixed at the time this issue was addressed in s5p-mfc and s5p-fimc drivers in commits: 8f401543e [media] s5p-fimc: Remove single-planar capability flags, 43defb118 [media] v4l: s5p-mfc: fix reported capabilities. The reason why these drivers were setting the both capability type flags was that original idea was to have multi/single-plane buffer related ioctls translated in the kernel. So the v4l2-core would be turning a multi-plane only driver into a single-plane capable as well. But the in kernel conversion code was stripped at last minute during merge for known reasons. Looks like the s5p-tv driver haven't been receiving enough love, probably because HDMI and TV-out support for these SoCs now happens mainly in DRM. I'll make sure there is a patch queued for 3.7, correcting those capabilities and enum_fmt. BTW, I couldn't find a justification of making multi-planar a property of fourcc, rather than of the memory/buffer, which it really is. As in this RFC [1]. Inventing multi-planar fourccs always seemed not a best idea to me.. > But mxr_ioctl_ops only implements these: > > /* format handling */ > .vidioc_enum_fmt_vid_out = mxr_enum_fmt, > .vidioc_s_fmt_vid_out_mplane = mxr_s_fmt, > .vidioc_g_fmt_vid_out_mplane = mxr_g_fmt, > > Mixing single planar enum_fmt with multiplanar s/g_fmt makes little sense. > > I suspect everything should be multiplanar. Yes, it should be all multi-planar right from the beginning. > BTW, I recommend running v4l2-compliance over your s5p drivers. I saw several > things it would fail on. I have it queued on my todo list, I'll see if it can be done for v3.8. -- Regards, Sylwester [1] http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/11212 -- 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: [RFCv2 PATCH 00/14] davinci: clean up input/output/subdev config
Hi Hans, Thanks for the patchset. On Thu, Sep 20, 2012 at 5:36 PM, Hans Verkuil wrote: > Hi Prabhakar, > > This is the second patch series for a vpif driver cleanup. > > The first version can be found here: > > http://www.mail-archive.com/linux-media@vger.kernel.org/msg52136.html > > Changes since RFCv1: > > - rebased to a newer git repo: > > http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git/shortlog/refs/heads/da850_vpif_machine > > - fixed probe() cleanup code in both display and capture that was seriously > broken. > > - fixed a broken s_routing implementation in the tvp514x driver: if there > is no incoming video signal, then s_routing would return EINVAL and > leave the driver with an inconsistent internal state. This has always > been a problem, but with this patch series it suddenly became really > noticable. s_routing shouldn't try to wait for a valid signal, that's > not what s_routing should do. > > This patch series does some driver cleanup and reorganizes the config > structs that are used to set up subdevices. > > The current driver associates an input or output with a subdev, but multiple > inputs may use the same subdev and some inputs may not use a subdev at all > (this is the case for our hardware). > > Several other things were also configured in the wrong structure. For > example the vpif_interface struct is really part of the channel config > and has nothing to do with the subdev. > Acked-by: Prabhakar Lad Tested-by: Prabhakar Lad > What is missing here is that the output doesn't have the same flexibility > as the input when it comes to configuration. It would be good if someone > can pick this up as a follow-up since it's unlikely I'll be working on > that. > Working on it. Regards, --Prabhakar Lad > What would also be nice is that by leaving the inputs or outputs for the > second channel empty (NULL) in the configuration you can disable the second > video node, e.g. trying to use it will always result in ENODEV or something. > > This patch series will at least make things more flexible. > > 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: [alsa-devel] [PATCH v2 00/34] i.MX multi-platform support
On Fri, Sep 21, 2012 at 01:26:43AM -0700, Olof Johansson wrote: > I'll take a look at merging it tomorrow after I've dealt with smp_ops; > if it looks reasonably conflict-free I'll pull it in. We need the > sound dependency sorted out (or agreed upon) first though. I guess in the light of the rest of the thread it doesn't much matter for this merge window but I just pushed: git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git tags/asoc-3.7 which is signed so can happily be merged elsewhere. -- 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: led flash driver for lm3554/lm3556
Hi Daniel and others, On Fri, Sep 21, 2012 at 03:29:18PM +, Jeong, Daniel wrote: > Hi Andy and Sakari. > > >On Fri, Sep 21, 2012 at 01:55:15PM +0300, Andy Shevchenko wrote: > >> On Fri, 2012-09-21 at 19:16 +0900, gshark wrote: > >> > >> [cut previous stories] > >> > >> > My development enviroments are Unbuntu and Android on Exynos and > >> > OMAP4 Processor. > >> > There is a function "Assistive Light" in the Android mobile phone > >> > and it turns on/off the Torch regardless Camera. It is controlled by SW. > >> > And the indicator function in LM3554/6 can be controlled by SW. One > >> > of our customers controls the indicator using SW. > >> Fortunately our driver is dedicated for Android as well. > >> > >> > I didn't know you did create the as3645a driver. > >> > But TI has similar products such as LM3554, 3555, 3556, 3559.. I > >> > think we don't need to create drivers for each product. > >> > Now I'm doing put these products into one driver file. (lm355x.c ) > >> Actually accordingly to the specs lm3554 and lm3555 is quite different > >> by hw configuration. It's better to keep them separate from my p.o.v. > > > >I agree with that. These chis are so simple it's easy to complicate the > >matter by trying to fit everything into the same driver. It'd be different > >if some of them would be just super or subsets of another chip. > > Is it really quite different? >Input pins > --- > SCL/SDA STROBE TORCHHWENTX > > LM3554 O O O O O > LM3555 O O O O X > LM3556 O O O O O > LM3559 O O O O O > > Output pins > - > LED(1) LED2 LEDI/NTC > > LM3554 O O O > LM3555 O X X > LM3556 O X X > LM3559 O O O > > >Operation Mode(ENABLE) bits size > > LM3554 2bits > LM3555 2bits > LM3556 2bits > LM3559 2bits > >Torch Current Control bits size > > LM3554 3bits > LM3555 3bits > LM3556 3bits > LM3559 3bits > >Flash Current Control bits size > > LM3554 4bits > LM3555 4bits > LM3556 4bits > LM3559 4bits > > >Indicator Current Control bits size > > LM3554 2bits > LM3555 2bits > LM3556 2bits > LM3559 3bits > > I'm sure that only register numbers are different and it can be handled in > one driver. If it's only that, then why not, but often the details have so many differences it's less work to just write a new driver instead of cluttering up the old one. That applies IMHO to e.g. LM3554 and LM3555. > >> > [cut previous stories] > >> > I agree with you that we shouldn't have multiple drivers for the same > >> > hardware. > >> > So I think the best way to avoid duplicated work is to change current > >> > lm355x file to like below. > >> > kernel > >> > ../drivers/mfd/lm355x-core.c// control i2c-accss etc.. > >> > /media/video/lm355x-flash.c // control flash and torch. > >> > /leds/leds-lm355x.c// control indicator > >> > and torch. > >> It doesn't require to split them. If you want to provide led framework > >> for that chip we could do the generic glue driver. And I would like to > >> do it. > >> > >> P.S. Any objections to go to the public mailing list with this > >> discussion? I mean linux-media@, for example. > > > >I'm all for that. What's the relevant list for the LED framework? > > > On Fri, 2012-09-21 at 15:06 +0300, Sakari Ailus wrote: > >> > P.S. Any objections to go to the public mailing list with this > >> > discussion? I mean linux-media@, for example. > >> > >> I'm all for that. What's the relevant list for the LED framework? > >linux-l...@vger.kernel.org, surprise, surprise! > > These chips are not only for Camera but also for Audio amp etc. You guys > are focusing Camera but Audio can use this chip, actually some > manufacturer's audio module uses this indicator. IMO these LED driver I can hardly see use for a LED flash controller in the ALSA API. V4L2 flash API supports flash controllers, including those with torch and indicator functionality. It's generic in the sense that it does not have hard-wired connections to cameras for instance. http://hverkuil.home.xs4all.nl/spec/media.html#flash-controls> > chips have multi-function, Flash, Torch and Indicator. Up to now > Flash(Strobe) function has been dedicated to Camera but Torch and > Indicator functions are used by the others, Audio etc. I think it is > relevant to LED framework and it sh
Re: [RFC] Timestamps and V4L2
Hi Hans,
Thanks for the comments.
Hans Verkuil wrote:
On Thu September 20 2012 22:21:22 Sakari Ailus wrote:
Hi all,
This RFC intends to summarise and further the recent discussion on
linux-media regarding the proposed changes of timestamping V4L2 buffers.
The problem
===
The V4L2 has long used realtime timestamps (such as
clock_gettime(CLOCK_REALTIME, ...)) to stamp the video buffers before
handing them over to the user. This has been found problematic in
associating the video buffers with data from other sources: realtime clock
may jump around due to daylight saving time, for example, and ALSA
(audio-video synchronisation is a common use case) user space API does not
provide the user with realtime timestamps, but instead uses monotonic time
(i.e. clock_gettime(CLOCK_MONOTONIC, ...)).
This is especially an issue in embedded systems where video recording is a
common use case. Drivers typically used in such systems have silently
switched to use monotonic timestamps. While against the spec, this is
necessary for those systems to operate properly.
In general, realtime timestamps are seen of little use in other than
debugging purposes, but monotonic timestamps are fine for that as well. It's
still possible that an application I'm not aware of uses them in a peculiar
way that would be adversely affected by changing to monotonic timestamps.
Nevertheless, we're not supposed to break the API (or ABI). It'd be also
very important for the application to know what kind of timestamps are
provided by the device.
Requirements, wishes and constraints
Now that it seems to be about the time to fix these issues, it's worth
looking a little bit to the future to anticipate the coming changes to be
able to accommodate them better later on.
- The new default should be monotonic. As the monotonic timestamps are seen
to be the most useful, they should be made the default.
- timeval vs. timespec. The two structs can be used to store timestamp
information. They are not compatible with each other. It's a little bit
uncertain what's the case with all the architectures but it looks like the
timespec fits into the space of timeval in all cases. If timespec is
considered to be used somewhere the compatibility must be ensured. Timespec
is better than timeval since timespec has more precision and it's the same
struct that's used everywhere else in the V4L2 API: timespec does not need
conversion to timespec in the user space.
struct timespec {
__kernel_time_t tv_sec; /* seconds */
longtv_nsec;/* nanoseconds */
};
struct timeval {
__kernel_time_t tv_sec; /* seconds */
__kernel_suseconds_ttv_usec;/* microseconds */
};
To be able to use timespec, the user would have to most likely explicitly
choose to do that.
- Users should know what kind of timestamps the device produces. This
includes existing and future kernels. What should be considered are
uninformed porting drivers back and forth across kernel versions and
out-of-date kernel header files.
- Device-dependent timestamps. Some devices such as the uvcvideo ones
produce device-dependent timestamps for synchronising video and audio, both
produced by the same physical hardware device. For uvcvideo these timestamps
are unsigned 32-bit integers.
- There's also another clock, Linux-specific raw monotonic clock (as in
clock_gettime(CLOCK_RAW_MONOTONIC, ...)) that could be better in some use
cases than the regular monotonic clock. The difference is that the raw
monotonic clock is free from the NTP adjustments. It would be nice for the
user to be able to choose the clock used for timestamps. This is especially
important for device-dependent timestamps: not all applications can be
expected to be able to use them.
- The field adjacent to timestamp, timecode, is 128 bits wide, and not used
by a single driver. This field could be re-used.
Possible solutions
==
Not all of the solutions below that have been proposed are mutually
exclusive. That's also what's making the choice difficult: the ultimate
solution to the issue of timestamping may involve several of these --- or
possibly something better that's not on the list.
Use of timespec
---
If we can conclude timespec will always fit into the size of timeval (or
timecode) we could use timespec instead. The solution should still make
the use of timespec explicit to the user space. This seems to conflict with
the idea of making monotonic timestamps the default: the default can't be
anything incompatible with timeval, and at the same time it's the most
important that the monotonic timestamps are timespec.
We have to keep timeval. Changing this will break the ABI. I see absolutely
no reason to use timespec for video. At 60 Hz a frame takes 16.67 ms, and that's
far, far removed from ns precisions. Should we ever have to support high-speed
cameras runn
Re: [alsa-devel] [PATCH v2 00/34] i.MX multi-platform support
On Sat, Sep 22, 2012 at 01:09:27AM -0700, Olof Johansson wrote: > > I've pulled this in now as staging/imx-multiplatform. > > > > As you mention, it might or might not make sense to send this up. It > > also accrued a few more merge conflicts with other branches in > > arm-soc, so we'll see how things play out. > > > > Either way, we'll for sure queue it for 3.8. > > Hmm. Pulling it in gives me a few new build errors, in particular on > the configs that Russell use to build test omap3, as well as one of > his vexpress configs. So I dropped it again for now. > > Let's have the current contents sit in linux-next for at least one > release before we bring in anything more, especially since it brings > in dependencies on external trees, and it also has a handful of new > merge conflicts. We're already exposing Stephen Rothwell to more merge > conflicts than I'm entirely comfortable with. > Ok. I will rebase the series against 3.7-rc1 and then send you then. Shawn -- 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: media_build error on header file not present in old linux in ivtv-alsa-pcm.c
Thanks. Ecxuse me for the previous mail. I could have searched the archive first: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/54099/match=printk+h Andy Walls wrote: > Jan Hoogenraad wrote: > >> I try to compile the media_build on an old Ubuntu Lucid system. >> 2.6.32-42-generic-pae #96-Ubuntu SMP Wed Aug 15 19:12:17 UTC 2012 i686 >> GNU/Linux >> >> The make job stops with >> >> /home/jhh/dvb/media_build/v4l/ivtv-alsa-pcm.c:29:26: error: >> linux/printk.h: No such file or directory >> make[3]: *** [/home/jhh/dvb/media_build/v4l/ivtv-alsa-pcm.o] Error 1 >> >> Apparently, this header file was not yet present in this version of >> linux. It is the only driver requesting this header file. >> Removing line 29 >> >> #include >> >> fixes the problem. All compiles well then. >> >> >> >> -- >> Jan Hoogenraad >> Hoogenraad Interface Services >> Postbus 2717 >> 3500 GS Utrecht >> -- >> 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 > > Hi Jan, > > Hans Verkuil already noticed this and submitted a patch to remove the include. > > Regards, > Andy > -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- 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] [dvb-apps] DVB-S update scan dir 12.5W - 28.2E
The attached patch includes updates to dvb-apps package for all satellites ranging from 12.5W to 28.5E. This patch replaces the few previous patches I send and adds several more sat positions. Regards, Wojciech Myrda diff -Naur dvb-apps-3fc7dfa68484/util/scan/dvb-s/Amos-4w dvb-apps/util/scan/dvb-s/Amos-4w --- dvb-apps-3fc7dfa68484/util/scan/dvb-s/Amos-4w 2012-09-13 14:36:09.0 +0200 +++ dvb-apps/util/scan/dvb-s/Amos-4w 2012-09-22 09:51:09.867227015 +0200 @@ -1,48 +1,37 @@ -# Amos 6 @ 4W +# Amos 2,3 @ 4W +# http://en.kingofsat.net/pos-4W.php +# 2012-Sep-21 # freq pol sr fec S 10722000 H 2750 3/4 -S 10722000 V 2750 3/4 -S 10722000 V 3000 2/3 -S 10758000 V 2750 3/4 -S 10758000 V 3000 2/3 +S2 10723000 V 3000 2/3 AUTO 8PSK S 10759000 H 3000 3/4 -S 10806000 H 2750 5/6 -S 10806000 V 2750 3/4 -S 10842000 H 2750 7/8 -S 10842000 V 2750 3/4 -S 10842000 V 3000 2/3 -S 1089 H 2750 7/8 -S 1089 V 2750 3/4 -S 10925000 H 2750 7/8 -S 10925000 V 2750 3/4 -S 10972000 V 2750 3/4 -S 11008000 V 2750 3/4 -S 11015000 H 2295000 3/4 -S 11123000 H 185 7/8 -S 11167000 H 1250 5/6 -S 11179000 H 000 3/4 -S 1126 H 2750 3/4 -S 11304000 H 1954 3/4 -S 11319000 H 275 3/4 -S 11329000 H 000 3/4 -S 11333000 H 350 3/4 -S 11347000 H 335 3/4 -S 11384000 H 1900 5/6 -S 11411000 H 7925000 5/6 -S 11429000 H 5925000 3/4 -S 11435000 H 2089000 3/4 -S 11474000 V 2750 3/4 -S 1151 V 3000 2/3 -S 11558000 V 2750 3/4 -S 11559000 H 1340 7/8 -S 11572000 H 000 3/4 -S 11592000 H 2135 3/4 -S 11593000 V 2750 3/4 -S 11625000 V 300 3/4 -S 1163 H 2963000 3/4 -S 1163 V 300 3/4 -S 11637000 V 148 3/4 -S 11647000 H 9167000 3/4 -S 11647000 V 8518000 3/4 -S 11654000 H 200 5/6 -S 11658000 V 852 5/6 +S2 10759000 V 3000 2/3 AUTO 8PSK +S 10806000 H 3000 3/4 +S2 10806000 V 3000 2/3 AUTO 8PSK +# PowerVu encrypted Channels +#S 10842000 H 2750 5/6 +S2 10842000 V 3000 2/3 AUTO 8PSK +# PowerVu encrypted Channels +#S2 1088 H 1391 3/4 AUTO 8PSK +S2 10889000 V 3000 2/3 AUTO 8PSK +# PowerVu encrypted Channels +#S 10893000 H 7925000 5/6 +S2 10925000 V 10833000 2/3 AUTO 8PSK +S 11149000 H 350 3/4 +S 11157000 H 000 3/4 +S2 11162000 H 333 2/3 AUTO 8PSK +S 11181000 H 565 3/4 +S 11186000 H 335 5/6 +S 11222000 H 3000 5/6 +S 11258000 H 2750 5/6 +S 11304000 H 1000 3/4 +S2 11314000 H 500 2/3 AUTO 8PSK +S 11336000 H 2750 5/6 +S 11389000 H 2750 3/4 +S 11543000 H 370 3/4 +S 11572000 H 8887000 3/4 +S2 11587000 H 10833000 2/3 AUTO 8PSK +S 11601000 H 1000 3/4 +S 1161 H 360 3/4 +S 11629000 H 240 5/6 +S 11635000 H 6333000 3/4 diff -Naur dvb-apps-3fc7dfa68484/util/scan/dvb-s/Astra1-28.2E dvb-apps/util/scan/dvb-s/Astra1-28.2E --- dvb-apps-3fc7dfa68484/util/scan/dvb-s/Astra1-28.2E 1970-01-01 01:00:00.0 +0100 +++ dvb-apps/util/scan/dvb-s/Astra1-28.2E 2012-09-22 09:55:51.448413696 +0200 @@ -0,0 +1,25 @@ +# Astra 1N @ 28.2E +# UK Spot Beam +# http://en.kingofsat.net/sat-astra1n.php +# 2012-Sep-22 +# freq pol sr fec +S 10714000 H 2200 5/6 +S 10729000 V 2200 5/6 +S 10744000 H 2200 5/6 +S 10758000 V 2200 5/6 +S 10773000 H 2200 5/6 +S 10788000 V 2200 5/6 +S 10803000 H 2200 5/6 +S 10818000 V 2200 5/6 +S 10832000 H 2200 5/6 +S2 10847000 V 2300 8/9 +S 10862000 H 2200 5/6 +S 10876000 V 2200 5/6 +S 10891000 H 2200 5/6 +S 10906000 V 2200 5/6 +S2 10921000 H 2300 8/9 +S2 10936000 V 2300 8/9 +S 10964000 H 2200 5/6 +S 10994000 H 2200 5/6 +S 11053000 H 2200 5/6 +S 11127000 V 2200 5/6 diff -Naur dvb-apps-3fc7dfa68484/util/scan/dvb-s/Astra-19.2E dvb-apps/util/scan/dvb-s/Astra-19.2E --- dvb-apps-3fc7dfa68484/util/scan/dvb-s/Astra-19.2E 2012-09-13 14:36:09.0 +0200 +++ dvb-apps/util/scan/dvb-s/Astra-19.2E 2012-09-22 09:51:40.299248874 +0200 @@ -1,3 +1,107 @@ -# Astra 19.2E SDT info service transponder +# Astra @ 19.2E +# http://en.kingofsat.net/pos-19.2E.php +# 2012-Sep-21 # freq pol sr fec +S2 10729000 V 2200 2/3 AUTO 8PSK +S 10744000 H 2200 5/6 +S 10758500 V 2200 5/6 +S2 10773000 H 2200 3/4 AUTO 8PSK +S 10788000 V 2200 5/6 +S2 10803000 H 2200 3/4 AUTO 8PSK +S2 10817500 V 2200 2/3 AUTO 8PSK +S2 10832000 H 2200 2/3 AUTO 8PSK +S 10847000 V 2200 5/6 +S 10862000 H 2200 7/8 +S 10876500 V 2200 5/6 +S 10921000 H 2200 7/8 +S2 10935500 V 2200 2/3 AUTO 8PSK +S 10979000 V 2200 5/6 +S 11023000 H 2200 5/6 +S 11038000 V 2200 5/6 +S 11067500 V 2200 5/6 +S 11097000 V 2200 5/6 +S2 11126500 V 2200 2/3 AUTO 8PSK +S 11156000 V 2200 5/6 +S2 11171000 H 2200 2/3 +S 11185500 V 2200 5/6 +S 11244000 H 2200 5/6 +S2 11258500 V 2200 2/3 AUTO 8PSK +S 11303000 H 2200 2/3 +S 11317500 V 2200 5/6 +S2 11347000 V 2200 2/3 AUTO 8PSK +S2 11362000 H 2200 2/3 AUTO 8PSK +S2 11376500
Re: [alsa-devel] [PATCH v2 00/34] i.MX multi-platform support
On Sat, Sep 22, 2012 at 12:41 AM, Olof Johansson wrote: > Hi, > > On Fri, Sep 21, 2012 at 9:53 AM, Shawn Guo wrote: >> On Sat, Sep 22, 2012 at 12:46:26AM +0800, Shawn Guo wrote: >>> I just published the branch below with this series rebased on top of >>> the necessary dependant branches. >>> >>> git://git.linaro.org/people/shawnguo/linux-2.6.git >>> staging/imx-multiplatform >>> >>> The dependant branches include: >>> >> >> Forgot the base: >> >> * arm-soc/next/multiplatform >> >> Shawn >> >>> * arm-soc/multiplatform/platform-data >>> >>> * arm-soc/multiplatform/smp_ops >>> >>> * git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-3.7 >>> >>> It contains dependant patch "ASoC: mx27vis: retrieve gpio numbers >>> from platform_data" >>> >>> * git://git.infradead.org/mtd-2.6.git master >>> >>> The series is based on this tree to solve some non-trivial conflicts >>> on mxc_nand driver. Because mtd tree completely missed 3.6 merge >>> window, having the series base on 3.6-rc actually means 3.5 code base >>> in term of mtd support. There are currently two cycles changes >>> accumulated on mtd, and we need to base the series on it to sort out >>> the conflicts. >>> >>> * git://linuxtv.org/mchehab/media-next.git master >>> >>> The media tree renames mx2/mx3 camera drivers twice. I'm not sure >>> if git merge can detect them, so I just rebased the series on media >>> tree to solve that. The bonus point is that a number of trivial >>> conflicts with imx27-coda support on media tree gets solved as well. >>> >>> I'm not requesting you to pull the branch into arm-soc as a stable >>> branch but staging one, because the external dependencies which might >>> not be stable. I attempt to use it for exposing the series on >>> linux-next, so that we can send it to Linus for 3.7 if there is chance >>> for us to (e.g. all the dependant branches hit mainline early during >>> 3.7 merge window). > > I've pulled this in now as staging/imx-multiplatform. > > As you mention, it might or might not make sense to send this up. It > also accrued a few more merge conflicts with other branches in > arm-soc, so we'll see how things play out. > > Either way, we'll for sure queue it for 3.8. Hmm. Pulling it in gives me a few new build errors, in particular on the configs that Russell use to build test omap3, as well as one of his vexpress configs. So I dropped it again for now. Let's have the current contents sit in linux-next for at least one release before we bring in anything more, especially since it brings in dependencies on external trees, and it also has a handful of new merge conflicts. We're already exposing Stephen Rothwell to more merge conflicts than I'm entirely comfortable with. -Olof -- 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] s5p-tv: Fix potential NULL pointer dereference error
When mdev is NULL, the error print statement will try to dereference
the NULL pointer.
Signed-off-by: Sachin Kamat
---
drivers/media/platform/s5p-tv/mixer_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/platform/s5p-tv/mixer_drv.c
b/drivers/media/platform/s5p-tv/mixer_drv.c
index a15ca05..ca0f297 100644
--- a/drivers/media/platform/s5p-tv/mixer_drv.c
+++ b/drivers/media/platform/s5p-tv/mixer_drv.c
@@ -384,7 +384,7 @@ static int __devinit mxr_probe(struct platform_device *pdev)
mdev = kzalloc(sizeof *mdev, GFP_KERNEL);
if (!mdev) {
- mxr_err(mdev, "not enough memory.\n");
+ dev_err(dev, "not enough memory.\n");
ret = -ENOMEM;
goto fail;
}
--
1.7.4.1
--
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: [alsa-devel] [PATCH v2 00/34] i.MX multi-platform support
Hi, On Fri, Sep 21, 2012 at 9:53 AM, Shawn Guo wrote: > On Sat, Sep 22, 2012 at 12:46:26AM +0800, Shawn Guo wrote: >> I just published the branch below with this series rebased on top of >> the necessary dependant branches. >> >> git://git.linaro.org/people/shawnguo/linux-2.6.git >> staging/imx-multiplatform >> >> The dependant branches include: >> > > Forgot the base: > > * arm-soc/next/multiplatform > > Shawn > >> * arm-soc/multiplatform/platform-data >> >> * arm-soc/multiplatform/smp_ops >> >> * git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-3.7 >> >> It contains dependant patch "ASoC: mx27vis: retrieve gpio numbers >> from platform_data" >> >> * git://git.infradead.org/mtd-2.6.git master >> >> The series is based on this tree to solve some non-trivial conflicts >> on mxc_nand driver. Because mtd tree completely missed 3.6 merge >> window, having the series base on 3.6-rc actually means 3.5 code base >> in term of mtd support. There are currently two cycles changes >> accumulated on mtd, and we need to base the series on it to sort out >> the conflicts. >> >> * git://linuxtv.org/mchehab/media-next.git master >> >> The media tree renames mx2/mx3 camera drivers twice. I'm not sure >> if git merge can detect them, so I just rebased the series on media >> tree to solve that. The bonus point is that a number of trivial >> conflicts with imx27-coda support on media tree gets solved as well. >> >> I'm not requesting you to pull the branch into arm-soc as a stable >> branch but staging one, because the external dependencies which might >> not be stable. I attempt to use it for exposing the series on >> linux-next, so that we can send it to Linus for 3.7 if there is chance >> for us to (e.g. all the dependant branches hit mainline early during >> 3.7 merge window). I've pulled this in now as staging/imx-multiplatform. As you mention, it might or might not make sense to send this up. It also accrued a few more merge conflicts with other branches in arm-soc, so we'll see how things play out. Either way, we'll for sure queue it for 3.8. -Olof -- 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] s5k6aa: Fix possible NULL pointer dereference
It is previously assumed that 'rect' could be NULL. Hence add a check to print the members of 'rect' only when it is not NULL. Signed-off-by: Sachin Kamat --- drivers/media/i2c/s5k6aa.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/i2c/s5k6aa.c b/drivers/media/i2c/s5k6aa.c index 045ca7f..7531edb 100644 --- a/drivers/media/i2c/s5k6aa.c +++ b/drivers/media/i2c/s5k6aa.c @@ -1177,8 +1177,9 @@ static int s5k6aa_get_crop(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh, mutex_unlock(&s5k6aa->lock); - v4l2_dbg(1, debug, sd, "Current crop rectangle: (%d,%d)/%dx%d\n", -rect->left, rect->top, rect->width, rect->height); + if (rect) + v4l2_dbg(1, debug, sd, "Current crop rectangle: (%d,%d)/%dx%d\n", +rect->left, rect->top, rect->width, rect->height); return 0; } -- 1.7.4.1 -- 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
