[PATCH] sh_mobile_ceu_camera: Add physical address alignment checks V2
From: Magnus Damm d...@opensource.se
Make sure physical addresses are 32-bit aligned in the SuperH
Mobile CEU driver V2. The lowest two bits of the frame address
registers are fixed to zero so frame buffers have to be 32-bit
aligned. The V4L2 mmap() case is using dma_alloc_coherent() for
this driver which will return already aligned addresses, but in
the USERPTR case we must make sure that the user space pointer
is valid.
Signed-off-by: Magnus Damm d...@opensource.se
---
Tested with a hacked up capture.c on a sh7722 Migo-R board.
V2 moves the checks to sh_mobile_ceu_videobuf_prepare()
drivers/media/video/sh_mobile_ceu_camera.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
--- 0010/drivers/media/video/sh_mobile_ceu_camera.c
+++ work/drivers/media/video/sh_mobile_ceu_camera.c 2009-12-11
16:52:19.0 +0900
@@ -339,7 +339,7 @@ static int sh_mobile_ceu_videobuf_prepar
}
vb-size = vb-width * vb-height * ((buf-fmt-depth + 7) 3);
- if (0 != vb-baddr vb-bsize vb-size) {
+ if (0 != vb-baddr vb-bsize vb-size !(vb-width 3)) {
ret = -EINVAL;
goto out;
}
@@ -348,6 +348,13 @@ static int sh_mobile_ceu_videobuf_prepar
ret = videobuf_iolock(vq, vb, NULL);
if (ret)
goto fail;
+
+ /* the physical address must be 32-bit aligned (USERPTR) */
+ if (videobuf_to_dma_contig(vb) 3) {
+ ret = -EINVAL;
+ goto fail;
+ }
+
vb-state = VIDEOBUF_PREPARED;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb for the following 2 changesets: 01/02: gspca - some subdrivers: Make device_table[]s constant. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=0ba73f8e8517 02/02: gspca - ov534: Fix a compilation warning. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=612a98aa8eec conex.c |4 ++-- etoms.c |4 ++-- ov534.c |2 +- pac7302.c |4 ++-- pac7311.c |4 ++-- sonixb.c |4 ++-- spca506.c |4 ++-- 7 files changed, 13 insertions(+), 13 deletions(-) Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: [linux-dvb] Hauppauge PVR-150 Vertical sync issue?
On Thu, 2009-12-10 at 11:56 -0500, Robert Longfield wrote: Ok I've been able to do some troubleshooting with some interesting results. I removed the one splitter being used, connected to the main cable coming into the house, isolated the grounds with no change in sync issues. I pulled the pvr-150 card out of the linux machine and put it into my window box, hooked it up to the original setup splitter and no ground isolation and the video is crystal clear with no sync issues. I can only come up with a few possible problems, but I am sure there are more. Could this be a driver issue on my linux box? Given your results, yes it is most likely a linux driver issue. The suspects would be the cx25840 module, or the modules for the analog tuner. What analog tuner assembly type does the tveeprom module show for your card in dmesg? Also what video standard are you capturing: NTSC or something else? Could a bad or failing PCI slot cause this problem? No. A *very* busy PCI bus may cause some I2C transactions that set up the tuner or CX25843 to fail, but it is more likely simply a suboptimal tuner or CX25843 configuration issue. However the sync problem is not on every channel. I'm going to try moving the linux box across the house to see if there is a source of EMI near by, but since the windows box doesn't have this issue I assume this is a problem with the linux box. I suppose you could try a linux liveCD in the Windows box and use $ cat /dev/video0 foo.mpg to capture video. Then move foo.mpg to a USB flash disk and play back foo.mpg where ever it is convenient. If foo.mpg shows artifacts then you can be somewhat sure of a linux driver issue. -Rob On Tue, Nov 24, 2009 at 6:43 PM, Andy Walls awa...@radix.net wrote: On Tue, 2009-11-24 at 13:05 -0500, Robert Longfield wrote: I have a PVR-150 card running on mythbuntu 9 and it appears that my card is suffering a vertical (and possibly a horizontal) sync issue. The video jumps around, shifts from side to side, up and down and when it shifts the video wraps. I'm including a link to a screen shot showing the vertical sync problem http://imagebin.ca/view/6fS-14Yi.html It looks like you have strong singal reflections in your cable due to impedance mismatches, a bad splitter, a bad cable or connector, etc. Please read: http://www.ivtvdriver.org/index.php/Howto:Improve_signal_quality and take steps to ensure you've got a good cabling plant in your home. Regards, Andy This is pretty tame to what happens sometimes. I haven't noticed this on all channels as we are mostly using this to record shows for my son. Here is my setup. Pentium 4 2 Ghz with a gig of ram. 40 gig OS drive, 150 gig drive for recording, 250 gig drive for backup and storage, a dvd-burner. The 150 gig drive is on a Promise Ultra133 TX2 card but exhibits no issues on reads or writes. I have cable connected to the internal tuner of my PVR-150 card and S-video from an Nvidia card (running Nvidea drivers) out to the TV. I don't know what else I can provide to help out but let me know and I'll get it. Thanks, -Rob -- 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] uvcvideo: add another YUYV format GUID
On 11.12.2009 02:21, Laurent Pinchart wrote: On Thursday 10 December 2009 17:34:25 Daniel Ritz wrote: On Thu, 2009-12-10 at 02:46 +0100, Laurent Pinchart wrote: Hi Daniel, On Friday 04 December 2009 03:05:37 Daniel Ritz wrote: Hi Laurent On Thu, 2009-12-03 at 21:15 +0100, Laurent Pinchart wrote: Hi Daniel, On Wednesday 02 December 2009 00:48:44 Daniel Ritz wrote: For some unknown reason, on a MacBookPro5,3 the iSight Could you please send me the output of lsusb -v both with the correct and wrong GUID ? sure. i attached three files: isight-good.txt, isight-bad.txt, isight-good2.txt this is three reboots in a row from like 10 minutes ago. the first boot into linux was actually rebooting from OSX...first cold boot today directly into linux had the right GUID. Thanks. diff'ing the descriptors shows something interesting (from good to good2): @@ -264,7 +264,7 @@ dwMaxVideoFrameBufferSize 614400 dwDefaultFrameInterval 33 bFrameIntervalType 11 -dwFrameInterval( 0) 3758429717 +dwFrameInterval( 0)33 dwFrameInterval( 1)363636 dwFrameInterval( 2)40 dwFrameInterval( 3)44 3758429717 is 0xe0051615 in hex, and 33 is 0x00051615. I wonder what other parts of the descriptors could get corrupted that way. hmm..dunno..but even with this it just worked. _sometimes_ report a different video format GUID. Sometimes only ? Now that's weird. Is that completely random ? yes, sometimes only. it seems to be related to reboots, but i don't know what exactly triggers it. rmmod/modprobe doesn't trigger it. also, when the wrong GUID is reported, the only way of fixing it is to reboot. it really is just the GUID. even when the wrong one is reported, the device works just fine. i started with a plain ubuntu 9.10, kernel 2.6.31 which was supposed to fail, so i upgraded to a 2.6.32-rc8 to fix the iSight and some other things, just to see it fail again. a reboot later and it worked, some time and reboot later it failed again... All of those are warm reboots, and you don't boot any alternative OS in- between, right ? yes, linux only. Does Linux reload the iSight firmware at every boot ? If it does, could you try to reload the firmware manually when you get a bad GUID to see if it helps ? You will probably need to unload the uvcvideo driver before reloading the firmware. linux does not load isight firmware at all. the new macbooks don't require to load FW the device just works. FW loading is only required for the devices with ID 0x05AC:0x8300, what i have is 05ac:8507 Ok, thanks for the information. I guess the camera is really broken. As MacOSX probably doesn't even try to parse the USB descriptors, the Apple developers never noticed. Anyway, I'll apply your patch. Can I still keep your SoB line if I rename YUY2_2 to YUY2_ISIGHT ? sure. thanks, rgds -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
[PULL] http://kernellabs.com/hg/~mkrufky/build-fix
Mauro, Backwards compat got broken a few weeks ago... Please pull for the fix. Please pull from: http://kernellabs.com/hg/~mkrufky/build-fix for: - saa7134: fix build against older kernels saa7134-input.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Cheers, Mike -- 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: TveiiS470 and DVBWorld2005 not working
Guillem Solà wrote: Hi, I come to this list as my last resort. I have two DVB-S PCIE cards and no one can get channels, but I have another computer with a PCI SAA7146 that can get 1400 services from same dish. * Tveii S470 * One is the Tveii S470. I guess that the S470 should work because you are working in IR support. I have tried V4L tip, drivers from website, from website and patched like in wiki says... but all I get is: scandvb -a 0 /usr/share/dvb-apps/dvb-s/Astra-19.2E scanning /usr/share/dvb-apps/dvb-s/Astra-19.2E using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 12551500 V 2200 5 tune to: 12551:v:0:22000 WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x0010it's going on dumping lists (0 services) Done. * DVBWorld 2005 * The other is the DVBWorld DVB-S2 2005. I have tried also latest V4l, liplianin branch... and I get the same: 0 services. The hardware were I'm trying to run this is a Dell 1 unit Rack Server with RHEL with kernels 2.6.30, 2.6.31 and 2.6.32 patched by myself. As I said I have another computer with a PCI dvb-s card that can get lot of channels so I thing that the disk is working well. Any idea about what's going on? Thanks in advance, Guillem Solà Sorry for the noise, The sooner I wrote the email, the sooner my TeviiS470 started to work! I did it work with the latest s2-liplianin tip, of course firmwares were in /lib/firmware dir. Now I'm doing some compatibility tests. As I said I can get a few less channels than with the saa7164 that I'm using in old computers. My aim is to certify it for the company I work for, so if there is something I could do testing it to help the community, I could do it during my work journey. regards, Guillem -- 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
dib0700: Nova-T-500 remote - mixed button codes
Hi all, I own a Hauppauge Nova-T-500 in a box running Mythbuntu 9.10. The card runs fine except when it comes to the in-built remote sensor: Whenever I press any button, the remote sensor seems to receive some other keycodes aside the proper one (i.e. when I press Volume Up button the sensor receives it most of the time, but sometimes it understands some other buttons are pressed like ArrowDown, Red button and so, making MythTV experience very annoying). There are only three buttons that are always well received with no confusion at all: OK, ArrowDown and Play. This behavior occurs with two identical remotes I own (one of them belonging to a WinTV HVR-1100) and another card user has reported a similar behavior with its own and same remote. I tested both remotes with the HVR-1100 and they behave perfectly, so I guess this is not a remote related issue. Though I have tried several LIRC setup files and swapped dvb_usb_dib0700 firmware files (1.10 and 1.20 versions) they make no working difference at all. I also tried rebuilding v4l-dvb code to no avail. Any suggestions? I would gladly provide further info/logs upon request. Cheers, Antonio -- 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
New ASUS P3-100 DVB-T/DVB-S device (1043:48cd)
Hi all, I'm new on this list. I modified on my own the SAA driver to manage an ASUS PS3-100 combo card not supported yet in current version. It features two DVB-S and DVB-T receivers packed on the same PCI card. The DVB-T part is identical to ASUS P7131 Hybrid and therefore is managed thru the existing driver after a light patch in the driver source (and card.c): copying relevant stuff from (1043:4876) to (1043:48cd). I'm not a developper, how to share my successfull experiments ? Regards. -- 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
dib0700: Nova-T-500 remote - mixed button codes
Hi all, I own a Hauppauge Nova-T-500 in a box running Mythbuntu 9.10. The card runs fine except when it comes to the in-built remote sensor: Whenever I press any button, the remote sensor seems to receive some other keycodes aside the proper one (i.e. when I press Volume Up button the sensor receives it most of the time, but sometimes it understands some other buttons are pressed like ArrowDown, Red button and so, making MythTV experience very annoying). There are only three buttons that are always well received with no confusion at all: OK, ArrowDown and Play. This behavior occurs with two identical remotes I own (one of them belonging to a WinTV HVR-1100) and another card user has reported a similar behavior with its own and same remote. I tested both remotes with the HVR-1100 and they behave perfectly, so I guess this is not a remote related issue. Though I have tried several LIRC setup files and swapped dvb_usb_dib0700 firmware files (1.10 and 1.20 versions) they make no working difference at all. I also tried rebuilding v4l-dvb code to no avail. Any suggestions? I would gladly provide further info/logs upon request. Cheers, Antonio -- 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: dib0700: Nova-T-500 remote - mixed button codes
Hi Antonio. Did you switched also the IR remote sensor itself ? I experienced same weird things with a WinovaTV years ago, and finally the IR phototransistor in the small round receiver was crappy. When I changed it by a common spare it all came right. Protect also your IR sensor from AC lights... If you experiment random keys, a noisy IR signal or dead receiver is perhaps the cause. If you experiment always the same button jam, that's something else. Regards. -Message d'origine- De : linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] De la part de Antonio Marcos López Alonso Envoyé : vendredi 11 décembre 2009 16:10 À : linux-media@vger.kernel.org Objet : dib0700: Nova-T-500 remote - mixed button codes Hi all, I own a Hauppauge Nova-T-500 in a box running Mythbuntu 9.10. The card runs fine except when it comes to the in-built remote sensor: Whenever I press any button, the remote sensor seems to receive some other keycodes aside the proper one (i.e. when I press Volume Up button the sensor receives it most of the time, but sometimes it understands some other buttons are pressed like ArrowDown, Red button and so, making MythTV experience very annoying). There are only three buttons that are always well received with no confusion at all: OK, ArrowDown and Play. This behavior occurs with two identical remotes I own (one of them belonging to a WinTV HVR-1100) and another card user has reported a similar behavior with its own and same remote. I tested both remotes with the HVR-1100 and they behave perfectly, so I guess this is not a remote related issue. Though I have tried several LIRC setup files and swapped dvb_usb_dib0700 firmware files (1.10 and 1.20 versions) they make no working difference at all. I also tried rebuilding v4l-dvb code to no avail. Any suggestions? I would gladly provide further info/logs upon request. Cheers, Antonio -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] V4L/DVB: lgs8gxx: Use shifts rather than multiply/divide when possible
If val is a u64, then following:
val *= (u64)1 32;
val /= (u64)1 32;
should surely be better represented as:
val = 32;
val = 32;
Especially as, for the division, the compiler might want to actually do a
division:
drivers/built-in.o: In function `lgs8gxx_get_afc_phase':
drivers/media/dvb/frontends/lgs8gxx.c:250: undefined reference to `__udivdi3'
Signed-off-by: David Howells dhowe...@redhat.com
---
drivers/media/dvb/frontends/lgs8gxx.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/frontends/lgs8gxx.c
b/drivers/media/dvb/frontends/lgs8gxx.c
index eabcadc..dee5396 100644
--- a/drivers/media/dvb/frontends/lgs8gxx.c
+++ b/drivers/media/dvb/frontends/lgs8gxx.c
@@ -199,7 +199,7 @@ static int lgs8gxx_set_if_freq(struct lgs8gxx_state *priv,
u32 freq /*in kHz*/)
val = freq;
if (freq != 0) {
- val *= (u64)1 32;
+ val = 32;
if (if_clk != 0)
do_div(val, if_clk);
v32 = val 0x;
@@ -246,7 +246,7 @@ static int lgs8gxx_get_afc_phase(struct lgs8gxx_state *priv)
val = v32;
val *= priv-config-if_clk_freq;
- val /= (u64)1 32;
+ val = 32;
dprintk(AFC = %u kHz\n, (u32)val);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TveiiS470 and DVBWorld2005 not working
Guillem Aranda wrote: Sorry for the noise, The sooner I wrote the email, the sooner my TeviiS470 started to work! I did it work with the latest s2-liplianin tip, of course firmwares were in /lib/firmware dir. Now I'm doing some compatibility tests. As I said I can get a few less channels than with the saa7164 that I'm using in old computers. My aim is to certify it for the company I work for, so if there is something I could do testing it to help the community, I could do it during my work journey. regards, Guillem On Thu, Dec 10, 2009 at 7:35 PM, Igor M. Liplianin liplia...@me.by mailto:liplia...@me.by wrote: On 10 декабря 2009 18:47:09 Guillem Solà wrote: Hi, I come to this list as my last resort. I have two DVB-S PCIE cards and no one can get channels, but I have another computer with a PCI SAA7146 that can get 1400 services from same dish. * Tveii S470 * One is the Tveii S470. I guess that the S470 should work because you are working in IR support. I have tried V4L tip, drivers from website, from website and patched like in wiki says... but all I get is: scandvb -a 0 /usr/share/dvb-apps/dvb-s/Astra-19.2E scanning /usr/share/dvb-apps/dvb-s/Astra-19.2E using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 12551500 V 2200 5 tune to: 12551:v:0:22000 WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x WARNING: filter timeout pid 0x0010it's going on dumping lists (0 services) Done. * DVBWorld 2005 * The other is the DVBWorld DVB-S2 2005. I have tried also latest V4l, liplianin branch... and I get the same: 0 services. The hardware were I'm trying to run this is a Dell 1 unit Rack Server with RHEL with kernels 2.6.30, 2.6.31 and 2.6.32 patched by myself. As I said I have another computer with a PCI dvb-s card that can get lot of channels so I thing that the disk is working well. Any idea about what's going on? Hi Guillem, I think you are missing firmwares, though you give too little information. Thanks in advance, Guillem Solà -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org mailto:majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks Hi, I have been testing my TeviiS470 against the saa7164 and basically what I get is that the signal and s/n ratio is lower tuning from the same dish with TeviiS470. For example tuning the same channel on each one and comparing the femon output: On saa7164 AragonTv from Astra works well FE: ST STV0299 DVB-S (SAT) status 1f | signal e600 | snr edba | ber | unc | FE_HAS_LOCK status 1f | signal e4c0 | snr ed84 | ber | unc | FE_HAS_LOCK status 1f | signal e73e | snr ed5a | ber | unc | FE_HAS_LOCK status 1f | signal e607 | snr ed0c | ber | unc | FE_HAS_LOCK status 1f | signal e608 | snr ee02 | ber | unc | FE_HAS_LOCK status 1f | signal e607 | snr edf3 | ber | unc | FE_HAS_LOCK On TeviiS470 the same channel have some problems : FE: Montage Technology DS3000/TS2020 (SAT) status 1f | signal 9088 | snr 51e0 | ber | unc 1010 | FE_HAS_LOCK status 1f | signal 9088 | snr 51e0 | ber 3f67 | unc 5669 | FE_HAS_LOCK status 1f | signal 9088 | snr 51e0 | ber 400e | unc 56ed | FE_HAS_LOCK status 00 | signal 9088 | snr 51e0 | ber 3f84 | unc 56ec | status 1f | signal 9088 | snr 51e0 | ber 3ebb | unc 56cb | FE_HAS_LOCK status 1f | signal 9088 | snr 51e0 | ber 4057 | unc 5507 | FE_HAS_LOCK status 1f | signal 9088 | snr 51e0 | ber 4083 | unc 56d1 | FE_HAS_LOCK status 1f | signal 9088 | snr 51e0 | ber 3e63 | unc 56bc | FE_HAS_LOCK status 1f | signal 9088 | snr 51e0 | ber 3fe9 | unc 56be | FE_HAS_LOCK Here femon output of a channel that works better than the last one FE: Montage Technology DS3000/TS2020 (SAT) status 1f | signal 9088 | snr 7ad0 | ber 02dc | unc | FE_HAS_LOCK status 1f | signal 9088 | snr 7ad0 | ber 024a | unc | FE_HAS_LOCK status 1f | signal 9088 | snr 8f48 | ber 0262 | unc | FE_HAS_LOCK status 1f | signal 9088 | snr 8f48 | ber 0314 | unc | FE_HAS_LOCK status 1f | signal 9088 | snr 8f48 | ber 02db | unc | FE_HAS_LOCK status 1f | signal 9088 | snr 8f48 | ber 02ed | unc | FE_HAS_LOCK status 1f | signal 9088 | snr 8f48 | ber 03a3 | unc | FE_HAS_LOCK FE: ST STV0299 DVB-S (SAT) status 1f |
Re: soc_camera: OV2640
Hi Guennadi, On 12/8/09, Alan Carvalho de Assis acas...@gmail.com wrote: Hi Guennadi, ... I am trying to use an OV2640 camera with soc_camera. I'm using ov772x driver as base, but it needs too much modification to work with ov2640. I don't know that sensor specifically, but they can be quite different. Yes, in fact ov2640 appears quite different compared to ov772x and ov9640. The OV2640 chip remaps all registers when register 0xFF is 1 or when it is 0. This is not unusual. There are a few ways to implement this, for example, drivers/media/video/rj54n1cb0c.c uses 16-bit addresses, and decodes them to bank:register pairs in its reg_read() and reg_write() routines. Ok, I will try to implement it this way, case nobody suggests me a better approach. I got mx27_camera from pengutronix tree and modified it to work with kernel 2.6.32 (few modifications). I added platform data/device on my board using pcm970-baseboard.c as example. In the kernel config I selected: CONFIG_VIDEO_MX27 CONFIG_SOC_CAMERA_OV9640 I noticed a strange behavior: the ov9640 driver is called before mx27_camera: Linux video capture interface: v2.00 Probe OK until now, going to ProbeVideo Probing OV9640 Parent missing or invalid! Driver for 1-wire Dallas network protocol. i.MX SDHC driver usbcore: registered new interface driver usbhid usbhid: v2.6:USB HID core driver oprofile: using timer interrupt. TCP cubic registered NET: Registered protocol family 17 mx27-camera mx27-camera.0: initialising mx27_camera: IRQ request OK! mx27_camera: pcdev OK! mx27_camera: clk_csi OK! mx27-camera mx27-camera.0: Camera clock frequency: 2660 mx27_camera: DMA request OK! mx27-camera mx27-camera.0: Using EMMA mx27_camera: probe OK until now! mx27-camera mx27-camera.0: Non-NULL drvdata on register mx27_camera: soc_camera_host_register returned 0! Then ov9640 returns error because icd-dev.parent doesn't exist. Did you already see this issue? Best Regards, Alan -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] soc-camera and mediabus
Hi Mauro, At last soc-camera and mediabus lot for 2.6.33. Note, that one of this patches adds new fourcc codes. A patch for their documentation will be submitted immediately. Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb for the following 30 changesets: 01/30: tw9910: The driver can also handle revision 1 of the chip http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f1e67c4ca734 02/30: soc-camera: remove no longer needed struct members http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ac42a43c9d3c 03/30: v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in soc-camera http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f3ce29815a19 04/30: soc-camera: fix multi-line comment coding style http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=e893641bb109 05/30: sh_mobile_ceu_camera: do not mark host occupied, when adding a client fails http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=9505453960fb 06/30: v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc codes http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=fc70aabadc59 07/30: soc-camera: add a private field to struct soc_camera_link http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8144ecd97132 08/30: Subject: kernel-sync for arch/sh/boards/mach-ap325rxa/setup.c http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ea27f790755c 09/30: soc-camera: switch drivers and platforms to use .priv in struct soc_camera_link http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=54707961f633 10/30: sh_mobile_ceu_camera: document the scaling and cropping algorithm http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f490679b43c3 11/30: tw9910: Add revision control http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4d27f0bec0f3 12/30: tw9910: simplify chip ID calculation http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=b919641bdf84 13/30: tw9910: Tri-state pins when idle http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=bb97c53db3c0 14/30: tw9910: Add power control http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2d8774ea617f 15/30: tw9910: tw9910_set_hsync clean up http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=669d0a9ca121 16/30: tw9910: Add revision control to tw9910_set_hsync http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d3619f5f5679 17/30: v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2c60bd900a7a 18/30: soc-camera: convert to the new mediabus API http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2a8289e3de7b 19/30: Subject: kernel-sync for arch/sh/boards/mach-kfr2r09/setup.c http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4e1dcff622e0 20/30: rj54n1cb0c: Add cropping, auto white balance, restrict sizes, add platform data http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c2ede215a03c 21/30: mt9t031: make the use of the soc-camera client API optional http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be8b7a9252d8 22/30: sh_mobile_ceu: Add V4L2_FIELD_INTERLACED_BT/TB support http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1a36ae75bdb1 23/30: tw9910: use V4L2_FIELD_INTERLACED_BT http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be43ab8c8490 24/30: sh_mobile_ceu_camera: Add support for sync polarity selection http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=596e9b685f9b 25/30: tw9910: modify V/H outpit pin setting to use VALID http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8e7ca505b942 26/30: tw9910: modify output format http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a42544f649b1 27/30: tw9910: remove cropping http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c141cc75045a 28/30: tw9910: Add sync polarity support http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=750376b279e0 29/30: soc-camera: Add mt9t112 camera driver http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=37cdd4e97937 30/30: sh_mobile_ceu_camera: Remove frame size page alignment http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8da6f7deee9f a/linux/arch/sh/boards/board-ap325rxa.c| 606 -- b/linux/Documentation/video4linux/sh_mobile_ceu_camera.txt | 157 + b/linux/arch/sh/boards/mach-ap325rxa/setup.c | 657 +++ b/linux/arch/sh/boards/mach-kfr2r09/setup.c| 622 ++ b/linux/drivers/media/video/mt9t112.c | 1177 + b/linux/drivers/media/video/soc_mediabus.c | 157 + b/linux/include/media/mt9t112.h| 30 b/linux/include/media/rj54n1cb0c.h | 19
[PATCH] document new pixel formats
Document all four 10-bit Bayer formats, 10-bit monochrome and a missing
8-bit Bayer formats.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Notice, this is a linux git patch, so, it includes manual additions to
media-entities.tmpl, which will hopefully not be needed for hg. I'm also
adding all four 10-bit Bayer formats here, including the
V4L2_PIX_FMT_SGRBG10, which is already documented in pixfmt.xml. We can
remove that bit then.
diff --git a/Documentation/DocBook/media-entities.tmpl
b/Documentation/DocBook/media-entities.tmpl
index bb5ab74..5524e32 100644
--- a/Documentation/DocBook/media-entities.tmpl
+++ b/Documentation/DocBook/media-entities.tmpl
@@ -222,8 +222,11 @@
!ENTITY sub-sbggr8 SYSTEM v4l/pixfmt-sbggr8.xml
!ENTITY sub-sgbrg8 SYSTEM v4l/pixfmt-sgbrg8.xml
!ENTITY sub-sgrbg8 SYSTEM v4l/pixfmt-sgrbg8.xml
+!ENTITY sub-srggb8 SYSTEM v4l/pixfmt-srggb8.xml
+!ENTITY sub-srggb10 SYSTEM v4l/pixfmt-srggb10.xml
!ENTITY sub-uyvy SYSTEM v4l/pixfmt-uyvy.xml
!ENTITY sub-vyuy SYSTEM v4l/pixfmt-vyuy.xml
+!ENTITY sub-y10 SYSTEM v4l/pixfmt-y10.xml
!ENTITY sub-y16 SYSTEM v4l/pixfmt-y16.xml
!ENTITY sub-y41p SYSTEM v4l/pixfmt-y41p.xml
!ENTITY sub-yuv410 SYSTEM v4l/pixfmt-yuv410.xml
@@ -313,8 +316,11 @@
!ENTITY sbggr8 SYSTEM v4l/pixfmt-sbggr8.xml
!ENTITY sgbrg8 SYSTEM v4l/pixfmt-sgbrg8.xml
!ENTITY sgrbg8 SYSTEM v4l/pixfmt-sgrbg8.xml
+!ENTITY srggb8 SYSTEM v4l/pixfmt-srggb8.xml
+!ENTITY srggb10 SYSTEM v4l/pixfmt-srggb10.xml
!ENTITY uyvy SYSTEM v4l/pixfmt-uyvy.xml
!ENTITY vyuy SYSTEM v4l/pixfmt-vyuy.xml
+!ENTITY y10 SYSTEM v4l/pixfmt-y10.xml
!ENTITY y16 SYSTEM v4l/pixfmt-y16.xml
!ENTITY y41p SYSTEM v4l/pixfmt-y41p.xml
!ENTITY yuv410 SYSTEM v4l/pixfmt-yuv410.xml
diff --git a/Documentation/DocBook/v4l/pixfmt-srggb10.xml
b/Documentation/DocBook/v4l/pixfmt-srggb10.xml
new file mode 100644
index 000..1be1815
--- /dev/null
+++ b/Documentation/DocBook/v4l/pixfmt-srggb10.xml
@@ -0,0 +1,98 @@
+refentry
+ refmeta
+ refentrytitleV4L2_PIX_FMT_SRGGB10 ('RG10'),
+V4L2_PIX_FMT_SGRBG10 ('BA10'),
+V4L2_PIX_FMT_SGBRG10 ('GB10'),
+V4L2_PIX_FMT_SBGGR10 ('BG10'),
+/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refname
id=V4L2-PIX-FMT-SRGGB10constantV4L2_PIX_FMT_SRGGB10/constant/refname
+ refname
id=V4L2-PIX-FMT-SGRBG10constantV4L2_PIX_FMT_SGRBG10/constant/refname
+ refname
id=V4L2-PIX-FMT-SGBRG10constantV4L2_PIX_FMT_SGBRG10/constant/refname
+ refname
id=V4L2-PIX-FMT-SBGGR10constantV4L2_PIX_FMT_SBGGR10/constant/refname
+ refpurpose10-bit Bayer formats expanded to 16 bits/refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+
+ paraThe following four pixel formats are raw sRGB / Bayer formats with
+10 bits per colour. Each colour component is stored in a 16-bit word, with 6
+unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
+and n/2 blue or red samples, with alternating red and blue rows. Bytes are
+stored in memory in little endian order. They are conventionally described
+as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
+formats/para
+
+example
+ titleconstantV4L2_PIX_FMT_SBGGR10/constant 4 times; 4
+pixel image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte, high 6 bits in high bytes are 0.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystartnbsp;+nbsp;0:/entry
+ entryBsubscript00low/subscript/entry
+ entryBsubscript00high/subscript/entry
+ entryGsubscript01low/subscript/entry
+ entryGsubscript01high/subscript/entry
+ entryBsubscript02low/subscript/entry
+ entryBsubscript02high/subscript/entry
+ entryGsubscript03low/subscript/entry
+ entryGsubscript03high/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;8:/entry
+ entryGsubscript10low/subscript/entry
+ entryGsubscript10high/subscript/entry
+ entryRsubscript11low/subscript/entry
+ entryRsubscript11high/subscript/entry
+ entryGsubscript12low/subscript/entry
+ entryGsubscript12high/subscript/entry
+ entryRsubscript13low/subscript/entry
+ entryRsubscript13high/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;16:/entry
+ entryBsubscript20low/subscript/entry
+ entryBsubscript20high/subscript/entry
+ entryGsubscript21low/subscript/entry
+ entryGsubscript21high/subscript/entry
+ entryBsubscript22low/subscript/entry
+
Re: soc_camera: OV2640
On Fri, 11 Dec 2009, Alan Carvalho de Assis wrote: Hi Guennadi, On 12/8/09, Alan Carvalho de Assis acas...@gmail.com wrote: Hi Guennadi, ... I am trying to use an OV2640 camera with soc_camera. I'm using ov772x driver as base, but it needs too much modification to work with ov2640. I don't know that sensor specifically, but they can be quite different. Yes, in fact ov2640 appears quite different compared to ov772x and ov9640. The OV2640 chip remaps all registers when register 0xFF is 1 or when it is 0. This is not unusual. There are a few ways to implement this, for example, drivers/media/video/rj54n1cb0c.c uses 16-bit addresses, and decodes them to bank:register pairs in its reg_read() and reg_write() routines. Ok, I will try to implement it this way, case nobody suggests me a better approach. I got mx27_camera from pengutronix tree and modified it to work with kernel 2.6.32 (few modifications). Sorry, I cannot help you with an out-of-tree driver, and generally I would expect significant changes when going to 2.6.32. I added platform data/device on my board using pcm970-baseboard.c as example. In the kernel config I selected: CONFIG_VIDEO_MX27 CONFIG_SOC_CAMERA_OV9640 I noticed a strange behavior: the ov9640 driver is called before mx27_camera: Linux video capture interface: v2.00 Probe OK until now, going to ProbeVideo Probing OV9640 Parent missing or invalid! Driver for 1-wire Dallas network protocol. i.MX SDHC driver usbcore: registered new interface driver usbhid usbhid: v2.6:USB HID core driver oprofile: using timer interrupt. TCP cubic registered NET: Registered protocol family 17 mx27-camera mx27-camera.0: initialising mx27_camera: IRQ request OK! mx27_camera: pcdev OK! mx27_camera: clk_csi OK! mx27-camera mx27-camera.0: Camera clock frequency: 2660 mx27_camera: DMA request OK! mx27-camera mx27-camera.0: Using EMMA mx27_camera: probe OK until now! mx27-camera mx27-camera.0: Non-NULL drvdata on register mx27_camera: soc_camera_host_register returned 0! Then ov9640 returns error because icd-dev.parent doesn't exist. Did you already see this issue? 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: linux-next: Tree for December 11 (media/dvb/frontends)
On Fri, 11 Dec 2009 16:01:51 +1100 Stephen Rothwell wrote: Hi all, My usual call for calm: please do not put stuff destined for 2.6.34 into linux-next trees until after 2.6.33-rc1. Changes since 20091210: drivers/media/dvb/frontends/dib0090.h:103: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'frontend_tune_state' static inline num frontend_tune_state dib0090_get_tune_state(struct dvb_frontend *fe) s/num/enum/ drivers/media/dvb/frontends/dib8000.h:104: error: expected expression before '}' token drivers/media/dvb/frontends/dib8000.h:104: warning: left-hand operand of comma expression has no effect return CT_SHUTDOWN, s/,/;/ and use tab to indent. someone built/tested these?? --- ~Randy -- 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: OV2640
Hi Guennadi, On 12/11/09, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Fri, 11 Dec 2009, Alan Carvalho de Assis wrote: I got mx27_camera from pengutronix tree and modified it to work with kernel 2.6.32 (few modifications). Sorry, I cannot help you with an out-of-tree driver, and generally I would expect significant changes when going to 2.6.32. Right, I can post a patch to add mx27_camera on mainstream kernel since Sascha (original author) let me do it. Sascha, can I submit it? Best Regards, Alan -- 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 - v1 1/2] V4L - vpfe capture - make clocks configurable
Karicheri, Muralidharan m-kariche...@ti.com writes:
Kevin,
I think I have figured it out...
First issue was that I was adding my entry at the end of dm644x_clks[]
array. I need to add it before the CLK(NULL, NULL, NULL)
secondly, your suggestion didn't work as is. This is what I had to
do to get it working...
static struct clk ccdc_master_clk = {
.name = dm644x_ccdc,
.parent = vpss_master_clk,
};
static struct clk ccdc_slave_clk = {
.name = dm644x_ccdc,
.parent = vpss_slave_clk,
};
It doesn't work with out doing this. The cat /proc/davinci_clocks hangs with
your suggestion implemented...
Can you track down the hang. It sounds like a bug in the walking of
the clock tree for davinci_clocks.
You should not need to add new clocks with new names. I don't thinke
the name field of the struct clk is used anywhere in the matching.
I think it's only used in /proc/davinci_clocks
static struct davinci_clk dm365_clks = {
CLK(dm644x_ccdc, master, ccdc_master_clk),
CLK(dm644x_ccdc, slave, ccdc_slave_clk),
Looks like the drivers name is 'dm644x_ccdc', not 'isif'. I'm
guessing just this should work without having to add new clock names.
No. I have mixed up the names. ISIF is for the new ISIF driver on DM365.
Below are for DM644x ccdc driver. With just these entries added, two
things observed
1) Only one clock is shown disabled (usually many are shown disabled) during
bootup
2) cat /proc/davinci_clocks hangs.
So this is the only way I got it working.
Hmm, it worked just fine for me without any of these side effects. I
applied the simple patch below on top of current master branch. It booted
fine showing all the unused clocks being disabled, and I was able to
see davinci_clocks just fine:
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index e65e29e..e6f3570 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -293,8 +293,8 @@ struct davinci_clk dm644x_clks[] = {
CLK(NULL, dsp, dsp_clk),
CLK(NULL, arm, arm_clk),
CLK(NULL, vicp, vicp_clk),
- CLK(NULL, vpss_master, vpss_master_clk),
- CLK(NULL, vpss_slave, vpss_slave_clk),
+ CLK(dm644x_ccdc, master, vpss_master_clk),
+ CLK(dm644x_ccdc, slave, vpss_slave_clk),
CLK(NULL, arm, arm_clk),
CLK(NULL, uart0, uart0_clk),
CLK(NULL, uart1, uart1_clk),
[...]
Clocks: disable unused uart1
Clocks: disable unused uart2
Clocks: disable unused emac
Clocks: disable unused ide
Clocks: disable unused asp0
Clocks: disable unused mmcsd
Clocks: disable unused spi
Clocks: disable unused usb
Clocks: disable unused vlynq
Clocks: disable unused pwm0
Clocks: disable unused pwm1
Clocks: disable unused pwm2
Clocks: disable unused timer1
[...]
r...@dm644x:~# uname -r
2.6.32-arm-davinci-default-06873-g1a7277b-dirty
r...@dm644x:~# cat /debug/davinci_clocks
ref_clk users= 8 2700 Hz
pll1users= 8 pll 59400 Hz
pll1_sysclk1 users= 0 pll 59400 Hz
dsp users= 1 psc 59400 Hz
pll1_sysclk2 users= 2 pll 29700 Hz
arm users= 2 psc 29700 Hz
pll1_sysclk3 users= 0 pll 19800 Hz
vpss_master users= 0 psc 19800 Hz
vpss_slave users= 0 psc 19800 Hz
pll1_sysclk5 users= 3 pll 9900 Hz
emacusers= 1 psc 9900 Hz
ide users= 0 psc 9900 Hz
asp0users= 0 psc 9900 Hz
mmcsd users= 0 psc 9900 Hz
spi users= 0 psc 9900 Hz
gpiousers= 1 psc 9900 Hz
usb
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: 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:Fri Dec 11 19:00:05 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13611:db37ff59927f gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.32-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: ERRORS linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: ERRORS linux-2.6.27-i686: ERRORS linux-2.6.28-i686: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30-i686: OK linux-2.6.31-i686: OK linux-2.6.32-i686: OK linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.30-mips: OK linux-2.6.31-mips: OK linux-2.6.32-mips: ERRORS linux-2.6.30-powerpc64: OK linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: OK linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: ERRORS linux-2.6.27-x86_64: ERRORS linux-2.6.28-x86_64: ERRORS linux-2.6.29.1-x86_64: ERRORS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: OK linux-2.6.32-x86_64: OK spec: OK sparse (linux-2.6.32): ERRORS linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.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
[SOLVED] dib0700: Nova-T-500 remote - mixed button codes
Spot on, Christophe! I didn't realize I have not tried swapping the sensor wires and this little damned thing is working now! However I must point the faulty sensor wire works right with the HVR-1100. I cannot tell which sensor belongs to which card (both of them are identical except the working Nova-T-500 wire that shows a label with what seems to be a P/N or a S/N on it) so I suppose the Nova-T-500 wire works well with the HVR-1100 but not the opposite (maybe a bandwidth issue). To support this theory there is the fact that the spurious keycodes are not random but always the same per remote button (but the happening frequency is random indeed). Thanks a lot for your help! Antonio El Viernes 11 Diciembre 2009, Rochet, Christophe escribió: Hi Antonio. Did you switched also the IR remote sensor itself ? I experienced same weird things with a WinovaTV years ago, and finally the IR phototransistor in the small round receiver was crappy. When I changed it by a common spare it all came right. Protect also your IR sensor from AC lights... If you experiment random keys, a noisy IR signal or dead receiver is perhaps the cause. If you experiment always the same button jam, that's something else. Regards. -Message d'origine- De : linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] De la part de Antonio Marcos López Alonso Envoyé : vendredi 11 décembre 2009 16:10 À : linux-media@vger.kernel.org Objet : dib0700: Nova-T-500 remote - mixed button codes Hi all, I own a Hauppauge Nova-T-500 in a box running Mythbuntu 9.10. The card runs fine except when it comes to the in-built remote sensor: Whenever I press any button, the remote sensor seems to receive some other keycodes aside the proper one (i.e. when I press Volume Up button the sensor receives it most of the time, but sometimes it understands some other buttons are pressed like ArrowDown, Red button and so, making MythTV experience very annoying). There are only three buttons that are always well received with no confusion at all: OK, ArrowDown and Play. This behavior occurs with two identical remotes I own (one of them belonging to a WinTV HVR-1100) and another card user has reported a similar behavior with its own and same remote. I tested both remotes with the HVR-1100 and they behave perfectly, so I guess this is not a remote related issue. Though I have tried several LIRC setup files and swapped dvb_usb_dib0700 firmware files (1.10 and 1.20 versions) they make no working difference at all. I also tried rebuilding v4l-dvb code to no avail. Any suggestions? I would gladly provide further info/logs upon request. Cheers, Antonio -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: [stable] [PATCH] ov511: fix probe() hang due to double mutex_lock
On 19:32 Thu 10 Dec 2009, Greg KH wrote: On Thu, Dec 10, 2009 at 05:04:49PM -0800, Brandon Philips wrote: Commit 163fe744c3283fd267268629afff4cfc846ed0e0 added a double mutex_lock which hangs ov51x_probe(). This was clearly a typo. Change final mutex_lock() - mutex_unlock() Signed-off-by: Brandon Philips bphil...@suse.de Brandon, when you want patches to be added to the stable tree, just add a: Cc: stable sta...@kernel.org to the signed-off-by area of the patch. That way, when they get merged into Linus's tree eventually, they will be automagically sent to the sta...@kernel.org alias, so I know to add it to the tree at that time. It saves you time, and me time, so I don't have to go hunt for this upstream sometime in the future. That is a handy feature. It might be nice to document it in the -stable documentation. See patch below for an attempt. I will ping stable again on this patch once this reaches Linus's tree so you don't need to track it. Sorry for messing up the stable procedure. :D Thanks, Brandon diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt index a452227..5d24504 100644 --- a/Documentation/stable_kernel_rules.txt +++ b/Documentation/stable_kernel_rules.txt @@ -36,6 +36,23 @@ Procedure for submitting patches to the -stable tree: - Security patches should not be sent to this alias, but instead to the documented secur...@kernel.org address. +Submitting to -stable automatically upon reaching Linus's tree: + + - As mentioned above, patches must be merged into Linus's tree before being + considered for -stable. But, if you are sending a patch for inclusion + into Linus's tree that you know you will eventually submit to -stable when + it is merged then you can save yourself the trouble of tracking the patch by + adding: + + Cc: stable sta...@kernel.org + + in the signed-off-by area of the patch. Then once it is merged with Linus + an email with the patch will be sent to sta...@kernel.org automatically. + + This only works for patches that are for both -stable and Linus's tree at + the time of submission. If a fix has already made its way into Linus's tree + or a maintainer's queue for Linus's tree then follow the regular submission + rules outlined above. Review cycle: -- 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 - v1 1/2] V4L - vpfe capture - make clocks configurable
Kevin,
That is what I had seen. I will check it again on Monday
and let you know.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Friday, December 11, 2009 1:35 PM
To: Karicheri, Muralidharan
Cc: davinci-linux-open-sou...@linux.davincidsp.com; linux-
me...@vger.kernel.org
Subject: Re: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable
Karicheri, Muralidharan m-kariche...@ti.com writes:
Kevin,
I think I have figured it out...
First issue was that I was adding my entry at the end of dm644x_clks[]
array. I need to add it before the CLK(NULL, NULL, NULL)
secondly, your suggestion didn't work as is. This is what I had to
do to get it working...
static struct clk ccdc_master_clk = {
.name = dm644x_ccdc,
.parent = vpss_master_clk,
};
static struct clk ccdc_slave_clk = {
.name = dm644x_ccdc,
.parent = vpss_slave_clk,
};
It doesn't work with out doing this. The cat /proc/davinci_clocks hangs
with
your suggestion implemented...
Can you track down the hang. It sounds like a bug in the walking of
the clock tree for davinci_clocks.
You should not need to add new clocks with new names. I don't thinke
the name field of the struct clk is used anywhere in the matching.
I think it's only used in /proc/davinci_clocks
static struct davinci_clk dm365_clks = {
CLK(dm644x_ccdc, master, ccdc_master_clk),
CLK(dm644x_ccdc, slave, ccdc_slave_clk),
Looks like the drivers name is 'dm644x_ccdc', not 'isif'. I'm
guessing just this should work without having to add new clock names.
No. I have mixed up the names. ISIF is for the new ISIF driver on DM365.
Below are for DM644x ccdc driver. With just these entries added, two
things observed
1) Only one clock is shown disabled (usually many are shown disabled)
during bootup
2) cat /proc/davinci_clocks hangs.
So this is the only way I got it working.
Hmm, it worked just fine for me without any of these side effects. I
applied the simple patch below on top of current master branch. It booted
fine showing all the unused clocks being disabled, and I was able to
see davinci_clocks just fine:
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-
davinci/dm644x.c
index e65e29e..e6f3570 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -293,8 +293,8 @@ struct davinci_clk dm644x_clks[] = {
CLK(NULL, dsp, dsp_clk),
CLK(NULL, arm, arm_clk),
CLK(NULL, vicp, vicp_clk),
- CLK(NULL, vpss_master, vpss_master_clk),
- CLK(NULL, vpss_slave, vpss_slave_clk),
+ CLK(dm644x_ccdc, master, vpss_master_clk),
+ CLK(dm644x_ccdc, slave, vpss_slave_clk),
CLK(NULL, arm, arm_clk),
CLK(NULL, uart0, uart0_clk),
CLK(NULL, uart1, uart1_clk),
[...]
Clocks: disable unused uart1
Clocks: disable unused uart2
Clocks: disable unused emac
Clocks: disable unused ide
Clocks: disable unused asp0
Clocks: disable unused mmcsd
Clocks: disable unused spi
Clocks: disable unused usb
Clocks: disable unused vlynq
Clocks: disable unused pwm0
Clocks: disable unused pwm1
Clocks: disable unused pwm2
Clocks: disable unused timer1
[...]
r...@dm644x:~# uname -r
2.6.32-arm-davinci-default-06873-g1a7277b-dirty
r...@dm644x:~# cat /debug/davinci_clocks
ref_clk users= 8 2700 Hz
pll1users= 8 pll 59400 Hz
pll1_sysclk1 users= 0 pll 59400 Hz
dsp users= 1 psc 59400 Hz
pll1_sysclk2 users= 2 pll 29700 Hz
arm users= 2 psc 29700 Hz
pll1_sysclk3 users= 0 pll 19800 Hz
vpss_master users= 0 psc 19800 Hz
vpss_slave users= 0 psc 19800 Hz
pll1_sysclk5 users= 3 pll 9900 Hz
emacusers= 1 psc 9900 Hz
ide users= 0 psc 9900 Hz
asp0users= 0 psc 9900 Hz
mmcsd users= 0 psc 9900 Hz
spi users= 0 psc 9900 Hz
gpiousers= 1 psc 9900 Hz
usb users= 0 psc 9900 Hz
vlynq users= 0 psc 9900 Hz
aemif users= 1 psc 9900 Hz
pll1_aux_clk users= 3 pll 2700 Hz
uart0 users= 1 psc 2700 Hz
uart1 users= 0 psc 2700 Hz
uart2 users= 0 psc 2700 Hz
i2c users= 1 psc 2700 Hz
pwm0users= 0 psc 2700 Hz
pwm1users= 0 psc 2700 Hz
pwm2users= 0 psc 2700 Hz
timer0 users= 1 psc 2700 Hz
timer1 users= 0 psc 2700 Hz
timer2 users= 1 psc 2700 Hz
pll1_sysclkbp users= 0 pll 2700 Hz
pll2users= 0 pll 64800 Hz
pll2_sysclk1 users= 0 pll 5400 Hz
pll2_sysclk2 users= 0 pll 32400 Hz
pll2_sysclkbp users= 0 pll 1350 Hz
r...@dm644x:~#
--
Re: Latest stack that can be merged on top of linux-next tree
Hi 2009/12/11 Karicheri, Muralidharan m-kariche...@ti.com: Hi, Thanks for the response. One more question that I have is if the devices on the two buses can use the same i2c address. That is the case for my board. So wondering if this works as well. That is IMHO exactly reason of existence such expanders. We, for example have two DVB-S2 tuners, using totally same i2c addresses (for demod pll). If you are carefull and access such devices only using those virtual i2c buses, then you not need to manage switching between them at all. It is job for pca954x driver. Simple and easy :) /Honza -- 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] dib8000: make some constant static
From: Márton Németh nm...@freemail.hu
Eliminate the following sparse warnings (see make C=1):
* dib8000.c:125:15: warning: symbol 'coeff_2k_sb_1seg_dqpsk' was not declared.
Should it be static?
* dib8000.c:130:15: warning: symbol 'coeff_2k_sb_1seg' was not declared.
Should it be static?
* dib8000.c:134:15: warning: symbol 'coeff_2k_sb_3seg_0dqpsk_1dqpsk' was not
declared. Should it be static?
* dib8000.c:139:15: warning: symbol 'coeff_2k_sb_3seg_0dqpsk' was not
declared. Should it be static?
* dib8000.c:144:15: warning: symbol 'coeff_2k_sb_3seg_1dqpsk' was not
declared. Should it be static?
* dib8000.c:149:15: warning: symbol 'coeff_2k_sb_3seg' was not declared.
Should it be static?
* dib8000.c:154:15: warning: symbol 'coeff_4k_sb_1seg_dqpsk' was not declared.
Should it be static?
* dib8000.c:159:15: warning: symbol 'coeff_4k_sb_1seg' was not declared.
Should it be static?
* dib8000.c:164:15: warning: symbol 'coeff_4k_sb_3seg_0dqpsk_1dqpsk' was not
declared. Should it be static?
* dib8000.c:169:15: warning: symbol 'coeff_4k_sb_3seg_0dqpsk' was not
declared. Should it be static?
* dib8000.c:174:15: warning: symbol 'coeff_4k_sb_3seg_1dqpsk' was not
declared. Should it be static?
* dib8000.c:179:15: warning: symbol 'coeff_4k_sb_3seg' was not declared.
Should it be static?
* dib8000.c:184:15: warning: symbol 'coeff_8k_sb_1seg_dqpsk' was not declared.
Should it be static?
* dib8000.c:189:15: warning: symbol 'coeff_8k_sb_1seg' was not declared.
Should it be static?
* dib8000.c:194:15: warning: symbol 'coeff_8k_sb_3seg_0dqpsk_1dqpsk' was not
declared. Should it be static?
* dib8000.c:199:15: warning: symbol 'coeff_8k_sb_3seg_0dqpsk' was not
declared. Should it be static?
* dib8000.c:204:15: warning: symbol 'coeff_8k_sb_3seg_1dqpsk' was not
declared. Should it be static?
* dib8000.c:209:15: warning: symbol 'coeff_8k_sb_3seg' was not declared.
Should it be static?
* dib8000.c:214:15: warning: symbol 'ana_fe_coeff_3seg' was not declared.
Should it be static?
* dib8000.c:218:15: warning: symbol 'ana_fe_coeff_1seg' was not declared.
Should it be static?
* dib8000.c:222:15: warning: symbol 'ana_fe_coeff_13seg' was not declared.
Should it be static?
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r f5662ce08663 linux/drivers/media/dvb/frontends/dib8000.c
--- a/linux/drivers/media/dvb/frontends/dib8000.c Fri Dec 11 09:53:41
2009 +0100
+++ b/linux/drivers/media/dvb/frontends/dib8000.c Fri Dec 11 23:33:26
2009 +0100
@@ -122,104 +122,104 @@
return dib8000_i2c_write16(state-i2c, reg, val);
}
-const int16_t coeff_2k_sb_1seg_dqpsk[8] = {
+static const int16_t coeff_2k_sb_1seg_dqpsk[8] = {
(769 5) | 0x0a, (745 5) | 0x03, (595 5) | 0x0d, (769 5) |
0x0a, (920 5) | 0x09, (784 5) | 0x02, (519 5) | 0x0c,
(920 5) | 0x09
};
-const int16_t coeff_2k_sb_1seg[8] = {
+static const int16_t coeff_2k_sb_1seg[8] = {
(692 5) | 0x0b, (683 5) | 0x01, (519 5) | 0x09, (692 5) |
0x0b, 0 | 0x1f, 0 | 0x1f, 0 | 0x1f, 0 | 0x1f
};
-const int16_t coeff_2k_sb_3seg_0dqpsk_1dqpsk[8] = {
+static const int16_t coeff_2k_sb_3seg_0dqpsk_1dqpsk[8] = {
(832 5) | 0x10, (912 5) | 0x05, (900 5) | 0x12, (832 5) |
0x10, (-931 5) | 0x0f, (912 5) | 0x04, (807 5) | 0x11,
(-931 5) | 0x0f
};
-const int16_t coeff_2k_sb_3seg_0dqpsk[8] = {
+static const int16_t coeff_2k_sb_3seg_0dqpsk[8] = {
(622 5) | 0x0c, (941 5) | 0x04, (796 5) | 0x10, (622 5) |
0x0c, (982 5) | 0x0c, (519 5) | 0x02, (572 5) | 0x0e,
(982 5) | 0x0c
};
-const int16_t coeff_2k_sb_3seg_1dqpsk[8] = {
+static const int16_t coeff_2k_sb_3seg_1dqpsk[8] = {
(699 5) | 0x14, (607 5) | 0x04, (944 5) | 0x13, (699 5) |
0x14, (-720 5) | 0x0d, (640 5) | 0x03, (866 5) | 0x12,
(-720 5) | 0x0d
};
-const int16_t coeff_2k_sb_3seg[8] = {
+static const int16_t coeff_2k_sb_3seg[8] = {
(664 5) | 0x0c, (925 5) | 0x03, (937 5) | 0x10, (664 5) |
0x0c, (-610 5) | 0x0a, (697 5) | 0x01, (836 5) | 0x0e,
(-610 5) | 0x0a
};
-const int16_t coeff_4k_sb_1seg_dqpsk[8] = {
+static const int16_t coeff_4k_sb_1seg_dqpsk[8] = {
(-955 5) | 0x0e, (687 5) | 0x04, (818 5) | 0x10, (-955 5) |
0x0e, (-922 5) | 0x0d, (750 5) | 0x03, (665 5) | 0x0f,
(-922 5) | 0x0d
};
-const int16_t coeff_4k_sb_1seg[8] = {
+static const int16_t coeff_4k_sb_1seg[8] = {
(638 5) | 0x0d, (683 5) | 0x02, (638 5) | 0x0d, (638 5) |
0x0d, (-655 5) | 0x0a, (517 5) | 0x00, (698 5) | 0x0d,
(-655 5) | 0x0a
};
-const int16_t coeff_4k_sb_3seg_0dqpsk_1dqpsk[8] = {
+static const int16_t coeff_4k_sb_3seg_0dqpsk_1dqpsk[8] = {
(-707 5) | 0x14, (910 5) | 0x06, (889 5) | 0x16, (-707 5) |
0x14, (-958 5) | 0x13, (993 5) | 0x05, (523 5) | 0x14,
(-958 5) | 0x13
};
-const int16_t coeff_4k_sb_3seg_0dqpsk[8] = {
+static const int16_t coeff_4k_sb_3seg_0dqpsk[8] = {
[PATCH] sanio-ms: clean up init, exit and id_table
From: Márton Németh nm...@freemail.hu
Make module_init static and mark it with __init.
Make module_exit static and mark it with __exit.
Mark probe functions with __devinit.
Make id table static and mark with __devinitconst.
This will eliminate the following sparse warnings (see make C=1):
* smsdvb.c:668:5: warning: symbol 'smsdvb_module_init' was not declared.
Should it be static?
* smsdvb.c:682:6: warning: symbol 'smsdvb_module_exit' was not declared.
Should it be static?
* smsusb.c:491:22: warning: symbol 'smsusb_id_table' was not declared. Should
it be static?
* smsusb.c:567:5: warning: symbol 'smsusb_module_init' was not declared.
Should it be static?
* smsusb.c:578:6: warning: symbol 'smsusb_module_exit' was not declared.
Should it be static?
* smssdio.c:341:5: warning: symbol 'smssdio_module_init' was not declared.
Should it be static?
* smssdio.c:353:6: warning: symbol 'smssdio_module_exit' was not declared.
Should it be static?
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r f5662ce08663 linux/drivers/media/dvb/siano/smsdvb.c
--- a/linux/drivers/media/dvb/siano/smsdvb.cFri Dec 11 09:53:41 2009 +0100
+++ b/linux/drivers/media/dvb/siano/smsdvb.cFri Dec 11 23:58:27 2009 +0100
@@ -665,7 +665,7 @@
return rc;
}
-int smsdvb_module_init(void)
+static int __init smsdvb_module_init(void)
{
int rc;
@@ -679,7 +679,7 @@
return rc;
}
-void smsdvb_module_exit(void)
+static void __exit smsdvb_module_exit(void)
{
smscore_unregister_hotplug(smsdvb_hotplug);
diff -r f5662ce08663 linux/drivers/media/dvb/siano/smssdio.c
--- a/linux/drivers/media/dvb/siano/smssdio.c Fri Dec 11 09:53:41 2009 +0100
+++ b/linux/drivers/media/dvb/siano/smssdio.c Fri Dec 11 23:58:27 2009 +0100
@@ -48,7 +48,7 @@
#define SMSSDIO_INT0x04
#define SMSSDIO_BLOCK_SIZE 128
-static const struct sdio_device_id smssdio_ids[] = {
+static const struct sdio_device_id smssdio_ids[] __devinitconst = {
{SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_STELLAR),
.driver_data = SMS1XXX_BOARD_SIANO_STELLAR},
{SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_NOVA_A0),
@@ -222,7 +222,7 @@
smscore_onresponse(smsdev-coredev, cb);
}
-static int smssdio_probe(struct sdio_func *func,
+static int __devinit smssdio_probe(struct sdio_func *func,
const struct sdio_device_id *id)
{
int ret;
@@ -338,7 +338,7 @@
/* Module functions*/
/***/
-int smssdio_module_init(void)
+static int __init smssdio_module_init(void)
{
int ret = 0;
@@ -350,7 +350,7 @@
return ret;
}
-void smssdio_module_exit(void)
+static void __exit smssdio_module_exit(void)
{
sdio_unregister_driver(smssdio_driver);
}
diff -r f5662ce08663 linux/drivers/media/dvb/siano/smsusb.c
--- a/linux/drivers/media/dvb/siano/smsusb.cFri Dec 11 09:53:41 2009 +0100
+++ b/linux/drivers/media/dvb/siano/smsusb.cFri Dec 11 23:58:27 2009 +0100
@@ -394,7 +394,7 @@
return rc;
}
-static int smsusb_probe(struct usb_interface *intf,
+static int __devinit smsusb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
struct usb_device *udev = interface_to_usbdev(intf);
@@ -488,7 +488,7 @@
return 0;
}
-struct usb_device_id smsusb_id_table[] = {
+static const struct usb_device_id smsusb_id_table[] __devinitconst = {
{ USB_DEVICE(0x187f, 0x0010),
.driver_info = SMS1XXX_BOARD_SIANO_STELLAR },
{ USB_DEVICE(0x187f, 0x0100),
@@ -564,7 +564,7 @@
.resume = smsusb_resume,
};
-int smsusb_module_init(void)
+static int __init smsusb_module_init(void)
{
int rc = usb_register(smsusb_driver);
if (rc)
@@ -575,7 +575,7 @@
return rc;
}
-void smsusb_module_exit(void)
+static void __exit smsusb_module_exit(void)
{
/* Regular USB Cleanup */
usb_deregister(smsusb_driver);
--
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: IR Receiver on an Tevii S470
On 11 декабря 2009, Igor M. Liplianin liplia...@me.by wrote: On Thu, 2009-12-10 at 18:16 +0200, Igor M. Liplianin wrote: On 10 декабря 2009 03:12:39 Andy Walls wrote: On Wed, 2009-12-09 at 17:54 +0200, Igor M. Liplianin wrote: Igor and Matthias, Please try the changes that I have for the TeVii S470 that are here: http://linuxtv.org/hg/~awalls/cx23885-ir In fact some time ago I was writing some code for cx23885 IR, but not reached IR interrupts to work. Though I used PCI_MSK_AV_CORE (1 27), then test register PIN_CTRL for field FLD_IR_IRQ_STAT. Igor, You are exactly right on this. I used the wrong interrupt status flag. I have pushed a patch to my repository to use the PCI_MSK_AV_CORE status flag. Could you please update an test the TeVii S470 again when you have time? I have Compro E650F with RC6 remote, also have RC5 remote from TV set. I will made little hack to test Compro RC5. OK. Thank you. Regards, Andy First try, without pressing IR keys cx25840 3-0044: IRQ Enables: rse rte roe cx25840 3-0044: IRQ Status: tsr cx25840 3-0044: IRQ Enables: rse rte roe irq 16: nobody cared (try booting with the irqpoll option) Pid: 0, comm: swapper Not tainted 2.6.32 #2 Call Trace: [c1052db0] ? __report_bad_irq+0x24/0x69 [c1052db7] ? __report_bad_irq+0x2b/0x69 [c1052edc] ? note_interrupt+0xe7/0x13f [c1053416] ? handle_fasteoi_irq+0x7a/0x97 [c1004411] ? handle_irq+0x38/0x3f [c1003bd1] ? do_IRQ+0x38/0x89 [c1002ea9] ? common_interrupt+0x29/0x30 [c1007a1e] ? mwait_idle+0x7a/0x7f [c1001b93] ? cpu_idle+0x37/0x4c handlers: [c13179ad] (usb_hcd_irq+0x0/0x59) [f85ba5e7] (azx_interrupt+0x0/0xe7 [snd_hda_intel]) [f88b1d2b] (cx23885_irq+0x0/0x4a5 [cx23885]) Disabling IRQ #16 cx25840 3-0044: IRQ Status: tsr cx25840 3-0044: IRQ Enables: rse rte roe cx25840 3-0044: IRQ Status: tsr OK. We're getting interrupts from the A/V core, but they are not IR related. They must be audio and video interrupts from the A/V core. I have checked in new changes: http://linuxtv.org/hg/~awalls/cx23885-ir please try again when you have time. # modprobe cx25840 debug=2 ir_debug=2 # modprobe cx23885 debug=7 My only concern now, is that I have not turned off all the audio interrupts from the A/V core - I could not determine if registers 0x80c-0x80f were improtant to set. Regards, Andy dmesg is full of repeated lines: cx25840 3-0044: AV Core IRQ status (entry): cx25840 3-0044: AV Core IRQ status (exit): cx23885[0]/0: pci_status: 0x083f4000 pci_mask: 0x0801 cx23885[0]/0: vida_status: 0x vida_mask: 0x count: 0x0 cx23885[0]/0: ts1_status: 0x ts1_mask: 0x count: 0x20 cx23885[0]/0: ts2_status: 0x ts2_mask: 0x count: 0xc7383f3a cx23885[0]/0: (PCI_MSK_AV_CORE 0x0800) Igor -- 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: IR Receiver on an Tevii S470
On Sat, 2009-12-12 at 02:30 +0200, Igor M. Liplianin wrote: On 11 декабря 2009, Igor M. Liplianin liplia...@me.by wrote: On Thu, 2009-12-10 at 18:16 +0200, Igor M. Liplianin wrote: On 10 декабря 2009 03:12:39 Andy Walls wrote: On Wed, 2009-12-09 at 17:54 +0200, Igor M. Liplianin wrote: Igor and Matthias, Please try the changes that I have for the TeVii S470 that are here: http://linuxtv.org/hg/~awalls/cx23885-ir First try, without pressing IR keys cx25840 3-0044: IRQ Enables: rse rte roe cx25840 3-0044: IRQ Status: tsr cx25840 3-0044: IRQ Enables: rse rte roe irq 16: nobody cared (try booting with the irqpoll option) please try again when you have time. # modprobe cx25840 debug=2 ir_debug=2 # modprobe cx23885 debug=7 dmesg is full of repeated lines: cx25840 3-0044: AV Core IRQ status (entry): cx25840 3-0044: AV Core IRQ status (exit): A strange thing here is that under this condition my changes should never claim the AV Core interrupt is handled. I don't know why you didn't get the nobody cared message again. cx23885[0]/0: pci_status: 0x083f4000 pci_mask: 0x0801 cx23885[0]/0: vida_status: 0x vida_mask: 0x count: 0x0 cx23885[0]/0: ts1_status: 0x ts1_mask: 0x count: 0x20 cx23885[0]/0: ts2_status: 0x ts2_mask: 0x count: 0xc7383f3a cx23885[0]/0: (PCI_MSK_AV_CORE 0x0800) I'll read over the documentation again to see if I missed something. I'll have some changes later tonight that will always try to clear every interrupt that the AV Core could possibly generate. -Andy -- 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: IR Receiver on an Tevii S470
On 12 декабря 2009 03:00:37 Andy Walls wrote: On Sat, 2009-12-12 at 02:30 +0200, Igor M. Liplianin wrote: On 11 декабря 2009, Igor M. Liplianin liplia...@me.by wrote: On Thu, 2009-12-10 at 18:16 +0200, Igor M. Liplianin wrote: On 10 декабря 2009 03:12:39 Andy Walls wrote: On Wed, 2009-12-09 at 17:54 +0200, Igor M. Liplianin wrote: Igor and Matthias, Please try the changes that I have for the TeVii S470 that are here: http://linuxtv.org/hg/~awalls/cx23885-ir First try, without pressing IR keys cx25840 3-0044: IRQ Enables: rse rte roe cx25840 3-0044: IRQ Status: tsr cx25840 3-0044: IRQ Enables: rse rte roe irq 16: nobody cared (try booting with the irqpoll option) please try again when you have time. # modprobe cx25840 debug=2 ir_debug=2 # modprobe cx23885 debug=7 dmesg is full of repeated lines: cx25840 3-0044: AV Core IRQ status (entry): cx25840 3-0044: AV Core IRQ status (exit): A strange thing here is that under this condition my changes should never claim the AV Core interrupt is handled. I don't know why you didn't get the nobody cared message again. I did, but not frequently. I thought it is obvious :) cx23885[0]/0: pci_status: 0x083f4000 pci_mask: 0x0801 cx23885[0]/0: vida_status: 0x vida_mask: 0x count: 0x0 cx23885[0]/0: ts1_status: 0x ts1_mask: 0x count: 0x20 cx23885[0]/0: ts2_status: 0x ts2_mask: 0x count: 0xc7383f3a cx23885[0]/0: (PCI_MSK_AV_CORE 0x0800) cx25840 3-0044: AV Core IRQ status (entry): cx25840 3-0044: AV Core IRQ status (exit): irq 16: nobody cared (try booting with the irqpoll option) Pid: 2521, comm: syslogd Not tainted 2.6.32 #2 Call Trace: [c1052db0] ? __report_bad_irq+0x24/0x69 [c1052db7] ? __report_bad_irq+0x2b/0x69 [c1052edc] ? note_interrupt+0xe7/0x13f [c1053416] ? handle_fasteoi_irq+0x7a/0x97 [c1004411] ? handle_irq+0x38/0x3f [c1003bd1] ? do_IRQ+0x38/0x89 [c1002ea9] ? common_interrupt+0x29/0x30 handlers: [c13179ad] (usb_hcd_irq+0x0/0x59) [f86275e7] (azx_interrupt+0x0/0xe7 [snd_hda_intel]) [f88a8d2b] (cx23885_irq+0x0/0x4e1 [cx23885]) Disabling IRQ #16 cx23885[0]/0: pci_status: 0x083f4000 pci_mask: 0x0801 cx23885[0]/0: vida_status: 0x vida_mask: 0x count: 0x0 cx23885[0]/0: ts1_status: 0x ts1_mask: 0x count: 0x20 cx23885[0]/0: ts2_status: 0x ts2_mask: 0x count: 0xc7383f3a cx23885[0]/0: (PCI_MSK_AV_CORE 0x0800) Igor -- 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: IR Receiver on an Tevii S470
On Sat, 2009-12-12 at 03:42 +0200, Igor M. Liplianin wrote: On 12 декабря 2009 03:00:37 Andy Walls wrote: On Sat, 2009-12-12 at 02:30 +0200, Igor M. Liplianin wrote: On 11 декабря 2009, Igor M. Liplianin liplia...@me.by wrote: On Thu, 2009-12-10 at 18:16 +0200, Igor M. Liplianin wrote: On 10 декабря 2009 03:12:39 Andy Walls wrote: On Wed, 2009-12-09 at 17:54 +0200, Igor M. Liplianin wrote: Igor and Matthias, Please try the changes that I have for the TeVii S470 that are here: http://linuxtv.org/hg/~awalls/cx23885-ir First try, without pressing IR keys cx25840 3-0044: IRQ Enables: rse rte roe cx25840 3-0044: IRQ Status: tsr cx25840 3-0044: IRQ Enables: rse rte roe irq 16: nobody cared (try booting with the irqpoll option) please try again when you have time. # modprobe cx25840 debug=2 ir_debug=2 # modprobe cx23885 debug=7 dmesg is full of repeated lines: cx25840 3-0044: AV Core IRQ status (entry): cx25840 3-0044: AV Core IRQ status (exit): A strange thing here is that under this condition my changes should never claim the AV Core interrupt is handled. I don't know why you didn't get the nobody cared message again. I did, but not frequently. I thought it is obvious :) OK, that's better. :P I have checked in more changes, please try when you get the chance. Please be aware that I reconfigured the drive of one signal PAD in the AV Core - I'm hoping to stop false interrupts. I did not reconfigure the corresponding IO pin in the bridge driver - I left it at whatever was the default. (I think I'm going to have to buy a CX23885 based card soon...) Regards, Andy -- 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
