Re: [soc_camera] Dynamic crop window change while streaming (Zoom case)?
Hi Sergio
On Tue, 12 Apr 2011, Aguirre, Sergio wrote:
Hi Guennadi,
I was wondering what's the stand on allowing soc_camera host drivers to have
internal scalers...
please, have a look at this thread for patches
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/30932
and (optionally) at this one for a discussion:
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/30910/focus=30922
If no objections are raised, these patches might end up in 2.6.40.
Thanks
Guennadi
It looks possible, but however I see one important blocker for being able to
change window rectangle while streaming (for example, when attempting to do
zoom in/out during streaming). See here:
in soc_camera.c::soc_camera_s_crop()
...
/* If get_crop fails, we'll let host and / or client drivers decide */
ret = ici-ops-get_crop(icd, current_crop);
/* Prohibit window size change with initialised buffers */
if (ret 0) {
dev_err(icd-dev,
S_CROP denied: getting current crop failed\n);
} else if (icd-vb_vidq.bufs[0]
(a-c.width != current_crop.c.width ||
a-c.height != current_crop.c.height)) {
dev_err(icd-dev,
S_CROP denied: queue initialised and sizes differ\n);
ret = -EBUSY;
} else {
ret = ici-ops-set_crop(icd, a);
}
...
Now, I don't want to move just yet to a Media Controller implementation in my
omap4 camera driver, since I don't intend yet to exploit the full HW, which
is easly 2x more complicated than omap3. But I want to start with a simplistic
driver which Pandaboard community can take (which don't need any advanced
features, just being able to receive frames.) and i just want to know how
complicated is to just offer the scaler functionality still.
Regards,
Sergio
---
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: Antwort: Re: [PATCH 1/2] mt9v022: fix pixel clock
Hello Teresa Thanks very much for your extensive testing! I'm afraid, I don't have the time right now to go through all those register settings, so, can we, maybe, do the following: we currently have two platforms in the mainline, that use mt9v022. We believe, that the driver itself implements the pixel clock edge configuration wrongly. Could you please provide patches to 1. fix mt9v022 to match our new understanding 2. if needed - additionally fix pcm037 by setting the SOCAM_SENSOR_INVERT_PCLK flag 3. same for pcm990 / pcm027 I also noticed your wrong colours result - if colours are completely swapped, maybe you just have to adjust your Bayer decoder? Once we get those patches, I'll try to test them, but I've a very tight schedule atm, so, maybe I'll just believe you to get them on time for 2.6.39. Thanks Guennadi On Tue, 12 Apr 2011, Teresa Gamez wrote: Am Freitag, den 08.04.2011, 15:27 +0200 schrieb Teresa Gamez: Hello Guennadi, Am Donnerstag, den 07.04.2011, 14:41 +0200 schrieb Guennadi Liakhovetski: Hello Teresa On Thu, 7 Apr 2011, Teresa Gamez wrote: Hello Guennadi, the datasheet also says (see table 3): quote Pixel clock out. DOUT is valid on rising edge of this clock. /quote There is a difference between DOUT beeing vaild and DOUT beeing set up. So does SOCAM_PCLK_SAMPLE_RISING mean that the data is valid at rising edge or does it mean the data is set up at rising edge? Hm, yeah, looks like a typical example of a copy-paste datasheet to me:-( And now we don't know which of the two is actually supposed to be true. As for set up vs. valid - not sure, whether there is indeed a difference between them. To me set up _TO_ the rising edge is a short way to set set up to be valid at the rising edge, however, I might be wrong. Can you tell me in more detail what and where (at the sensor board or on the baseboard) you measured and what it looked like? I think, Figure 7 and the description below it are interesting. From that diagram I would indeed say indeed the DOUT pins are valid and should be sampled at the rising edge by default - when bit 4 in 0x74 is not set. SOCAM_PCLK_SAMPLE_RISING means, that the data should be sampled at the rising of pclkm, i.e., it is valid there. I meassured the outgoing pins from the baseboard to the camera board and checked the PCLK and D0 to see at which point the data is valid. I have also checked the quality of the image. All tests where made with sensor_type=color My results for pcm038 are with following register settings: mx2_camera 0x0 CSICR1: 0x10020b92 - rising edge mt9v022 0x74 PIXCLK_FV_LV: 0x0010 - rising edge (which I think is falling edge) meassured: falling edge (ugly image, wrong colors) Now I set the SOCAM_SENSOR_INVERT_PCLK flag in the platformcode for the mt9v022: mx2_camera 0x0 CSICR10x10020b92 - rising edge mt9v022 0x74 PIXCLK_FV_LV 0x - falling edge (which I think is rising edge) meassured: rising edge (image is OK) Now changed the PCLK of the mx2_camera: mx2_camera 0x0 CSICR1 0x10020b90 - falling edge mt9v022 0x74 PIXCLK_FV_LV0x0010 - rising edge (which I think is falling edge) meassured: falling edge (image is OK) So, yes, if your measurements agree with figure 7 from the datasheet, we shall assume, that the driver implements the pclk polarity wrongly. But the fix should be more extensive, than what you've submitted: if we invert driver's behaviour, we should also invert board configuration of all driver users: pcm990 and pcm037. Or we have to test them and verify, that the inverted pclk polarity doesn't megatively affect the image quality, or maybe even improves it. Thanks Guennadi I have tested this with a pcm038 but I will also make meassurements with the pcm037. Same results with the pcm037: mx3_camera 0x60 CSI_SENS_CONF: 0x0700 - rising edge mt9v022 0x74 PIXCLK_FV_LV: 0x0010 - rising edge (which I think is falling edge) meassured: falling edge (ulgy image, looks like b/w with pixel errors) Set SOCAM_SENSOR_INVERT_PCLK flag in the platformcode for the mt9v022: mx3_camera 0x60 CSI_SENS_CONF: 0x0700 - rising edge mt9v022 0x74 PIXCLK_FV_LV 0x - falling edge (which I think is rising edge) meassured: rising edge (image is OK) Additionally set MX3_CAMERA_PCP of the mx3_camera flags mx3_camera 0x60 CSI_SENS_CONF: 0x0708 - falling edge mt9v022 0x74 PIXCLK_FV_LV: 0x0010 - rising edge (which I think is falling edge) meassured: falling edge (image is OK) Removed SOCAM_SENSOR_INVERT_PCLK flag
[RFC 1/1] v4l: Improve error handling in v4l2_device_register_subdev()
In some cases v4l2_device_register_subdev() did not module_put() a module
the user count of which was incremented by try_module_get() earlier.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
Hi,
I'm sending this as an RFC since technically this leaves still room for
improvement.
v4l2_ctrl_add_handler() error handling is still to be implemented. The
controls are added to the parent and that needs to be cleaned up ---
actually, even if v4l2_ctrl_add_handler() fails, the added controls would
have to be removed from the v4l2_dev parent.
I don't see an easy way to do this, except to call v4l2_ctrl_handler_free().
But that also cleans up the existing controls in the parent, which might not
be desirable.
As far as I understand, no driver initialises the v4l2_dev-ctrl_handler for
the moment.
---
drivers/media/video/v4l2-device.c | 30 ++
1 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/v4l2-device.c
b/drivers/media/video/v4l2-device.c
index 5aeaf87..773146d 100644
--- a/drivers/media/video/v4l2-device.c
+++ b/drivers/media/video/v4l2-device.c
@@ -156,27 +156,20 @@ int v4l2_device_register_subdev(struct v4l2_device
*v4l2_dev,
if (sd-internal_ops sd-internal_ops-registered) {
err = sd-internal_ops-registered(sd);
if (err)
- return err;
+ goto err_registered;
}
/* This just returns 0 if either of the two args is NULL */
err = v4l2_ctrl_add_handler(v4l2_dev-ctrl_handler, sd-ctrl_handler);
- if (err) {
- if (sd-internal_ops sd-internal_ops-unregistered)
- sd-internal_ops-unregistered(sd);
- return err;
- }
+ if (err)
+ goto err_v4l2_ctrl_add_handler;
#if defined(CONFIG_MEDIA_CONTROLLER)
/* Register the entity. */
if (v4l2_dev-mdev) {
err = media_device_register_entity(v4l2_dev-mdev, entity);
- if (err 0) {
- if (sd-internal_ops sd-internal_ops-unregistered)
- sd-internal_ops-unregistered(sd);
- module_put(sd-owner);
- return err;
- }
+ if (err 0)
+ goto err_media_device_register_entity;
}
#endif
@@ -185,6 +178,19 @@ int v4l2_device_register_subdev(struct v4l2_device
*v4l2_dev,
spin_unlock(v4l2_dev-lock);
return 0;
+
+#if defined(CONFIG_MEDIA_CONTROLLER)
+err_media_device_register_entity:
+#endif
+err_v4l2_ctrl_add_handler:
+ /* FIXME: v4l2_ctrl_add_handler() error handling. */
+ if (sd-internal_ops sd-internal_ops-unregistered)
+ sd-internal_ops-unregistered(sd);
+
+err_registered:
+ module_put(sd-owner);
+
+ return err;
}
EXPORT_SYMBOL_GPL(v4l2_device_register_subdev);
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR 2.6.39] s5p-fimc driver updates
Hi Mauro, please pull from git://git.infradead.org/users/kmpark/linux-2.6-samsung for-mauro for a few s5p-fimc driver bugfixes. The following changes since commit 28df73703e738d8ae7a958350f74b08b2e9fe9ed: [media] xc5000: Improve it to work better with 6MHz-spaced channels (2011-03-28 15:49:28 -0300) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung for-mauro Sylwester Nawrocki (4): s5p-fimc: Fix FIMC3 pixel limits on Exynos4 s5p-fimc: Do not allow changing format after REQBUFS s5p-fimc: Fix bytesperline and plane payload setup s5p-fimc: Add support for the buffer timestamps and sequence drivers/media/video/s5p-fimc/fimc-capture.c |8 ++- drivers/media/video/s5p-fimc/fimc-core.c| 74 +-- 2 files changed, 52 insertions(+), 30 deletions(-) Thank you, -- Sylwester Nawrocki Samsung Poland RD Center -- 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
[GIT PULL FOR 2.6.40] Anysee
Moikka Mauro, PULL following patches for the 2.6.40. There is new silicon tuner driver for NXP TDA18212HN. This basically adds support for two Anysee models: 1. E30 Combo Plus (new revision, TDA18212 tuner) 2. E7 TC t. Antti The following changes since commit d9954d8547181f9a6a23f835cc1413732700b785: Merge branch 'linus' into staging/for_v2.6.40 (2011-04-04 16:04:30 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git anysee Antti Palosaari (12): NXP TDA18212HN silicon tuner driver anysee: I2C address fix anysee: fix multibyte I2C read anysee: change some messages anysee: reimplement demod and tuner attach anysee: add support for TDA18212 based E30 Combo Plus anysee: add support for Anysee E7 TC anysee: fix E30 Combo Plus TDA18212 GPIO anysee: fix E30 Combo Plus TDA18212 DVB-T anysee: enhance demod and tuner attach anysee: add support for two byte I2C address anysee: add more info about known board configs drivers/media/common/tuners/Kconfig |8 + drivers/media/common/tuners/Makefile|1 + drivers/media/common/tuners/tda18212.c | 265 ++ drivers/media/common/tuners/tda18212.h | 48 +++ drivers/media/common/tuners/tda18212_priv.h | 44 +++ drivers/media/dvb/dvb-usb/Kconfig |1 + drivers/media/dvb/dvb-usb/anysee.c | 519 +- drivers/media/dvb/dvb-usb/anysee.h | 22 +- 8 files changed, 806 insertions(+), 102 deletions(-) create mode 100644 drivers/media/common/tuners/tda18212.c create mode 100644 drivers/media/common/tuners/tda18212.h create mode 100644 drivers/media/common/tuners/tda18212_priv.h -- 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: V4L/ARM: videobuf-dma-contig no longer works on my ARM machine
Dnia sobota 09 kwiecień 2011 o 18:42:40 Jiri Slaby napisał(a): On 04/09/2011 05:10 PM, Janusz Krzysztofik wrote: (CC: Jiri Slaby, the author of the problematic change; truncate subject) On Sat, 09 Apr 2011, at 09:16:24, Russell King - ARM Linux wrote: On Sat, Apr 09, 2011 at 03:33:39AM +0200, Janusz Krzysztofik wrote: Since there were no actual problems reported before, I suppose the old code, which was passing to remap_pfn_range() a physical page number calculated from dma_alloc_coherent() privided dma_handle, worked correctly on all platforms actually using videobud-dma-config. No, it didn't when IOMMU was used. Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name a board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf-dma-config susbsystem, c) uses IOMMU? If there is one, than I agree that reverting the patch is not a good option. Because remap_pfn_range didn't get a physical page address. If I didn't understand it, I wouldn't try to find a solution other than reverting your patch. Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
On Tue 12 Apr 2011 at 23:40:11 Russell King - ARM Linux wrote: On Tue, Apr 12, 2011 at 11:06:34PM +0200, Janusz Krzysztofik wrote: The patch tries to solve this regression by using virt_to_phys(bus_to_virt(mem-dma_handle)) instead of problematic virt_to_phys(mem-vaddr). Who says that DMA handles are bus addresses in the strictest sense? DMA handles on ARM are the bus address to program 'dev' with in order for it to access the memory mapped by dma_alloc_coherent(). On some ARM platforms, this bus address is dependent on 'dev' - such as platforms with more than one root PCI bus, and so bus_to_virt() just doesn't hack it. Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name an ARM based board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf- dma-config susbsystem, c) has a bus structure with which virt_to_phys(bus_to_virt(dma_handle)) is not equal dma_handle? If there is one, then I agree that my short-term fix is wrong. What is really needed is for this problem - the mapping of DMA coherent memory into userspace - to be solved with a proper arch API rather than all these horrible hacks which subsystems instead invent. That's something I tried to do with the dma_mmap_coherent() stuff but it was shot down by linux-arch as (iirc) PA-RISC objected to it. Hence why ARM only implements it. I thought so too, but missed the fact that PowerPC implements it actually, even defining the ARCH_HAS_DMA_MMAP_COHERENT symbol, which ARM doesn't so far. Maybe the video drivers should try to resurect the idea, maybe only allowing this support for architectures which provide dma_mmap_coherent(). AFAICT, ARM implementation of dma_mmap_coherent() is not compatible with dma_declare_coherent_memory(), is it? If I'm wrong, please correct me, I'll get back to the idea presented in v1 of the fix. Otherwise, I think that switching to dma_mmap_coherent() is not an option for the videobuf-dma-contig subsystem as long as there is no good solution to the problem of dma_alloc_coherent() not guaranteed to succeed with high-order allocations at any time. Any chance for your already proposed (http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036463.html, http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/036809.html), or perhaps a new, better solution ever finding its way to the mainline tree? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Hello. On 13-04-2011 1:06, Janusz Krzysztofik wrote: After switching from mem-dma_handle to virt_to_phys(mem-vaddr) used for obtaining page frame number passed to remap_pfn_range() (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig Please specify the commit summary -- for the human readers. stopped working on my ARM based board. The ARM architecture maintainer, Russell King, confirmed that using something like virt_to_phys(dma_alloc_coherent()) is not supported on ARM, and can be broken on other architectures as well. The author of the change, Jiri Slaby, also confirmed that his code may not work on all architectures. The patch tries to solve this regression by using virt_to_phys(bus_to_virt(mem-dma_handle)) instead of problematic virt_to_phys(mem-vaddr). I think this should work even if those translations would occure inaccurate for DMA addresses, since possible errors introduced by both translations, performed in opposite directions, should compensate. Tested on ARM OMAP1 based Amstrad Delta board. Signed-off-by: Janusz Krzysztofikjkrzy...@tis.icnet.pl WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] V4L2 API for flash devices
Sung Hee Park wrote: Here are two more use-cases for flash that might help inform the API design. Sakari encouraged me to post these. The person writing this is Andrew Adams, but I'm sending this from Sung Hee's account, because I only just subscribed to linux-media and can't immediately figure out how to reply to messages from before I subscribed. Sung Hee and I are both grad students at Stanford who work on FCam (http://fcam.garage.maemo.org/) Hi Andrew, Many thanks for the comments. Second-curtain-sync: Sometimes you want to fire the flash at the end of a long exposure time. It's usually a way to depict motion. Here's an example: http://www.flickr.com/photos/latitudes/133206615/. This only really applies to xenon flashes because you can't get a crisp image out of a longer duration LED flash. Even then it's somewhat problematic on rolling-shutter sensors but still possible provided you don't mind a slight shear to the crisp part of the image. From an API perspective, it requires you to be able to specify a trigger time at some number of microseconds into the exposure. On the N900 we did this with a real-time thread. Triggering external hardware: This use-case is a little weirder, but it has the same API requirement. Some photographic setups require you to synchronize some piece of hardware with the exposure (e.g. an oscilloscope, or an external slave flash). On embedded devices this is generally difficult. If you can at least fire the flash at a precise delay into the exposure, you can attach a photodiode to it, and use the flash+photodiode as an opto-isolator to trigger your external hardware. So we're in favor of having user-settable flash duration, and also user-settable trigger times (with reference to the start of the exposure time). I'm guessing that in a SMIA++ driver the trigger time would actually be a control on the sensor device, but it seemed relevant to bring up while you guys were talking about the flash API. From this I reckon that in a general case the handling of the flash timing cannot be left for the drivers only. There must be a way to control it. So I'd think that also the level/edge trigger for the flash should be visible. On edge trigger, the only limiting factor for the flash duration on hardware would be the relatively coarse watchdog timer, and I'd think the user should be able to know that. The flash timing controls should be exposed by the sensor driver since the sensor is what actually performs the timing. Laurent; what do you think? Cheers, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
OMAP3 ISP deadlocks on my new arm
Hello people, I switched to the new DM3730 from IGEP and while it's supposed to be (almost) the same as the 3530 Version the isp deadlocks deterministically after I start capturing the second time with yavta. All extra locking debug output is enabled in the kernel .config. I am unsure if this is an ISP thing or a problem in the interrupthandling software. The first block is the watchdog that detects the deadlock. The last block is in the isp-code but how can it hang when trying to UNlock a spinlock? I am unsure about the 2nd block. The assembler code of __irq_svc is located in arch/arm/kernel/entry-armv.S Maybe I should try on linux-...@lists.arm.linux.org.uk but I thought I give it a shot here first. I use the omap3isp-2.6.35.3-omap3isp branch from Laurent. Any ideas? Thanks for any help, Bastian Hecht [ 190.059509] BUG: soft lockup - CPU#0 stuck for 61s! [yavta:2224] [ 190.065704] Kernel panic - not syncing: softlockup: hung tasks [ 190.071563] [c0031078] (unwind_backtrace+0x0/0xe4) from [c02baf24] (panic+0x50/0xd0) [ 190.079711] [c02baf24] (panic+0x50/0xd0) from [c00729e4] (softlockup_tick+0x134/0x158) [ 190.088043] [c00729e4] (softlockup_tick+0x134/0x158) from [c005612c] (update_process_times+0x28/0x48) [ 190.097656] [c005612c] (update_process_times+0x28/0x48) from [c00697bc] (tick_sched_timer+0x88/0xbc) [ 190.107177] [c00697bc] (tick_sched_timer+0x88/0xbc) from [c0061ff0] (__run_hrtimer+0x44/0x84) [ 190.116119] [c0061ff0] (__run_hrtimer+0x44/0x84) from [c0062144] (hrtimer_interrupt+0x114/0x2c8) [ 190.125305] [c0062144] (hrtimer_interrupt+0x114/0x2c8) from [c0035e20] (omap2_gp_timer_interrupt+0x20/0x2c) [ 190.135437] [c0035e20] (omap2_gp_timer_interrupt+0x20/0x2c) from [c00730e4] (handle_IRQ_event+0x24/0xe0) [ 190.145324] [c00730e4] (handle_IRQ_event+0x24/0xe0) from [c0074b80] (handle_level_irq+0x90/0xfc) [ 190.154510] [c0074b80] (handle_level_irq+0x90/0xfc) from [c002c06c] (asm_do_IRQ+0x6c/0x8c) [ 190.163177] [c002c06c] (asm_do_IRQ+0x6c/0x8c) from [c002c9f4] (__irq_svc+0x34/0x80) [ 190.171234] Exception stack(0xda413c98 to 0xda413ce0) [ 190.176300] 3c80: 0020 c03c20d0 [ 190.184509] 3ca0: c0417240 da412000 0002 ded72e84 000a dec54640 [ 190.192718] 3cc0: c0417240 0002 da413ce0 c0051bd4 c0051ad8 2113 [ 190.200958] [c002c9f4] (__irq_svc+0x34/0x80) from [c0051ad8] (__do_softirq+0x3c/0xf8) [ 190.209167] [c0051ad8] (__do_softirq+0x3c/0xf8) from [c0051bd4] (irq_exit+0x40/0x8c) [ 190.217315] [c0051bd4] (irq_exit+0x40/0x8c) from [c002c070] (asm_do_IRQ+0x70/0x8c) [ 190.225280] [c002c070] (asm_do_IRQ+0x70/0x8c) from [c002c9f4] (__irq_svc+0x34/0x80) [ 190.233306] Exception stack(0xda413d20 to 0xda413d68) [ 190.238403] 3d20: defc4938 defc48c0 defc4084 ded72e84 ded72e14 ded72e80 4013 ded72e84 [ 190.246612] 3d40: ded72e68 dec54640 dedc5a38 defc40f8 da413d68 bf01d4cc bf01d4ec [ 190.254821] 3d60: 6013 [ 190.258361] [c002c9f4] (__irq_svc+0x34/0x80) from [bf01d4ec] (omap3isp_video_queue_streamon+0x6c/0x7c [omap3_isp]) [ 190.269165] [bf01d4ec] (omap3isp_video_queue_streamon+0x6c/0x7c [omap3_isp]) from [bf01f1d4] (isp_video_streamon+0x150/0x1f8 [omap3_isp]) [ 190.281951] [bf01f1d4] (isp_video_streamon+0x150/0x1f8 [omap3_isp]) from [c01fa76c] (__video_do_ioctl+0x1488/0x3bd0) [ 190.292877] [c01fa76c] (__video_do_ioctl+0x1488/0x3bd0) from [c01f8ee8] (__video_usercopy+0x2d0/0x414) [ 190.302581] [c01f8ee8] (__video_usercopy+0x2d0/0x414) from [c01f8370] (v4l2_unlocked_ioctl+0x38/0x3c) [ 190.312194] [c01f8370] (v4l2_unlocked_ioctl+0x38/0x3c) from [c00a6d6c] (vfs_ioctl+0x2c/0x6c) [ 190.321044] [c00a6d6c] (vfs_ioctl+0x2c/0x6c) from [c00a7448] (do_vfs_ioctl+0x4cc/0x514) [ 190.329437] [c00a7448] (do_vfs_ioctl+0x4cc/0x514) from [c00a74c4] (sys_ioctl+0x34/0x54) [ 190.337829] [c00a74c4] (sys_ioctl+0x34/0x54) from [c002ce40] (ret_fast_syscall+0x0/0x30) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia środa 13 kwiecień 2011 o 14:03:44 Sergei Shtylyov napisał(a): Hello. On 13-04-2011 1:06, Janusz Krzysztofik wrote: After switching from mem-dma_handle to virt_to_phys(mem-vaddr) used for obtaining page frame number passed to remap_pfn_range() (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig Please specify the commit summary -- for the human readers. Hi, OK, I'll try to reword the summary using a more human friendly language as soon as I have signs that Mauro (who seemed to understand the message well enough) is willing to accept the code. Thanks, Janusz -- 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: soc_camera with V4L2 driver
Hello Guennadi, Thank you for the quick response. I am implementing 2mega pixel camera driver made by sharp and attached my primal kernel driver. (I still do not have the data sheet yet...) Thanks for attaching your driver. You can have a look at another driver for a Sharp camera sensor: drivers/media/video/rj54n1cb0c.c and at its platform glue in arch/sh/boards/mach-kfr2r09/setup.c, there you find struct platform_device kfr2r09_camera which links to struct soc_camera_link rj54n1_link etc. It would also help to know, with which SoC you're working, because in your platform code you'll need both platform data for the sensor and for the host. Feel free to ask, if you have more questions, but please also cc the mailing list. Great! I will look into rj54n1cb0c.c and mach-kfr2r09/setup.c of the: struct soc_camera_link rj54n1_link The ARM CPU is Renesas SoC. On Wed, 13 Apr 2011 08:29:31 -0300 Mauro Carvalho Chehab mche...@infradead.org mentioned: Thank you for the great advice. How do I bind the driver to soc_camera in my attached file? You'll need to add some glue on it, via platform_data. I never wrote such glue for soc_camera, so I can't give you the exact directions, but feel free to contact Guennadi (soc_camera author and maintainer) to get more details. How do I glue together my attached driver with your soc_camera? May I have a pointer or suggestion? I was project leader of PlayStaion3 Linux and now moved Nomovok to develop ARM based embedded devices. With kind regards, Akira --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- Akira Tsukamoto akir...@s9.dion.ne.jp -- 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: soc_camera with V4L2 driver
Hello Guennadi, Additional information. The ARM cpu is made by Renesas. Then, perhaps, something similar to arch/arm/mach-shmobile/board-ap4evb.c Thank you, I will look into it too. With kind regards, Akira -- Akira Tsukamoto -- 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: OMAP3 ISP deadlocks on my new arm
Hello, I attached the output without extra kernel lock info, here is the debug output: [ 375.811157] BUG: soft lockup - CPU#0 stuck for 61s! [yavta:2226] [ 375.817474] Kernel panic - not syncing: softlockup: hung tasks [ 375.823364] [c003250c] (unwind_backtrace+0x0/0xe4) from [c02e11a0] (panic+0x50/0xd4) [ 375.831512] [c02e11a0] (panic+0x50/0xd4) from [c007e154] (softlockup_tick+0x14c/0x170) [ 375.839813] [c007e154] (softlockup_tick+0x14c/0x170) from [c00592e8] (update_process_times+0x28/0x48) [ 375.849456] [c00592e8] (update_process_times+0x28/0x48) from [c006e840] (tick_sched_timer+0x88/0xbc) [ 375.858978] [c006e840] (tick_sched_timer+0x88/0xbc) from [c00666c4] (__run_hrtimer+0x50/0x9c) [ 375.867889] [c00666c4] (__run_hrtimer+0x50/0x9c) from [c006681c] (hrtimer_interrupt+0x10c/0x2d8) [ 375.877075] [c006681c] (hrtimer_interrupt+0x10c/0x2d8) from [c0037438] (omap2_gp_timer_interrupt+0x20/0x2c) [ 375.887237] [c0037438] (omap2_gp_timer_interrupt+0x20/0x2c) from [c007e944] (handle_IRQ_event+0x24/0xe4) [ 375.897125] [c007e944] (handle_IRQ_event+0x24/0xe4) from [c0080570] (handle_level_irq+0xac/0x128) [ 375.906402] [c0080570] (handle_level_irq+0xac/0x128) from [c002d06c] (asm_do_IRQ+0x6c/0x8c) [ 375.915130] [c002d06c] (asm_do_IRQ+0x6c/0x8c) from [c002da78] (__irq_svc+0x38/0xa0) [ 375.923187] Exception stack(0xdea1dc80 to 0xdea1dcc8) [ 375.928253] dc80: 0001 dea3e840 0110 0001dbb7 dea1c000 0002 dff0cac8 [ 375.936492] dca0: 000a deab8800 c0461080 c0773214 dea1dcc8 c0071ba0 c0054614 [ 375.944702] dcc0: 6113 [ 375.948211] [c002da78] (__irq_svc+0x38/0xa0) from [c0054614] (__do_softirq+0x4c/0x128) [ 375.956512] [c0054614] (__do_softirq+0x4c/0x128) from [c0054740] (irq_exit+0x50/0x9c) [ 375.964752] [c0054740] (irq_exit+0x50/0x9c) from [c002d070] (asm_do_IRQ+0x70/0x8c) [ 375.972686] [c002d070] (asm_do_IRQ+0x70/0x8c) from [c002da78] (__irq_svc+0x38/0xa0) [ 375.980743] Exception stack(0xdea1dd08 to 0xdea1dd50) [ 375.985809] dd00: 0001 dea3e840 0110 0001dbb4 4013 dff0caa8 [ 375.994049] dd20: dff0cac4 dff0cac8 dff0caa8 deab8800 4013 c089e5fc dea1dd50 [ 376.002258] dd40: c0071ba0 c02e3dc4 2013 [ 376.007354] [c002da78] (__irq_svc+0x38/0xa0) from [c02e3dc4] (_raw_spin_unlock_irqrestore+0x40/0x44) [ 376.016906] [c02e3dc4] (_raw_spin_unlock_irqrestore+0x40/0x44) from [bf01f678] (omap3isp_video_queue_streamon+0x80/0x90 [omap3_isp]) [ 376.029388] [bf01f678] (omap3isp_video_queue_streamon+0x80/0x90 [omap3_isp]) from [bf02128c] (isp_video_streamon+0x15c/0x214 [omap3_isp]) [ 376.042175] [bf02128c] (isp_video_streamon+0x15c/0x214 [omap3_isp]) from [c0216b38] (__video_do_ioctl+0x1488/0x3bd0) [ 376.053100] [c0216b38] (__video_do_ioctl+0x1488/0x3bd0) from [c02152b4] (__video_usercopy+0x2d0/0x414) [ 376.062835] [c02152b4] (__video_usercopy+0x2d0/0x414) from [c0214708] (v4l2_unlocked_ioctl+0x38/0x3c) [ 376.072448] [c0214708] (v4l2_unlocked_ioctl+0x38/0x3c) from [c00b5f1c] (vfs_ioctl+0x2c/0x6c) [ 376.081268] [c00b5f1c] (vfs_ioctl+0x2c/0x6c) from [c00b6610] (do_vfs_ioctl+0x4e4/0x52c) [ 376.089660] [c00b6610] (do_vfs_ioctl+0x4e4/0x52c) from [c00b668c] (sys_ioctl+0x34/0x54) [ 376.098052] [c00b668c] (sys_ioctl+0x34/0x54) from [c002df40] (ret_fast_syscall+0x0/0x3c) [ 376.106933] [ cut here ] [ 376.111572] WARNING: at kernel/lockdep.c:2327 panic+0xb0/0xd4() [ 376.117523] Modules linked in: board_bastix framix omap3_isp iovmm omap_iommu iommu2 iommu [ 376.125915] [c003250c] (unwind_backtrace+0x0/0xe4) from [c004f554] (warn_slowpath_common+0x4c/0x64) [ 376.135375] [c004f554] (warn_slowpath_common+0x4c/0x64) from [c004f584] (warn_slowpath_null+0x18/0x1c) [ 376.145080] [c004f584] (warn_slowpath_null+0x18/0x1c) from [c02e1200] (panic+0xb0/0xd4) [ 376.153472] [c02e1200] (panic+0xb0/0xd4) from [c007e154] (softlockup_tick+0x14c/0x170) [ 376.161804] [c007e154] (softlockup_tick+0x14c/0x170) from [c00592e8] (update_process_times+0x28/0x48) [ 376.171417] [c00592e8] (update_process_times+0x28/0x48) from [c006e840] (tick_sched_timer+0x88/0xbc) [ 376.180969] [c006e840] (tick_sched_timer+0x88/0xbc) from [c00666c4] (__run_hrtimer+0x50/0x9c) [ 376.189880] [c00666c4] (__run_hrtimer+0x50/0x9c) from [c006681c] (hrtimer_interrupt+0x10c/0x2d8) [ 376.199066] [c006681c] (hrtimer_interrupt+0x10c/0x2d8) from [c0037438] (omap2_gp_timer_interrupt+0x20/0x2c) [ 376.209197] [c0037438] (omap2_gp_timer_interrupt+0x20/0x2c) from [c007e944] (handle_IRQ_event+0x24/0xe4) [ 376.219085] [c007e944] (handle_IRQ_event+0x24/0xe4) from [c0080570] (handle_level_irq+0xac/0x128) [ 376.228363] [c0080570] (handle_level_irq+0xac/0x128) from [c002d06c] (asm_do_IRQ+0x6c/0x8c) [ 376.237121] [c002d06c] (asm_do_IRQ+0x6c/0x8c) from [c002da78] (__irq_svc+0x38/0xa0) [ 376.245147] Exception stack(0xdea1dc80 to 0xdea1dcc8) [ 376.250244] dc80: 0001 dea3e840 0110 0001dbb7 dea1c000 0002 dff0cac8 [
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Hello. Janusz Krzysztofik wrote: After switching from mem-dma_handle to virt_to_phys(mem-vaddr) used for obtaining page frame number passed to remap_pfn_range() (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig Please specify the commit summary -- for the human readers. Hi, OK, I'll try to reword the summary using a more human friendly language as soon as I have signs that Mauro (who seemed to understand the message well enough) is willing to accept the code. I wasn't asking you to rework your summary but to specify the summary of the commit you've mentioned (in parens). Thanks, Janusz WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHES] Misc. trivial fixes
On 04/12/2011 04:31 PM, Robby Workman wrote: On Tue, 12 Apr 2011, Andreas Oberritter wrote: On 04/12/2011 04:10 AM, Robby Workman wrote: --- a/Make.rules +++ b/Make.rules @@ -11,6 +11,7 @@ PREFIX = /usr/local LIBDIR = $(PREFIX)/lib # subdir below LIBDIR in which to install the libv4lx libc wrappers LIBSUBDIR = libv4l +MANDIR = /usr/share/man Why did you hardcode /usr instead of keeping $(PREFIX)/share/man? Eek. I'd like to say that I sent the wrong patch, but alas, I simply had a thinko. See attached (better) patch :-) Looks good. Mauro, will you pick up this patch? Regards, Andreas -RW 0002-Allow-override-of-manpage-installation-directory.patch From 6ef4a1fecee242be9658528ef7663845d9bd6bc6 Mon Sep 17 00:00:00 2001 From: Robby Workman rwork...@slackware.com Date: Tue, 12 Apr 2011 09:26:57 -0500 Subject: [PATCH] Allow override of manpage installation directory This creates MANDIR in Make.rules and keeps the preexisting default of $(PREFIX)/share/man, but allows packagers to easily override via e.g. make MANDIR=/usr/man --- Make.rules |1 + utils/keytable/Makefile |4 ++-- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Make.rules b/Make.rules index 0bb2eb8..875828a 100644 --- a/Make.rules +++ b/Make.rules @@ -11,6 +11,7 @@ PREFIX = /usr/local LIBDIR = $(PREFIX)/lib # subdir below LIBDIR in which to install the libv4lx libc wrappers LIBSUBDIR = libv4l +MANDIR = $(PREFIX)/share/man # These ones should not be overriden from the cmdline diff --git a/utils/keytable/Makefile b/utils/keytable/Makefile index 29a6ac4..e093280 100644 --- a/utils/keytable/Makefile +++ b/utils/keytable/Makefile @@ -39,7 +39,7 @@ install: $(TARGETS) install -m 644 -p rc_keymaps/* $(DESTDIR)/etc/rc_keymaps install -m 755 -d $(DESTDIR)/lib/udev/rules.d install -m 644 -p 70-infrared.rules $(DESTDIR)/lib/udev/rules.d - install -m 755 -d $(DESTDIR)$(PREFIX)/share/man/man1 - install -m 644 -p ir-keytable.1 $(DESTDIR)$(PREFIX)/share/man/man1 + install -m 755 -d $(DESTDIR)$(MANDIR)/man1 + install -m 644 -p ir-keytable.1 $(DESTDIR)$(MANDIR)/man1 include ../../Make.rules -- 1.7.4.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
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Apr 13 19:00:29 CEST 2011 git hash:d9954d8547181f9a6a23f835cc1413732700b785 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: WARNINGS 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.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: WARNINGS 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 spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote: Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name an ARM based board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf- dma-config susbsystem, c) has a bus structure with which virt_to_phys(bus_to_virt(dma_handle)) is not equal dma_handle? I have no idea - and why should whether someone can name something that may break be a justification to allow something which is technically wrong? Surely it should be the other way around - if its technically wrong and _may_ break something then it shouldn't be allowed. I thought so too, but missed the fact that PowerPC implements it actually, even defining the ARCH_HAS_DMA_MMAP_COHERENT symbol, which ARM doesn't so far. So, there's no problem adding that symbol to ARM. Maybe the video drivers should try to resurect the idea, maybe only allowing this support for architectures which provide dma_mmap_coherent(). AFAICT, ARM implementation of dma_mmap_coherent() is not compatible with dma_declare_coherent_memory(), is it? If I'm wrong, please correct me, I'll get back to the idea presented in v1 of the fix. 1. dma_declare_coherent_memory() doesn't work on ARM for memory which already exists (its not permitted to ioremap() the kernel direct-mapped memory due to attribute aliasing issues.) 2. dma_declare_coherent_memory() totally bypasses the DMA allocator, and so dma_mmap_coherent() has no knowledge of how to map the memory. If we had a proper way to map DMA memory into userspace, then we wouldn't have these issues as the dma_declare_coherent_memory() would already support that. And actually, talking about dma_declare_coherent_memory(), you've just provided a reason why virt_to_phys(bus_to_virt(dma_handle)) won't work - dma_declare_coherent_memory() can be used to provide on-device memory where the virt/handle may not be mappable with bus_to_virt(). Otherwise, I think that switching to dma_mmap_coherent() is not an option for the videobuf-dma-contig subsystem as long as there is no good solution to the problem of dma_alloc_coherent() not guaranteed to succeed with high-order allocations at any time. Let me repeat: there is no official API or way to map DMA memory into userspace. Every way people try is a half-hacked up bodge which may or may not work for a limited subset of systems. Until someone (like you) puts some serious effort into persuading *everyone* that this feature is needed, things are just going to continue being bodged and fragile. All that's happening here is that you're changing one broken way which works for one subset with another broken way which works for a different subset of systems and architectures. What actually needs to happen is a _proper_ fix for this. -- 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/2 v2] [media] rc/nuvoton-cir: enable CIR on w83667hg chip variant
Thanks to some excellent investigative work by Douglas Clowes, it was
uncovered that the older w83667hg Nuvoton chip functions with this
driver after actually enabling the CIR function via its multi-function
chip config register. The CIR and CIR wide-band sensor enable bits are
just in a different place on this hardware, so we only poke register
0x27 on 677 hardware now, and we poke register 0x2c on the 667 now.
Reported-by: Douglas Clowes dclow...@optusnet.com.au
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/rc/nuvoton-cir.c | 22 --
drivers/media/rc/nuvoton-cir.h |7 +++
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/media/rc/nuvoton-cir.c b/drivers/media/rc/nuvoton-cir.c
index bc5c1e2..5d93384 100644
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -291,13 +291,23 @@ static int nvt_hw_detect(struct nvt_dev *nvt)
static void nvt_cir_ldev_init(struct nvt_dev *nvt)
{
- u8 val;
+ u8 val, psreg, psmask, psval;
+
+ if (nvt-chip_major == CHIP_ID_HIGH_667) {
+ psreg = CR_MULTIFUNC_PIN_SEL;
+ psmask = MULTIFUNC_PIN_SEL_MASK;
+ psval = MULTIFUNC_ENABLE_CIR | MULTIFUNC_ENABLE_CIRWB;
+ } else {
+ psreg = CR_OUTPUT_PIN_SEL;
+ psmask = OUTPUT_PIN_SEL_MASK;
+ psval = OUTPUT_ENABLE_CIR | OUTPUT_ENABLE_CIRWB;
+ }
- /* output pin selection (Pin95=CIRRX, Pin96=CIRTX1, WB enabled */
- val = nvt_cr_read(nvt, CR_OUTPUT_PIN_SEL);
- val = OUTPUT_PIN_SEL_MASK;
- val |= (OUTPUT_ENABLE_CIR | OUTPUT_ENABLE_CIRWB);
- nvt_cr_write(nvt, val, CR_OUTPUT_PIN_SEL);
+ /* output pin selection: enable CIR, with WB sensor enabled */
+ val = nvt_cr_read(nvt, psreg);
+ val = psmask;
+ val |= psval;
+ nvt_cr_write(nvt, val, psreg);
/* Select CIR logical device and enable */
nvt_select_logical_dev(nvt, LOGICAL_DEV_CIR);
diff --git a/drivers/media/rc/nuvoton-cir.h b/drivers/media/rc/nuvoton-cir.h
index cc8cee3..379795d 100644
--- a/drivers/media/rc/nuvoton-cir.h
+++ b/drivers/media/rc/nuvoton-cir.h
@@ -345,6 +345,7 @@ struct nvt_dev {
#define CR_CHIP_ID_LO 0x21
#define CR_DEV_POWER_DOWN 0x22 /* bit 2 is CIR power, default power on */
#define CR_OUTPUT_PIN_SEL 0x27
+#define CR_MULTIFUNC_PIN_SEL 0x2c
#define CR_LOGICAL_DEV_EN 0x30 /* valid for all logical devices */
/* next three regs valid for both the CIR and CIR_WAKE logical devices */
#define CR_CIR_BASE_ADDR_HI0x60
@@ -368,10 +369,16 @@ struct nvt_dev {
#define CIR_INTR_MOUSE_IRQ_BIT 0x80
#define PME_INTR_CIR_PASS_BIT 0x08
+/* w83677hg CIR pin config */
#define OUTPUT_PIN_SEL_MASK0xbc
#define OUTPUT_ENABLE_CIR 0x01 /* Pin95=CIRRX, Pin96=CIRTX1 */
#define OUTPUT_ENABLE_CIRWB0x40 /* enable wide-band sensor */
+/* w83667hg CIR pin config */
+#define MULTIFUNC_PIN_SEL_MASK 0x1f
+#define MULTIFUNC_ENABLE_CIR 0x80 /* Pin75=CIRRX, Pin76=CIRTX1 */
+#define MULTIFUNC_ENABLE_CIRWB 0x20 /* enable wide-band sensor */
+
/* MCE CIR signal length, related on sample period */
/* MCE CIR controller signal length: about 43ms
--
1.7.1
--
Jarod Wilson
ja...@redhat.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: OMAP3 ISP deadlocks on my new arm
Bastian Hecht wrote: Hello people, Hi Bastian, I'm cc'ing Laurent. I switched to the new DM3730 from IGEP and while it's supposed to be (almost) the same as the 3530 Version the isp deadlocks deterministically after I start capturing the second time with yavta. Does the capture work the first time w/o issues? All extra locking debug output is enabled in the kernel .config. I'm not fully certain on what this exactly is that you have below, but it looks like your system is staying in interrupt context all the time. My guess is that the ISP is producing interrupts that the driver is not handling properly, causing the interrupt handler to be called again immediately. Do you have the same sensor working on OMAP 3530? I am unsure if this is an ISP thing or a problem in the interrupthandling software. This has probably something to do with the ISP driver. :-) The first block is the watchdog that detects the deadlock. The last block is in the isp-code but how can it hang when trying to UNlock a spinlock? I am unsure about the 2nd block. The assembler code of __irq_svc is located in arch/arm/kernel/entry-armv.S Maybe I should try on linux-...@lists.arm.linux.org.uk but I thought I give it a shot here first. I use the omap3isp-2.6.35.3-omap3isp branch from Laurent. Why so old kernel? I think you'd be best off using this one: URL:http://git.linuxtv.org/pinchartl/media.git?a=shortlog;h=refs/heads/omap3isp-next-omap3isp Any ideas? Thanks for any help, Bastian Hecht [ 190.059509] BUG: soft lockup - CPU#0 stuck for 61s! [yavta:2224] [ 190.065704] Kernel panic - not syncing: softlockup: hung tasks [ 190.071563] [c0031078] (unwind_backtrace+0x0/0xe4) from [c02baf24] (panic+0x50/0xd0) [ 190.079711] [c02baf24] (panic+0x50/0xd0) from [c00729e4] (softlockup_tick+0x134/0x158) [ 190.088043] [c00729e4] (softlockup_tick+0x134/0x158) from [c005612c] (update_process_times+0x28/0x48) [ 190.097656] [c005612c] (update_process_times+0x28/0x48) from [c00697bc] (tick_sched_timer+0x88/0xbc) [ 190.107177] [c00697bc] (tick_sched_timer+0x88/0xbc) from [c0061ff0] (__run_hrtimer+0x44/0x84) [ 190.116119] [c0061ff0] (__run_hrtimer+0x44/0x84) from [c0062144] (hrtimer_interrupt+0x114/0x2c8) [ 190.125305] [c0062144] (hrtimer_interrupt+0x114/0x2c8) from [c0035e20] (omap2_gp_timer_interrupt+0x20/0x2c) [ 190.135437] [c0035e20] (omap2_gp_timer_interrupt+0x20/0x2c) from [c00730e4] (handle_IRQ_event+0x24/0xe0) [ 190.145324] [c00730e4] (handle_IRQ_event+0x24/0xe0) from [c0074b80] (handle_level_irq+0x90/0xfc) [ 190.154510] [c0074b80] (handle_level_irq+0x90/0xfc) from [c002c06c] (asm_do_IRQ+0x6c/0x8c) [ 190.163177] [c002c06c] (asm_do_IRQ+0x6c/0x8c) from [c002c9f4] (__irq_svc+0x34/0x80) [ 190.171234] Exception stack(0xda413c98 to 0xda413ce0) [ 190.176300] 3c80: 0020 c03c20d0 [ 190.184509] 3ca0: c0417240 da412000 0002 ded72e84 000a dec54640 [ 190.192718] 3cc0: c0417240 0002 da413ce0 c0051bd4 c0051ad8 2113 [ 190.200958] [c002c9f4] (__irq_svc+0x34/0x80) from [c0051ad8] (__do_softirq+0x3c/0xf8) [ 190.209167] [c0051ad8] (__do_softirq+0x3c/0xf8) from [c0051bd4] (irq_exit+0x40/0x8c) [ 190.217315] [c0051bd4] (irq_exit+0x40/0x8c) from [c002c070] (asm_do_IRQ+0x70/0x8c) [ 190.225280] [c002c070] (asm_do_IRQ+0x70/0x8c) from [c002c9f4] (__irq_svc+0x34/0x80) [ 190.233306] Exception stack(0xda413d20 to 0xda413d68) [ 190.238403] 3d20: defc4938 defc48c0 defc4084 ded72e84 ded72e14 ded72e80 4013 ded72e84 [ 190.246612] 3d40: ded72e68 dec54640 dedc5a38 defc40f8 da413d68 bf01d4cc bf01d4ec [ 190.254821] 3d60: 6013 [ 190.258361] [c002c9f4] (__irq_svc+0x34/0x80) from [bf01d4ec] (omap3isp_video_queue_streamon+0x6c/0x7c [omap3_isp]) [ 190.269165] [bf01d4ec] (omap3isp_video_queue_streamon+0x6c/0x7c [omap3_isp]) from [bf01f1d4] (isp_video_streamon+0x150/0x1f8 [omap3_isp]) [ 190.281951] [bf01f1d4] (isp_video_streamon+0x150/0x1f8 [omap3_isp]) from [c01fa76c] (__video_do_ioctl+0x1488/0x3bd0) [ 190.292877] [c01fa76c] (__video_do_ioctl+0x1488/0x3bd0) from [c01f8ee8] (__video_usercopy+0x2d0/0x414) [ 190.302581] [c01f8ee8] (__video_usercopy+0x2d0/0x414) from [c01f8370] (v4l2_unlocked_ioctl+0x38/0x3c) [ 190.312194] [c01f8370] (v4l2_unlocked_ioctl+0x38/0x3c) from [c00a6d6c] (vfs_ioctl+0x2c/0x6c) [ 190.321044] [c00a6d6c] (vfs_ioctl+0x2c/0x6c) from [c00a7448] (do_vfs_ioctl+0x4cc/0x514) [ 190.329437] [c00a7448] (do_vfs_ioctl+0x4cc/0x514) from [c00a74c4] (sys_ioctl+0x34/0x54) [ 190.337829] [c00a74c4] (sys_ioctl+0x34/0x54) from [c002ce40] (ret_fast_syscall+0x0/0x30) -- 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 Regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia środa 13 kwiecień 2011 o 20:32:31 Russell King - ARM Linux napisał(a): On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote: Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name an ARM based board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf- dma-config susbsystem, c) has a bus structure with which virt_to_phys(bus_to_virt(dma_handle)) is not equal dma_handle? I have no idea - and why should whether someone can name something that may break be a justification to allow something which is technically wrong? Surely it should be the other way around - if its technically wrong and _may_ break something then it shouldn't be allowed. In theory - of course. In practice - couldn't we now, close to -rc3, relax the rules a little bit and stop bothering with something that may break in the future if it doesn't break on any board supported so far (I hope)? I thought so too, but missed the fact that PowerPC implements it actually, even defining the ARCH_HAS_DMA_MMAP_COHERENT symbol, which ARM doesn't so far. So, there's no problem adding that symbol to ARM. OK, I can provide a patch as soon as dma_mmap_coherent() really works for me. Maybe the video drivers should try to resurect the idea, maybe only allowing this support for architectures which provide dma_mmap_coherent(). AFAICT, ARM implementation of dma_mmap_coherent() is not compatible with dma_declare_coherent_memory(), is it? If I'm wrong, please correct me, I'll get back to the idea presented in v1 of the fix. 1. dma_declare_coherent_memory() doesn't work on ARM for memory which already exists (its not permitted to ioremap() the kernel direct-mapped memory due to attribute aliasing issues.) But you had once inspired (http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/034879.html), then was supporting my attempts towards pushing ioremap() out of this function up to the caller (http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036419.html), which would allow for doing sane preallocations via dma_coherent_alloc() and caching them back into dma_declare_coherent_memory() at boot time for later reuse mempry from that pool as DMA coherent. Now, should my attepmts succeded, we would still end up with the following: 2. dma_declare_coherent_memory() totally bypasses the DMA allocator, Would it still, under your terms, if it could accept dma_alloc_coherent() obtained cpu addresses, not trying to ioremap() them? and so dma_mmap_coherent() has no knowledge of how to map the memory. I think it _could_ have a good knowledge if that memory was first preallocated with dma_alloc_coherent() at boot time, unless that memory was then fetched from that pool in smaller chunks. I think this is the reason it didn't work for me when I tried using this method with dma_mmap_coherent(). Am I missing something? If we had a proper way to map DMA memory into userspace, then we wouldn't have these issues as the dma_declare_coherent_memory() would already support that. And actually, talking about dma_declare_coherent_memory(), you've just provided a reason why virt_to_phys(bus_to_virt(dma_handle)) won't work - dma_declare_coherent_memory() can be used to provide on-device memory where the virt/handle may not be mappable with bus_to_virt(). While I have no problems to agree with the principles, I can confirm that this _hack_ does coexist nicely with dma_declare_coherent_memory(), at least on my OMAP1 based board. It also coexists nicely with your WiP patches I mentioned before and you didn't quote here, so I provide the links again: http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036461.html, http://lists.infradead.org/pipermail/linux-arm-kernel/2011-January/036809.html. OTOH, dma_mmap_coherent() didn't work for me when I tried using it on top of those patches. This doesn't mean I'm against a dma_mmap_coherent() based solution. I just think we can't afford switching to it _now_. Otherwise, I think that switching to dma_mmap_coherent() is not an option for the videobuf-dma-contig subsystem as long as there is no good solution to the problem of dma_alloc_coherent() not guaranteed to succeed with high-order allocations at any time. Let me repeat: there is no official API or way to map DMA memory into userspace. Doesn't dma_mmap_coherent(), already available on 2 architectures, ARM and PPC, aim to provide the correct API? From the fact you didn't dispute v1 of my patch, which provided a dma_mmap_coherent() based code path for architectures supporting it, I would conclude this is a solution which might get your support, isn't it? However, I think that even if it was a _proper_ solution to the problem, it couldn't be accepted as a fix during the rc cycle
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia środa 13 kwiecień 2011 o 19:36:30 Sergei Shtylyov napisał(a): Hello. Janusz Krzysztofik wrote: After switching from mem-dma_handle to virt_to_phys(mem-vaddr) used for obtaining page frame number passed to remap_pfn_range() (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig Please specify the commit summary -- for the human readers. Hi, OK, I'll try to reword the summary using a more human friendly language as soon as I have signs that Mauro (who seemed to understand the message well enough) is willing to accept the code. I wasn't asking you to rework your summary but to specify the summary of the commit you've mentioned (in parens). Ah, I see. How about just reordered wording: After commit 35d9f510b67b10338161aba6229d4f55b4000f5b (switching from mem-dma_handle to virt_to_phys(mem-vaddr) used for obtaining page frame number passed to remap_pfn_range()), Do you think this would be clear enough? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia środa 13 kwiecień 2011 o 23:01:55 Janusz Krzysztofik napisał(a): Dnia środa 13 kwiecień 2011 o 19:36:30 Sergei Shtylyov napisał(a): Hello. Janusz Krzysztofik wrote: After switching from mem-dma_handle to virt_to_phys(mem-vaddr) used for obtaining page frame number passed to remap_pfn_range() (commit 35d9f510b67b10338161aba6229d4f55b4000f5b), videobuf-dma-contig Please specify the commit summary -- for the human readers. Hi, OK, I'll try to reword the summary using a more human friendly language as soon as I have signs that Mauro (who seemed to understand the message well enough) is willing to accept the code. I wasn't asking you to rework your summary but to specify the summary of the commit you've mentioned (in parens). Ah, I see. How about just reordered wording: After commit 35d9f510b67b10338161aba6229d4f55b4000f5b (switching from mem-dma_handle to virt_to_phys(mem-vaddr) used for obtaining page frame number passed to remap_pfn_range()), Do you think this would be clear enough? Oh no, I probably missed your point again. You meant just quoting the commit original summary line, didn't you? Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
On Wed, Apr 13, 2011 at 10:56:39PM +0200, Janusz Krzysztofik wrote: Dnia środa 13 kwiecień 2011 o 20:32:31 Russell King - ARM Linux napisał(a): On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote: Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name an ARM based board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf- dma-config susbsystem, c) has a bus structure with which virt_to_phys(bus_to_virt(dma_handle)) is not equal dma_handle? I have no idea - and why should whether someone can name something that may break be a justification to allow something which is technically wrong? Surely it should be the other way around - if its technically wrong and _may_ break something then it shouldn't be allowed. In theory - of course. In practice - couldn't we now, close to -rc3, relax the rules a little bit and stop bothering with something that may break in the future if it doesn't break on any board supported so far (I hope)? If we are worried about closeness to -final, then what should happen is that the original commit is reverted; the fix for IOMMUs resulted in a regression for existing users which isn't trivial to resolve without risking possible breakage of other users. Do we even know whether bus_to_virt(iommu_bus_address) works? I suspect it doesn't, so by doing so you're already re-breaking the IOMMU case. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39 v2] V4L: videobuf-dma-contig: fix mmap_mapper broken on ARM
Dnia czwartek 14 kwiecień 2011 o 00:00:08 Russell King - ARM Linux napisał(a): On Wed, Apr 13, 2011 at 10:56:39PM +0200, Janusz Krzysztofik wrote: Dnia środa 13 kwiecień 2011 o 20:32:31 Russell King - ARM Linux napisał(a): On Wed, Apr 13, 2011 at 12:52:31PM +0200, Janusz Krzysztofik wrote: Taking into account that I'm just trying to fix a regression, and not invent a new, long term solution: are you able to name an ARM based board which a) is already supported in 2.6.39, b) is (or can be) equipped with a device supported by a V4L driver which uses videobuf- dma-config susbsystem, c) has a bus structure with which virt_to_phys(bus_to_virt(dma_handle)) is not equal dma_handle? I have no idea - and why should whether someone can name something that may break be a justification to allow something which is technically wrong? Surely it should be the other way around - if its technically wrong and _may_ break something then it shouldn't be allowed. In theory - of course. In practice - couldn't we now, close to -rc3, relax the rules a little bit and stop bothering with something that may break in the future if it doesn't break on any board supported so far (I hope)? If we are worried about closeness to -final, then what should happen is that the original commit is reverted; the fix for IOMMUs resulted in a regression for existing users which isn't trivial to resolve without risking possible breakage of other users. Do we even know whether bus_to_virt(iommu_bus_address) works? I suspect it doesn't, so by doing so you're already re-breaking the IOMMU case. Hard to deny with only me having actually tested this dirty hack on one single board :) Thanks for your support, Janusz -- 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: TT-budget S2-3200 cannot tune on HB13E DVBS2 transponder
On 05/04/11 21:07, Steffen Barszus wrote:
On Tue, 05 Apr 2011 13:00:14 +0200
Issa Gorissen flop.m@xxx wrote:
Hi,
Eutelsat made a recent migration from DVB-S to DVB-S2 (since
31/3/2011) on two transponders on HB13E
- HOT BIRD 6 13° Est TP 159 Freq 11,681 Ghz DVB-S2 FEC 3/4 27500
Msymb/s 0.2 Pilot off Polar H
- HOT BIRD 9 13° Est TP 99 Freq 12,692 Ghz DVB-S2 FEC 3/4 27500
Msymb/s 0.2 Pilot off Polar H
Before those changes, with my TT S2 3200, I was able to watch TV on
those transponders. Now, I cannot even tune on those transponders. I
have tried with scan-s2 and w_scan and the latest drivers from git.
They both find the transponders but cannot tune onto it.
Something noteworthy is that my other card, a DuoFlex S2 can tune
fine on those transponders.
My question is; can someone try this as well with a TT S2 3200 and
post the results ?
i read something about it lately here (german!):
http://www.vdr-portal.de/board16-video-disk-recorder/board85-hdtv-dvb-s2/p977938-stb0899-fec-3-4-tester-gesucht/#post977938
It says in stb0899_drv.c function:
static void stb0899_set_iterations(struct stb0899_state *state)
This:
reg = STB0899_READ_S2REG(STB0899_S2DEMOD, MAX_ITER);
STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale);
stb0899_write_s2reg(state, STB0899_S2DEMOD, STB0899_BASE_MAX_ITER,
STB0899_OFF0_MAX_ITER, reg);
should be replaced with this:
reg = STB0899_READ_S2REG(STB0899_S2FEC, MAX_ITER);
STB0899_SETFIELD_VAL(MAX_ITERATIONS, reg, iter_scale);
stb0899_write_s2reg(state, STB0899_S2FEC, STB0899_BASE_MAX_ITER,
STB0899_OFF0_MAX_ITER, reg);
Basically replace STB0899_S2DEMOD with STB0899_S2FEC in this 2 lines
affected.
Kind Regards
Steffen
Hi Steffen,
Unfortunately, it does not help in my case. Thx anyway.
Try my locking fix. With above patch I can lock the
channels without problem.
Johns
diff --git a/drivers/media/dvb/frontends/stb0899_algo.c
b/drivers/media/dvb/frontends/stb0899_algo.c
index 2da55ec..55f0c4e 100644
--- a/drivers/media/dvb/frontends/stb0899_algo.c
+++ b/drivers/media/dvb/frontends/stb0899_algo.c
@@ -338,36 +338,42 @@ static enum stb0899_status
stb0899_check_data(struct stb0899_state *state)
int lock = 0, index = 0, dataTime = 500, loop;
u8 reg;
- internal-status = NODATA;
+ reg = stb0899_read_reg(state, STB0899_VSTATUS);
+ lock = STB0899_GETFIELD(VSTATUS_LOCKEDVIT, reg);
+ if ( !lock ) {
- /* RESET FEC*/
- reg = stb0899_read_reg(state, STB0899_TSTRES);
- STB0899_SETFIELD_VAL(FRESACS, reg, 1);
- stb0899_write_reg(state, STB0899_TSTRES, reg);
- msleep(1);
- reg = stb0899_read_reg(state, STB0899_TSTRES);
- STB0899_SETFIELD_VAL(FRESACS, reg, 0);
- stb0899_write_reg(state, STB0899_TSTRES, reg);
+ internal-status = NODATA;
- if (params-srate = 200)
- dataTime = 2000;
- else if (params-srate = 500)
- dataTime = 1500;
- else if (params-srate = 1500)
- dataTime = 1000;
- else
- dataTime = 500;
-
- stb0899_write_reg(state, STB0899_DSTATUS2, 0x00); /* force
search loop */
- while (1) {
- /* WARNING! VIT LOCKED has to be tested before
VIT_END_LOOOP*/
- reg = stb0899_read_reg(state, STB0899_VSTATUS);
- lock = STB0899_GETFIELD(VSTATUS_LOCKEDVIT, reg);
- loop = STB0899_GETFIELD(VSTATUS_END_LOOPVIT, reg);
+ /* RESET FEC*/
+ reg = stb0899_read_reg(state, STB0899_TSTRES);
+ STB0899_SETFIELD_VAL(FRESACS, reg, 1);
+ stb0899_write_reg(state, STB0899_TSTRES, reg);
+ msleep(1);
+ reg = stb0899_read_reg(state, STB0899_TSTRES);
+ STB0899_SETFIELD_VAL(FRESACS, reg, 0);
+ stb0899_write_reg(state, STB0899_TSTRES, reg);
- if (lock || loop || (index dataTime))
- break;
- index++;
+ msleep(1);
+ }
}
if (lock) { /* DATA LOCK indicator */
--
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
KNC ONE DVB-C [1894:0022] can't find any channels, PAT/SDT/NIT filter timeout
Hi, i'm having problems with my new DVB-C device on UPC DVB-C network (Bratislava, Slovakia, encrypted using Conax CAM module inserted in CI slot connected to the DVB-C card): 05:00.0 Multimedia controller [0480]: Philips Semiconductors SAA7146 [1131:7146] (rev 01) Subsystem: KNC One Device [1894:0022] Flags: bus master, medium devsel, latency 64, IRQ 16 Memory at ff70 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget_av Kernel modules: budget-av As you can see, the device is detected and modules loaded : # ls -l /dev/dvb/adapter0 total 0 crw-rw 1 root video 212, 6 Apr 13 23:58 ca0 crw-rw 1 root video 212, 4 Apr 13 23:58 demux0 crw-rw 1 root video 212, 5 Apr 13 23:58 dvr0 crw-rw 1 root video 212, 3 Apr 13 23:58 frontend0 crw-rw 1 root video 212, 7 Apr 13 23:58 net0 # lsmod (i did cut out the unnecessary bits) Module Size Used by sbs 8885 0 sbshc 2712 1 sbs ipv6 244116 33 tda100235443 1 i915 515809 1 budget_av 18830 0 saa7146_vv 38879 1 budget_av drm_kms_helper 23711 1 i915 videodev 72530 1 saa7146_vv drm 144199 2 i915,drm_kms_helper videobuf_dma_sg 6848 1 saa7146_vv videobuf_core 13183 2 saa7146_vv,videobuf_dma_sg budget_core 5956 1 budget_av i2c_algo_bit4304 1 i915 i2c_i8016866 0 dvb_core 75119 2 budget_av,budget_core saa714612490 3 budget_av,saa7146_vv,budget_core serio_raw 3358 0 ttpci_eeprom1364 1 budget_core r8169 34246 0 i2c_core 15854 11 lm75,tda10023,i915,budget_av,drm_kms_helper,videodev,drm,budget_core,i2c_algo_bit,i2c_i801,ttpci_eeprom dmesg: http://pastebin.com/uJDtLGYm The problem is that i can't even successfully scan for channels.To rule out hardware issue, first i tried to use it first with my Windows PC, it worked flawlessly (SD absolutely no problems, HD channels had some minor dropouts due the high bitrate). The result of scan for channels using GlobeTV (the Windows app) was this : http://pastebin.com/XNHvjAfb . Because i'm using a cable operator not listed in /usr/share/dvb files, i need to use w_scan and the result is something like this : http://pastebin.com/0fUS6Tzx . Because of those filter timeouts, it finds no channels using the same cable and card which had no problems on Windows and using the same cable which has no problems with the provided set top box from the cable operator. You might suggest me to use dvbsnoop, but only two commands which work are the signal and feinfo. pidscan returns nothing : # dvbsnoop -s signal dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/ - Transponder/Frequency signal strength statistics... - cycle: 1 d_time: 0.001 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 2 d_time: 0.008 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 3 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 4 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 5 d_time: 0.008 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 6 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 7 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 8 d_time: 0.008 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 9 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 10 d_time: 0.008 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 11 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 12 d_time: 0.008 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 13 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 14 d_time: 0.008 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 15 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 16 d_time: 0.007 s Sig: 65535 SNR: 65535 BER: 1019791 UBLK: -1886417009 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] cycle: 17 d_time: 0.008 s
Re: HVR-1600 (model 74351 rev F1F5) analog Red Screen
On Mon, Apr 11, 2011 at 12:42 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: On Mon, Apr 11, 2011 at 12:32 PM, Eric B Munson emun...@mgebm.net wrote: Can you tune to other known digital channels? I will have to see if I can set one up by hand and try it. I will get back to you when I am able to do this (should be later today). Let me know if you need anything else. Are you tuning digital cable (North American QAM) or digital Over The Air (ATSC)? I am using digital cable (NA QAM). This is going to seem a little nuts, but just as a test could you try sticking the card into a different machine (with a different motherboard)? I heard something a few months ago about an issue related to the power sequencing that only occurred with a specific motherboard. Using any other motherboard resulted in success. It would be useful if we could rule that out. I ruled this out today, my HTPC is using a Biostar G31D-M7 and my desktop is using an ASUS P6X58D and I see the same behavior from the hauppage card in both machines. -- 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
