[PATCH] zoran: cleanup pointer condition

2010-01-16 Thread Németh Márton
From: Márton Németh nm...@freemail.hu

Remove the following sparse warning (see make C=1):
 * warning: Using plain integer as NULL pointer

Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 5bcdcc072b6d linux/drivers/media/video/zoran/zoran_driver.c
--- a/linux/drivers/media/video/zoran/zoran_driver.cSat Jan 16 07:25:43 
2010 +0100
+++ b/linux/drivers/media/video/zoran/zoran_driver.cSat Jan 16 09:03:31 
2010 +0100
@@ -325,7 +325,7 @@
/* Allocate fragment table for this buffer */

mem = (void *)get_zeroed_page(GFP_KERNEL);
-   if (mem == 0) {
+   if (!mem) {
dprintk(1,
KERN_ERR
%s: %s - get_zeroed_page (frag_tab) failed for 
buffer %d\n,
--
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: Order of dvb devices

2010-01-16 Thread Dan Taylor


Mika Laitio wrote:

True, the ordering is not exactly the same everytime. One will need to
provide PCI Bus related info also to a practical udev configuration to
get things sorted out in a sane way, rather than anything else.


At least in Mandriva, the order and naming of network adapters are handled by 
using a this kind of udev rule which prevents for example eth0 and eth1 to swap 
between boots:

[lam...@iiris rules.d]$ cat 70-persistent-net.rules
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# Drakx-net rule for eth0 (00:24:e8:9e:66:13)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==00:11:22:33:44:55, 
ATTR{type}==1, KERNEL==eth*, NAME=eth0

# PCI device 0x8086:0x4232 (iwlagn)
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==11:22:33:44:55:66, ATTR{type}==1, 
KERNEL==wlan*, NAME=wlan0

I am not sure whether udev rules itself can originally generate this file or 
whether it's mandriva's own tools/scripts that will generate this file and add 
all new adapters it finds that are not yet in the file.

Mika



The eth drivers have one advantage:  nearly all of them have an
associated MAC address, which is (supposed to be, anyway) globally
(the planet, not just the system) unique.  It is, therefore, easy
enough to associate a specific NIC with a specific name, as shown.

If we keep some sort of configuration table:

For those boards that have eeproms, and for which the eeprom contains
a serial number, or other unique identifier, we could do the same thing.

Alternatively, we could use the PCI address (bus/device/unit).

USB devices can have serial numbers, but it isn't common.

Sounds like we need to think about keeping a table, having some udev
rules to work with it, and some utility to manage it.

RFQ time?


--
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: DM1105: could not attach frontend 195d:1105

2010-01-16 Thread Igor M. Liplianin
On 16 января 2010, pau...@planar.id.au wrote:
 Sorry for the many e-mails.

 I've looked through the code for si21xx.c.  I can't see any obvious reason
 it wouldn't be working.  si21xx_attach calls read_reg, and read_reg is not
 returning a value.  The datasheet for the chip
 (http://www.datasheetarchive.com/datasheet-pdf/016/DSA00286370.html) says
 those registers are correct.

 I'm assuming the problem would be the demod_address?  I modified the code
 in dm1105.c to try all options for demod_address between 0x01 and 0x100.
 None of them seemed to work.  The code looked like this:
 int demod = 0x01;
 while (demod  0x100) {
 serit_config.demod_address = demod;
 dm1105dvb-fe = dvb_attach(
 si21xx_attach, serit_config,
 dm1105dvb-i2c_adap);
 if (dm1105dvb-fe) {
 dm1105dvb-fe-ops.set_voltage =
 dm1105dvb_set_voltage;
 break;
 }
 printk(KERN_ERR Try: %x\n, demod);
 demod++;
 }

 The output from dmesg looks something like this (obviously much longer):
 [196838.768110] Try: fb
 [196838.768162] si21xx: si21xx_attach
 [196839.016208] si21xx: si21_readreg: readreg error (reg == 0x01, ret ==
 -1)
 [196839.264255] si21xx: si21_writereg: writereg error (reg == 0x01, data
 == 0x40, ret == -1)
 [196839.716056] si21xx: si21_readreg: readreg error (reg == 0x00, ret ==
 -1)
 [196839.716112] Try: fc
 [196839.716164] si21xx: si21xx_attach
 [196839.964211] si21xx: si21_readreg: readreg error (reg == 0x01, ret ==
 -1)
 [196840.212259] si21xx: si21_writereg: writereg error (reg == 0x01, data
 == 0x40, ret == -1)
 [196840.664056] si21xx: si21_readreg: readreg error (reg == 0x00, ret ==
 -1)
 [196840.664112] Try: fd
 [196840.664164] si21xx: si21xx_attach
 [196840.912211] si21xx: si21_readreg: readreg error (reg == 0x01, ret ==
 -1)
 [196841.160258] si21xx: si21_writereg: writereg error (reg == 0x01, data
 == 0x40, ret == -1)
 [196841.612053] si21xx: si21_readreg: readreg error (reg == 0x00, ret ==
 -1)
 [196841.612111] Try: fe
 [196841.612162] si21xx: si21xx_attach
 [196841.860209] si21xx: si21_readreg: readreg error (reg == 0x01, ret ==
 -1)
 [196842.108256] si21xx: si21_writereg: writereg error (reg == 0x01, data
 == 0x40, ret == -1)
 [196842.560055] si21xx: si21_readreg: readreg error (reg == 0x00, ret ==
 -1)
 [196842.560112] Try: ff
 [196842.560115] dm1105 :06:00.0: could not attach frontend
 [196842.560287] dm1105 :06:00.0: PCI INT A disabled


 I'm now out of ideas for what to do next.  In the mean-time, I noticed a
 couple of tidyups in the code for si21xx.c.  They are cosmetic only, patch
 is attached if you happened to be in that module for some other reason:

 diff si21xx.c.old si21xx.c
 99a100,104

  #define VERSION_SI21070x34
  #define VERSION_SI21080x24
  #define VERSION_SI21090x14
  #define VERSION_SI21100x04

 945c950
id = si21_readreg(state, 0x00);
 ---

id = si21_readreg(state, REVISION_REG);

 947c952
/* register 0x00 contains:
 ---

/* register REVISION_REG contains:

 953c958
if (id != 0x04  id != 0x14)
 ---

if (id != VERSION_SI2110  id != VERSION_SI2109)

 954a960

  /* only 2110 and 2109 are currently supported */

 Thanks again for your help,

 Paul

Accordingly datasheet possible demod addresses are 0x68, 0x69, 0x6a, 0x6b only.
Possibly there is some DM1105 GPIO drives reset for demod.
I assume it is last (26, top right if you look from card elements side) pin on 
tuner.
You can visually trace way from can tuner. Or use multimeter.

-- 
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks

--
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: How to use saa7134 gpio via gpio-sysfs?

2010-01-16 Thread Trent Piepho
On Sat, 16 Jan 2010, hermann pitton wrote:
 Am Freitag, den 15.01.2010, 17:27 -0800 schrieb Trent Piepho:
  On Sat, 16 Jan 2010, hermann pitton wrote:
   Am Dienstag, den 12.01.2010, 04:13 +0100 schrieb hermann pitton:
 gpio-sysfs creates
 /sys/class/gpio/export
 /sys/class/gpio/import
 but no gpion entries so far.
 
  The saa713x driver predates the generic gpio layer by years and years, so
  it doesn't use it.  It also doesn't need to use it.  Since the gpios are
  managed by the saa713x driver, and they also used by the saa713x driver,
  there is no need to interface two different drivers together.  There are
  tons of drivers for devices that have gpios like this, but they don't use
  the gpio layer.
 
  But with gpio access via sysfs for generic gpios, there is something useful
  about having the saa713x driver support generic gpios.  IIRC, somehow wrote
  a gpio only bt848 driver that didn't do anything but export gpios.
 
  In order to do this, you'll have to write code for the saa7134 driver to
  have it register with the gpio layer.  I think you could still have the
  saa7134 driver itself use its gpio directly.  That would avoid a
  performance penalty in the driver.

 Thanks for more details, but I'm still wondering what pins ever could be
 interesting in userland, given that they are all treated such different
 per device, and we count up to 200 different boards these days.

There are some cards for intended for survilence or embedded applications
that have headers on them to connect things to the GPIOs.  Like alarms or
camera controllers and stuff like that.

The GPIO only bttv driver was created by someone who just soldered a bunch
of wires on a cheap bt848 card, you can get them for just a few dollars, as
it was a cheap and easy way to get a bunch of gpios in a pc.  See his page
here http://www.bu3sch.de/joomla/index.php/bt8xx-based-gpio-card

There are cards you can get that just have GPIOs, but they end up being
rather expensive.  Here's one:
http://www.acromag.com/parts.cfm?Model_ID=317Product_Function_ID=4Category_ID=18Group_ID=1
Way fancier than a tv card, but it's $600.

I think if I was doing the coding, I'd add a field in the card description
for what GPIOs should be exported.  I.e., which ones have an external
header.  Maybe in addition to, or instead of, I'd have a module option that
would cause GPIOs to be exported.  A bitmask of which to export would be
enough.
--
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: Need testers: cx23885 IR Rx for TeVii S470 and HVR-1250

2010-01-16 Thread Igor M. Liplianin
On 16 января 2010 06:02:41 Andy Walls wrote:
 Hi,

 I've got reworked changes for the IR for the TeVii S470 and the HVR-1250
 at

   http://linuxtv.org/hg/~awalls/cx23885-ir2

 Thanks to loaner HVR-1250 hardware from Devin Heitmueller,
 I've solved the infinite interrupt problem with the CX23885 AV core and
 have reworked the change set against the latest v4l-dvb.

 Please test.

 Note

 1. the parameters for the IR controller setup in
 linux/drivers/video/cx23885-input.c may need to be tweaked to set the
 proper params.modulation and params.invert_level before you get
 keypresses decoded.

 2. I guessed at a reasonable set of remote keycodes for the TeVii S470,
 so don't be surprised if the button mapping isn't quite right.

 3.  These module settings may be helpful for debug and test:

# modprobe cx25840 debug=2 ir_debug=2
# modprobe cx23885 debug=7

 Also directing kern.* messages to /var/log/messages
 in /etc/rsyslogd.conf and giving rsyslod a SIGHUP may be helpful for
 capturing the messages.

 4.  In case I didn't fix the infinite interrupts problem for the TeVii
 S470: Before testing, blacklist the cx23885 module
 in /etc/modprobe.d/blacklist, so that when you reboot, the module
 doesn't automatically load.  If your system seems to be very busy with
 inifinite interrupts upon cx23885 module load, stop testing (and let me
 know).

 Regards,
 Andy
Hi

modprobe cx23885 gives nobody cared : 

Creating IR device irrcv0
irq 16: nobody cared (try booting with the irqpoll option)
Pid: 0, comm: swapper Not tainted 2.6.33-rc4 #3
Call Trace:
 [c1054700] ? __report_bad_irq+0x24/0x69
 [c1054707] ? __report_bad_irq+0x2b/0x69
 [c105482c] ? note_interrupt+0xe7/0x13f
 [c1054d66] ? handle_fasteoi_irq+0x7a/0x97
 [c1003e80] ? handle_irq+0x38/0x40
 [c10036d8] ? do_IRQ+0x38/0x8e
 [c1002ca9] ? common_interrupt+0x29/0x30
 [c100796e] ? mwait_idle+0x7a/0x7f
 [c1001ab3] ? cpu_idle+0x37/0x4c
 [c1648774] ? start_kernel+0x29a/0x29d
handlers:
[c1332132] (usb_hcd_irq+0x0/0x59)
[f87cdd88] (cx23885_irq+0x0/0x4e0 [cx23885])
Disabling IRQ #16

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: PULL http://jusst.de/hg/stv090x

2010-01-16 Thread Mauro Carvalho Chehab
Oliver Endriss wrote:
 Mauro Carvalho Chehab wrote:
 Oliver Endriss wrote:
 Manu Abraham wrote:
 On Mon, Jan 11, 2010 at 12:17 AM, Manu Abraham abraham.m...@gmail.com 
 wrote:
 Mauro,


 Following the changesets 13830 - 13894 from my earlier pull request,
 Correction, 13880 - 13894 inclusive of both.

 Please pull the following changeset as well


 http://jusst.de/hg/stv090x/rev/80c74966d955


 It fixes a nasty bug as described at
 http://osdir.com/ml/linux-media/2009-11/msg00643.html


 Regards,
 Manu
 Mauro,

 when will you pull-in these changesets?
 You are blocking the submission of the ngene driver.
 Hi Oliver,

 Since I returned from vacations this week, I had a pile of tasks to
 handle, both at the subsystem and at the work.

 Unfortunately, having to deal with both -hg and -git eats lot of my
 time, to be sure that nothing is missed. This time, I had to re-generate
 all my local -git trees that somehow had loose some patches in the process.
 Due to that, the patch merge is taking longer than I've expected.

 I still have a few issues pending at the subsystem, including this stv090x
 pull request, the omap pull (that it is very complex, as it requires both
 -hg and -git patch insertions), lnbh24 fix, my own proposals to dvb-apps, 
 and two upstream submissions.

 My intention is to finish those tasks during this weekend if time
 allows me to do everything.

 In the specific case of stv090x, I intend to review again the locks,
 in the light of your comments.
 
 I just wondered why you did not pull-in these changesets.

I finished reviewing the locking schema and it seemed OK with your fixes.

Still, I think that the i2c_gate_control function is poorly documented. Somehow,
it should be commented that the lock is taken when enable=1 and is dropped when
enable=0, warning anyone that may be analyzing the code about that, especially
since the lock function is exported to dvb core. It is not common to use a
locking schema like that, where the information that the code is locked is
hidden.

IMO, the better way would be to split the function in two, like:
i2c_gate_enable_lock(struct dvb_frontend *fe);
i2c_gate_disable_unlock(struct dvb_frontend *fe);

And use those two functions internally. You'll still need to have an 
i2c_gate_control() function that has the locks inside, due to the calls
done at dvb_frontend.c, but the code will be better documented.

In order to not add more delay to ngene, I'll apply the stv090x patches, but
please better document the i2c_gate_control on your next patch series.

Btw, with respect to dvb-core, we'll need to do soon a lock review, since
dvbdev.c uses the BKL, and it will be removed on 2.6.34 or 2.6.35.
 
 The first lnbh24 patch was pulled so fast, that I had no chance to
 respond. This patch was submitted much later than the stv090x stuff.
 Btw, it breaks the ngene driver, so it is important to apply the
 lnbh24 fix...

Yes, it were submitted latter, but I've reviewed stv090x before lnbh24.
Anyway, it is the next on my review list.
 
 CU
 Oliver
 

--
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: Need testers: cx23885 IR Rx for TeVii S470 and HVR-1250

2010-01-16 Thread Igor M. Liplianin
On 16 января 2010 06:02:41 Andy Walls wrote:
 Hi,

 I've got reworked changes for the IR for the TeVii S470 and the HVR-1250
 at

   http://linuxtv.org/hg/~awalls/cx23885-ir2

 Thanks to loaner HVR-1250 hardware from Devin Heitmueller,
 I've solved the infinite interrupt problem with the CX23885 AV core and
 have reworked the change set against the latest v4l-dvb.

 Please test.

 Note

 1. the parameters for the IR controller setup in
 linux/drivers/video/cx23885-input.c may need to be tweaked to set the
 proper params.modulation and params.invert_level before you get
 keypresses decoded.

 2. I guessed at a reasonable set of remote keycodes for the TeVii S470,
 so don't be surprised if the button mapping isn't quite right.

 3.  These module settings may be helpful for debug and test:

# modprobe cx25840 debug=2 ir_debug=2
# modprobe cx23885 debug=7

 Also directing kern.* messages to /var/log/messages
 in /etc/rsyslogd.conf and giving rsyslod a SIGHUP may be helpful for
 capturing the messages.

 4.  In case I didn't fix the infinite interrupts problem for the TeVii
 S470: Before testing, blacklist the cx23885 module
 in /etc/modprobe.d/blacklist, so that when you reboot, the module
 doesn't automatically load.  If your system seems to be very busy with
 inifinite interrupts upon cx23885 module load, stop testing (and let me
 know).

 Regards,
 Andy
However, modprobe cx23885 card=3
and RC5 remote gives some events.

cx25840 3-0044: IRQ Status:  tsr rsr ror rby
cx25840 3-0044: IRQ Enables: rse rte roe
cx25840 3-0044: IR receiver hardware FIFO overrun
cx25840 3-0044: AV Core IRQ status (exit):   
cx25840 3-0044: AV Core IRQ status (entry): ir
cx25840 3-0044: IRQ Status:  tsr rsr ror rby
cx25840 3-0044: IRQ Enables: rse rte roe
cx25840 3-0044: IR receiver hardware FIFO overrun
cx25840 3-0044: AV Core IRQ status (exit):   
cx25840 3-0044: AV Core IRQ status (entry): ir
cx25840 3-0044: IRQ Status:  tsr rsr rby
cx25840 3-0044: IRQ Enables: rse rte roe
cx25840 3-0044: AV Core IRQ status (exit):   
cx25840 3-0044: AV Core IRQ status (entry): ir
cx25840 3-0044: IRQ Status:  tsr rsr ror rby
cx25840 3-0044: IRQ Enables: rse rte roe
cx25840 3-0044: IR receiver hardware FIFO overrun
cx25840 3-0044: AV Core IRQ status (exit):   
cx25840 3-0044: AV Core IRQ status (entry): ir
cx25840 3-0044: IRQ Status:  tsr rsr rto
cx25840 3-0044: IRQ Enables: rse rte roe
cx25840 3-0044: AV Core IRQ status (exit):   
cx25840 3-0044: rx read:1605444 ns  space
cx25840 3-0044: rx read:1748852 ns  mark
cx25840 3-0044: rx read:1618778 ns  space
cx25840 3-0044: rx read:1713000 ns  mark
cx25840 3-0044: rx read: end of rx
cx25840 3-0044: AV Core IRQ status (entry): ir
cx25840 3-0044: IRQ Status:  tsr rsr rto ror
cx25840 3-0044: IRQ Enables: rse rte roe
cx25840 3-0044: IR receiver hardware FIFO overrun
cx25840 3-0044: AV Core IRQ status (exit):   
cx25840 3-0044: rx read: 779667 ns  space
cx25840 3-0044: rx read:1737741 ns  mark
cx25840 3-0044: rx read:1618630 ns  space
cx25840 3-0044: rx read:1737593 ns  mark
cx25840 3-0044: rx read:1618630 ns  space
cx25840 3-0044: rx read:1738481 ns  mark
cx25840 3-0044: rx read:1617889 ns  space
cx25840 3-0044: rx read:1738926 ns  mark
cx25840 3-0044: AV Core IRQ status (entry): ir
cx25840 3-0044: IRQ Status:  tsr rsr rto ror
cx25840 3-0044: IRQ Enables: rse rte roe
cx25840 3-0044: IR receiver hardware FIFO overrun

-- 
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: PULL http://jusst.de/hg/stv090x

2010-01-16 Thread Mauro Carvalho Chehab
Hi Andreas,

Andreas Regel wrote:
 
 you don't have to look at stv090x_i2c_gate_ctrl alone. stv090x driver
 contains code like this:
 
 if (stv090x_i2c_gate_ctrl(fe, 1)  0)
 goto err;
 
 tuner access
 
 if (stv090x_i2c_gate_ctrl(fe, 0)  0)
 goto err;

Ok. It is very unusual to have a lock internally like the above, since
the code becomes poorly documented.

In the cases that we want to do things like that, it is documented like:

 if (stv090x_gate_enable_lock(fe)  0)
 goto err;
 
 tuner access
 
 if (stv090x_gate_disable_unlock(fe, 0)  0)
 goto err;

This way, it is clear to anyone that is reviewing the code that the functions
are returning with the lock on a different state and prevent the kernel janitors
to send patches that will try to fix the lock.

I bet that their coccinelle rules will generate some false alarms with the 
current code.

 Intention of the patch is to make the tuner access exclusive. Thats the
 reason why the mutex is locked when gate is opened and unlocked when the
 gate is closed.
 
 In case the opening fails the close call is not made und thus mutex is
 not unlocked twice.
 
 There one problem pending with: when there is an error during tuner
 access the gate will not be closed and thus the mutex will not be
 unlocked. For this case a patch from Oliver Endriss is attached.

After the patch, the lock is fine, but we still need to better document it,
in order to save time from reviewers and janitors.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: DM1105: could not attach frontend 195d:1105

2010-01-16 Thread paul10
Igor wrote:

 Accordingly datasheet possible demod addresses are 0x68, 0x69, 0x6a,
0x6b only.
 Possibly there is some DM1105 GPIO drives reset for demod.
 I assume it is last (26, top right if you look from card elements side)
pin on tuner.
 You can visually trace way from can tuner. Or use multimeter.

Sorry, that is a bit beyond me.

If I understand correctly, I'm looking for the top right pin from the
tuner when I'm looking at the side of the card that has all the chips on
it.  I can see that, and there are a number of traces that run from there
to the DM1105, and also a few that run to other components on the card. 

I'm assuming I need to follow the topmost of the traces that go to the
DM1105, and see which pin on the DM1105 it goes to.

My eyesight isn't that good...but I have a magnifying glass.  If I follow
the topmost of the traces it looks to run to the rightmost pin on the top
row of pins on the DM1105, when the writing on the DM1105 is the right way
up.  I didn't find a data sheet for the DM1105, so I can't tell if that is
a GPIO pin or not.

The next trace down from the top right on the tuner appears to end without
connecting.  It ends in a small brass circle, and doesn't appear to go
through to the back of the board and connect anywhere.  The next one below
that goes to the fifth pin in from the right hand end of the top row on the
DM1105.

Am I doing the right thing here - does this make sense?

I've drawn on the photo so you can see what I'm doing.  Refer:
http://planar.id.au/Photos/img_1964%20%28copy%29.jpg.  The far right blue
line comes from the top most right hand pin on the tuner, runs under the
board at the brass circle, and comes out again to join on to the rightmost
pin.  The next blue line in is the one going to the fifth pin, it is the
third track down coming from the tuner.  In between the two is a track that
appears to go nowhere.  I've marked in white roughly where they are coming
out of the tuner.

Thanks again for all your help,

Paul


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-22fix

2010-01-16 Thread Mauro Carvalho Chehab
Abylai Ospan wrote:
 Mauro,
 
 Please pulll change:
 
 http://udev.netup.ru/cgi-bin/hgwebdir.cgi/v4l-dvb-aospan-22fix/rev/fc3e44f30da3
 
 22-kHz set_tone fix for NetUP Dual DVB-S2-CI card. 22kHz logic controlled by 
 demod.
 
 This patch modified after discussion with Oliver. This version is acceptable 
 for both side ... 
 
 Thanks.
 

Your site seems to be down:

abort: error: No route to host

Please send me a pull request when the site returns.

Cheers,
Mauro.

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] dvb-core: remove unnecessary casting of kmalloc.

2010-01-16 Thread Thiago Farina
Signed-off-by: Thiago Farina tfrans...@gmail.com
---
 drivers/media/dvb/dvb-core/dvb_frontend.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c 
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 0746122..8eb4a3b 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1536,8 +1536,7 @@ static int dvb_frontend_ioctl_properties(struct inode 
*inode, struct file *file,
if ((tvps-num == 0) || (tvps-num  DTV_IOCTL_MAX_MSGS))
return -EINVAL;
 
-   tvp = (struct dtv_property *) kmalloc(tvps-num *
-   sizeof(struct dtv_property), GFP_KERNEL);
+   tvp = kmalloc(tvps-num * sizeof(struct dtv_property), 
GFP_KERNEL);
if (!tvp) {
err = -ENOMEM;
goto out;
@@ -1569,8 +1568,7 @@ static int dvb_frontend_ioctl_properties(struct inode 
*inode, struct file *file,
if ((tvps-num == 0) || (tvps-num  DTV_IOCTL_MAX_MSGS))
return -EINVAL;
 
-   tvp = (struct dtv_property *) kmalloc(tvps-num *
-   sizeof(struct dtv_property), GFP_KERNEL);
+   tvp = kmalloc(tvps-num * sizeof(struct dtv_property), 
GFP_KERNEL);
if (!tvp) {
err = -ENOMEM;
goto out;
-- 
1.6.6.103.g699d2

--
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: Need testers: cx23885 IR Rx for TeVii S470 and HVR-1250

2010-01-16 Thread Igor M. Liplianin
On 16 января 2010 06:02:41 Andy Walls wrote:
 Hi,

 I've got reworked changes for the IR for the TeVii S470 and the HVR-1250
 at

   http://linuxtv.org/hg/~awalls/cx23885-ir2

 Thanks to loaner HVR-1250 hardware from Devin Heitmueller,
 I've solved the infinite interrupt problem with the CX23885 AV core and
 have reworked the change set against the latest v4l-dvb.

 Please test.

 Note

 1. the parameters for the IR controller setup in
 linux/drivers/video/cx23885-input.c may need to be tweaked to set the
 proper params.modulation and params.invert_level before you get
 keypresses decoded.

It works properly with settings

params.modulation = false;
params.invert_level = true;

But after couple seconds :(

cx25840 3-0044: IRQ Status:  tsr rsr rto
cx25840 3-0044: IRQ Enables: rse rte roe
cx25840 3-0044: rx read:9046778 ns  mark
cx25840 3-0044: rx read:2206333 ns  space
cx25840 3-0044: rx read: 606926 ns  mark
cx25840 3-0044: rx read: end of rx
cx25840 3-0044: IRQ Status:  tsr rsr rto
cx25840 3-0044: IRQ Enables: rse rte roe
cx25840 3-0044: rx read:9055815 ns  mark
cx25840 3-0044: rx read:2203519 ns  space
cx25840 3-0044: rx read: 582481 ns  mark
cx25840 3-0044: rx read: end of rx
irq 16: nobody cared (try booting with the irqpoll option)
Pid: 2971, comm: X Not tainted 2.6.33-rc4 #3
Call Trace:
 [c1054700] ? __report_bad_irq+0x24/0x69
 [c1054707] ? __report_bad_irq+0x2b/0x69
 [c105482c] ? note_interrupt+0xe7/0x13f
 [c1054d66] ? handle_fasteoi_irq+0x7a/0x97
 [c1003e80] ? handle_irq+0x38/0x40
 [c10036d8] ? do_IRQ+0x38/0x8e
 [c1002ca9] ? common_interrupt+0x29/0x30
 [c109cb00] ? __pollwait+0x76/0xa5
 [c13d4000] ? unix_poll+0x14/0x89
 [c137c496] ? sock_poll+0xc/0xe
 [c109c4ff] ? do_select+0x2a1/0x42d
 [c109ca8a] ? __pollwait+0x0/0xa5
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109cb2f] ? pollwake+0x0/0x65
 [c109c7f0] ? core_sys_select+0x165/0x21b
 [f8cb0318] ? i915_gem_object_set_to_cpu_domain+0x2b/0xdb [i915]
 [f878535a] ? drm_ioctl+0x0/0x2a4 [drm]
 [c109ab89] ? vfs_ioctl+0x1c/0x7d
 [c109b13b] ? do_vfs_ioctl+0x4aa/0x4e5
 [c1047341] ? ktime_get_ts+0xd3/0xdb
 [c109ca69] ? sys_select+0x6e/0x8f
 [c1425105] ? syscall_call+0x7/0xb
handlers:
[c1332132] (usb_hcd_irq+0x0/0x59)
[f8aafd88] (cx23885_irq+0x0/0x4e0 [cx23885])


 2. I guessed at a reasonable set of remote keycodes for the TeVii S470,
 so don't be surprised if the button mapping isn't quite right.

 3.  These module settings may be helpful for debug and test:

# modprobe cx25840 debug=2 ir_debug=2
# modprobe cx23885 debug=7

 Also directing kern.* messages to /var/log/messages
 in /etc/rsyslogd.conf and giving rsyslod a SIGHUP may be helpful for
 capturing the messages.

 4.  In case I didn't fix the infinite interrupts problem for the TeVii
 S470: Before testing, blacklist the cx23885 module
 in /etc/modprobe.d/blacklist, so that when you reboot, the module
 doesn't automatically load.  If your system seems to be very busy with
 inifinite interrupts upon cx23885 module load, stop testing (and let me
 know).

 Regards,
 Andy

-- 
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
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: DM1105: could not attach frontend 195d:1105

2010-01-16 Thread Igor M. Liplianin
On 16 января 2010 15:18:07 pau...@planar.id.au wrote:
 Igor wrote:
  Accordingly datasheet possible demod addresses are 0x68, 0x69, 0x6a,

 0x6b only.

  Possibly there is some DM1105 GPIO drives reset for demod.
  I assume it is last (26, top right if you look from card elements side)

 pin on tuner.

  You can visually trace way from can tuner. Or use multimeter.

 Sorry, that is a bit beyond me.

 If I understand correctly, I'm looking for the top right pin from the
 tuner when I'm looking at the side of the card that has all the chips on
 it.  I can see that, and there are a number of traces that run from there
 to the DM1105, and also a few that run to other components on the card.

 I'm assuming I need to follow the topmost of the traces that go to the
 DM1105, and see which pin on the DM1105 it goes to.

 My eyesight isn't that good...but I have a magnifying glass.  If I follow
 the topmost of the traces it looks to run to the rightmost pin on the top
 row of pins on the DM1105, when the writing on the DM1105 is the right way
 up.  I didn't find a data sheet for the DM1105, so I can't tell if that is
 a GPIO pin or not.

 The next trace down from the top right on the tuner appears to end without
 connecting.  It ends in a small brass circle, and doesn't appear to go
 through to the back of the board and connect anywhere.  The next one below
 that goes to the fifth pin in from the right hand end of the top row on the
 DM1105.

 Am I doing the right thing here - does this make sense?

 I've drawn on the photo so you can see what I'm doing.  Refer:
 http://planar.id.au/Photos/img_1964%20%28copy%29.jpg.  The far right blue
 line comes from the top most right hand pin on the tuner, runs under the
 board at the brass circle, and comes out again to join on to the rightmost
 pin.  The next blue line in is the one going to the fifth pin, it is the
 third track down coming from the tuner.  In between the two is a track that
 appears to go nowhere.  I've marked in white roughly where they are coming
 out of the tuner.

 Thanks again for all your help,

 Paul
Well, as I understood, GPIO15 drives reset for demod.
dm1105 driver needs little patching.

-- 
Igor M. Liplianin
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb-misc

2010-01-16 Thread Mauro Carvalho Chehab
Andy Walls wrote:
 The better is to rely on input_dev stuff, since they can easily be used by 
 ir-core
 sysfs to provide device naming for loading keytables from userspace during 
 udev
 handling.
 
 OK, I don't see struct input_dev providing any storage for name and phys
 strings.  From vanilla-2.6.31-rc8/include/linux/input.h:
 
   struct input_dev {
   const char *name;
   const char *phys;
   [...]
 
 
 and vanilla-2.6.31-rc8/drivers/input/input.c:input_register_device()
 doesn't do any allocation.  In fact it spits out useless default strings
 like Unspecified device if input_dev-name is NULL.
 
 Also vanilla-2.6.31-rc8/drivers/input/input.c:input_devices_seq_show(),
 doesn't print any useful information if they are not set:
 
   seq_printf(seq, N: Name=\%s\\n, dev-name ? dev-name : );
   seq_printf(seq, P: Phys=%s\n, dev-phys ? dev-phys : );
 
 So I don't see where the input layer is providing anything: storage
 space nor automatic string generation.
 
That's true, but the drivers should be dynamically allocating the memory:
ir-phys = kasprintf(GFP_KERNEL, pci-%s/ir0, pci_name(pci));
or
ir-phys = kasprintf(GFP_KERNEL, usb-%s-%s, dev-bus-bus_name,
  dev-devpath);

For the IR name, probably this would be enough:
ir-name = dev-name;

That's said, I agree that the better is to provide automatic string generation
at the ir-core, for both PCI and USB cases.

Of course, those names should be freed when unregistering the device.

 
 Some of the V4L drivers use struct card_ir from
 linux/include/media/ir-common.h:
 
   struct card_ir {
   struct input_dev*dev;
   struct ir_input_state   ir;
   charname[32];
   charphys[32];
   [...]

Yes, i know. Legacy code. We should really remove name/phys from there
and use the pointers at input.h. As input layer changed, we should have
better patched the IR drivers to not duplicate data.

 which has string storage that is too small for the card names in
 cx23885-cards.c and also has a group of fields that don't make a lot of
 sense for the RC-5 and NEC decoding state machines I've implemented.
 
 In fact linux/drivers/media/video/cx88/cx88-input.c uses it's own struct
 cx88_IR instead of card_IR:
 
   struct cx88_IR {
   struct cx88_core *core;
   struct input_dev *input;
   struct ir_input_state ir;
   char name[32];
   char phys[32];
   [...]
 
 
 So what is it you want me to do with this change?  I don't know what
 storage space for strings you want me to reuse. 
 
 Regards,
 Andy
 
 Cheers,
 Mauro.

 

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Slovak Republic DVB-T updates

2010-01-16 Thread Christoph Pfister
Hi,

2010/1/3 a a puk...@gmail.com:
 Hi all,

 in Slovak Republic there are some updates regarding DVB-T.
 On 22.12.2009 has been DVB-T officially started in some new cities +
 existing transmission has been changed as well.

 updated ones:
 - Bratislava
 - Kosice
 - Banska Bystrica

 new ones:
 - Bardejov
 - Michalovce
 - Namestovo
 - Poprad
 - Rimavska Sobota
 - Trencin
 - Velky Krtis
 - Zilina

 updates were made based on official announcement (sorry is slovak):
 http://dvbt.towercom.sk/odbornici.php?article=32

 Attached are dvb-t config files for all these. Please include them to
 official list if possible.

 I've tested Kosice setting only and it works OK for me.

 Kind regards

 Peter Butkovic

Updated, thanks!

Christoph
--
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: dvb-apps: add scan file for Kojal, Czech Republic

2010-01-16 Thread Christoph Pfister
Thanks!

Christoph
--
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] ov534: allow enumerating supported framerates

2010-01-16 Thread Antonio Ospite
On Sat,  9 Jan 2010 01:41:31 +0100
Antonio Ospite osp...@studenti.unina.it wrote:

 Signed-off-by: Antonio Ospite osp...@studenti.unina.it
 
 ---
 
 Historical note:
 
 This has been re-tested on a reliable machine and it works from guvcview for
 all the framerates; on my old PC I am still having problems with 640x...@60fps
 _regardless_ of this change, so it must be a USB problem.
 
 Thanks,
Antonio

Ping? Jean-Francois.

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


pgpA8KwH8LYS8.pgp
Description: PGP signature


Re: [PATCH] ov534: allow enumerating supported framerates

2010-01-16 Thread Antonio Ospite
On Sat,  9 Jan 2010 01:41:31 +0100
Antonio Ospite osp...@studenti.unina.it wrote:



 Index: gspca/linux/drivers/media/video/gspca/ov534.c
 ===
 --- gspca.orig/linux/drivers/media/video/gspca/ov534.c
 +++ gspca/linux/drivers/media/video/gspca/ov534.c
 @@ -282,6 +282,21 @@
.priv = 0},
  };
  
 +static const int qvga_rates[] = {125, 100, 75, 60, 50, 40, 30};
 +static const int vga_rates[] = {60, 50, 40, 30, 15};
 +

Hmm, after double checking compilation messages, having these as 'const'
produces two:
  warning: initialization discards qualifiers from pointer target type
in the assignments below.

If I remove the 'const' qualifiers here, the messages go away, so I'd
say we can do also without them. If that's ok I'll send a v2 soon,
sorry.

Thanks,
   Antonio

 +static const struct framerates ov772x_framerates[] = {
 + { /* 320x240 */
 + .rates = qvga_rates,
 + .nrates = ARRAY_SIZE(qvga_rates),
 + },
 + { /* 640x480 */
 + .rates = vga_rates,
 + .nrates = ARRAY_SIZE(vga_rates),
 + },
 +};
 +
 +
  static const u8 bridge_init[][2] = {
   { 0xc2, 0x0c },
   { 0x88, 0xf8 },
 @@ -799,6 +814,7 @@
  
   cam-cam_mode = ov772x_mode;
   cam-nmodes = ARRAY_SIZE(ov772x_mode);
 + cam-mode_framerates = ov772x_framerates;
  
   cam-bulk = 1;
   cam-bulk_size = 16384;


-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


pgp4D1q0L3AVD.pgp
Description: PGP signature


Re: [PULL] http://udev.netup.ru/hg/v4l-dvb-aospan-22fix

2010-01-16 Thread Abylai Ospan
On Sat, 2010-01-16 at 11:18 -0200, Mauro Carvalho Chehab wrote:
 Abylai Ospan wrote:
  Mauro,
  
  Please pulll change:
  
  http://udev.netup.ru/cgi-bin/hgwebdir.cgi/v4l-dvb-aospan-22fix/rev/fc3e44f30da3
  
  22-kHz set_tone fix for NetUP Dual DVB-S2-CI card. 22kHz logic controlled 
  by demod.
  
  This patch modified after discussion with Oliver. This version is 
  acceptable for both side ... 
  
  Thanks.
  
 
 Your site seems to be down:
 
 abort: error: No route to host
 
 Please send me a pull request when the site returns.

Please try again. Should work.
Thanks.


-- 
Abylai Ospan aos...@netup.ru
NetUP Inc.

--
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/~dougsland/v4l-dvb

2010-01-16 Thread Douglas Schilling Landgraf
Hello Mauro,

  Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb for
the following:

- cx23888-ir: fix kfifo erros for kernels  2.6.33
- meye: fix kfifo errors for kernels  2.6.33

Cheers,
Douglas
--
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: New init DVB-T file for fr-Saint-Jorioz-1 (Saint-Germain / Talloire)]

2010-01-16 Thread Christoph Pfister
Hi,

2010/1/7 Benoît Pourre benoit.pou...@gmail.com:
 Hello,

 Here is my complete init dvb file for the new location fr-Saint-Jorioz-1
 (Saint-Germain / Talloire).

 Best regards.

 Benoît

 T   -10 8MHz AUTO NONEQAM64   8k 1/32 NONE

^ this is nonsense (not your fault)

 T 49000 8MHz AUTO AUTO AUTO AUTO AUTO AUTO# F
 T 51400 8MHz AUTO AUTO AUTO AUTO AUTO AUTO# F
 T 53800 8MHz AUTO AUTO AUTO AUTO AUTO AUTO# F
 T 71400 8MHz AUTO AUTO AUTO AUTO AUTO AUTO# F
 T 73800 8MHz AUTO AUTO AUTO AUTO AUTO AUTO

^ transponders with all values set to AUTO are not very useful, sorry
(people using this file might as well use auto scan)

Christoph
--
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] disable building cx23885 before 2.6.33

2010-01-16 Thread Németh Márton
From: Márton Németh nm...@freemail.hu

The cx23885 driver does not compile before Linux kernel 2.6.33 because of
incompatible fifo API changes. Disable this driver being built before
2.6.33.

Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 5bcdcc072b6d v4l/versions.txt
--- a/v4l/versions.txt  Sat Jan 16 07:25:43 2010 +0100
+++ b/v4l/versions.txt  Sat Jan 16 16:56:28 2010 +0100
@@ -1,6 +1,10 @@
 # Use this for stuff for drivers that don't compile
 [2.6.99]

+[2.6.33]
+# Incompatible fifo API changes, see linux/kfifo.h
+VIDEO_CX23885
+
 [2.6.32]
 # These rely on arch support that wasn't available until 2.6.32
 VIDEO_SH_MOBILE_CEU

--
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] cx231xx: cleanup dvb_attach() return value handling

2010-01-16 Thread Németh Márton
From: Márton Németh nm...@freemail.hu

Remove the following sparse error (see make C=1):
 * error: incompatible types for operation ()
   left side has type struct dvb_frontend *
   right side has type int

Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 5bcdcc072b6d linux/drivers/media/video/cx231xx/cx231xx-dvb.c
--- a/linux/drivers/media/video/cx231xx/cx231xx-dvb.c   Sat Jan 16 07:25:43 
2010 +0100
+++ b/linux/drivers/media/video/cx231xx/cx231xx-dvb.c   Sat Jan 16 17:21:06 
2010 +0100
@@ -465,9 +465,9 @@
/* define general-purpose callback pointer */
dvb-frontend-callback = cx231xx_tuner_callback;

-   if (dvb_attach(xc5000_attach, dev-dvb-frontend,
+   if (!dvb_attach(xc5000_attach, dev-dvb-frontend,
   dev-i2c_bus[1].i2c_adap,
-  cnxt_rde250_tunerconfig)  0) {
+  cnxt_rde250_tunerconfig)) {
result = -EINVAL;
goto out_free;
}
@@ -487,9 +487,9 @@
/* define general-purpose callback pointer */
dvb-frontend-callback = cx231xx_tuner_callback;

-   if (dvb_attach(xc5000_attach, dev-dvb-frontend,
+   if (!dvb_attach(xc5000_attach, dev-dvb-frontend,
   dev-i2c_bus[1].i2c_adap,
-  cnxt_rde250_tunerconfig)  0) {
+  cnxt_rde250_tunerconfig)) {
result = -EINVAL;
goto out_free;
}
--
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] stv0900: make local functions static

2010-01-16 Thread Németh Márton
From: Márton Németh nm...@freemail.hu

The functions stv0900_sw_algo() and stv0900_set_dvbs1_track_car_loop() are only 
used
locally so mark them static.

This will remove the following sparse warnings (see make C=1):
 * symbol 'stv0900_sw_algo' was not declared. Should it be static?
 * symbol 'stv0900_set_dvbs1_track_car_loop' was not declared. Should it be 
static?

Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 5bcdcc072b6d linux/drivers/media/dvb/frontends/stv0900_sw.c
--- a/linux/drivers/media/dvb/frontends/stv0900_sw.cSat Jan 16 07:25:43 
2010 +0100
+++ b/linux/drivers/media/dvb/frontends/stv0900_sw.cSat Jan 16 17:34:44 
2010 +0100
@@ -193,7 +193,7 @@
return lock;
 }

-int stv0900_sw_algo(struct stv0900_internal *intp,
+static int stv0900_sw_algo(struct stv0900_internal *intp,
enum fe_stv0900_demod_num demod)
 {
int lock = FALSE,
@@ -795,7 +795,7 @@
return prate;
 }

-void stv0900_set_dvbs1_track_car_loop(struct stv0900_internal *intp,
+static void stv0900_set_dvbs1_track_car_loop(struct stv0900_internal *intp,
enum fe_stv0900_demod_num demod,
u32 srate)
 {

--
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] stv0900: make more local functions static

2010-01-16 Thread Németh Márton
From: Márton Németh nm...@freemail.hu

Some functions are only used locally so mark them static.

This will remove the following sparse warnings (see make C=1):
 * symbol 'extract_mask_pos' was not declared. Should it be static?
 * symbol 'stv0900_initialize' was not declared. Should it be static?
 * symbol 'stv0900_get_mclk_freq' was not declared. Should it be static?
 * symbol 'stv0900_set_mclk' was not declared. Should it be static?
 * symbol 'stv0900_get_err_count' was not declared. Should it be static?

Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 5bcdcc072b6d linux/drivers/media/dvb/frontends/stv0900_core.c
--- a/linux/drivers/media/dvb/frontends/stv0900_core.c  Sat Jan 16 07:25:43 
2010 +0100
+++ b/linux/drivers/media/dvb/frontends/stv0900_core.c  Sat Jan 16 17:37:59 
2010 +0100
@@ -177,7 +177,7 @@
return buf;
 }

-void extract_mask_pos(u32 label, u8 *mask, u8 *pos)
+static void extract_mask_pos(u32 label, u8 *mask, u8 *pos)
 {
u8 position = 0, i = 0;

@@ -218,7 +218,7 @@
return val;
 }

-enum fe_stv0900_error stv0900_initialize(struct stv0900_internal *intp)
+static enum fe_stv0900_error stv0900_initialize(struct stv0900_internal *intp)
 {
s32 i;

@@ -282,7 +282,7 @@
return STV0900_NO_ERROR;
 }

-u32 stv0900_get_mclk_freq(struct stv0900_internal *intp, u32 ext_clk)
+static u32 stv0900_get_mclk_freq(struct stv0900_internal *intp, u32 ext_clk)
 {
u32 mclk = 9000, div = 0, ad_div = 0;

@@ -296,7 +296,7 @@
return mclk;
 }

-enum fe_stv0900_error stv0900_set_mclk(struct stv0900_internal *intp, u32 mclk)
+static enum fe_stv0900_error stv0900_set_mclk(struct stv0900_internal *intp, 
u32 mclk)
 {
u32 m_div, clk_sel;

@@ -334,7 +334,7 @@
return STV0900_NO_ERROR;
 }

-u32 stv0900_get_err_count(struct stv0900_internal *intp, int cntr,
+static u32 stv0900_get_err_count(struct stv0900_internal *intp, int cntr,
enum fe_stv0900_demod_num demod)
 {
u32 lsb, msb, hsb, err_val;
--
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] ov534: allow enumerating supported framerates

2010-01-16 Thread Jean-Francois Moine
On Sat, 16 Jan 2010 15:33:45 +0100
Antonio Ospite osp...@studenti.unina.it wrote:

  Index: gspca/linux/drivers/media/video/gspca/ov534.c
  ===
  --- gspca.orig/linux/drivers/media/video/gspca/ov534.c
  +++ gspca/linux/drivers/media/video/gspca/ov534.c
  @@ -282,6 +282,21 @@
   .priv = 0},
   };
   
  +static const int qvga_rates[] = {125, 100, 75, 60, 50, 40, 30};
  +static const int vga_rates[] = {60, 50, 40, 30, 15};
  +
 
 Hmm, after double checking compilation messages, having these as
 'const' produces two:
   warning: initialization discards qualifiers from pointer target type
 in the assignments below.
 
 If I remove the 'const' qualifiers here, the messages go away, so I'd
 say we can do also without them. If that's ok I'll send a v2 soon,
 sorry.

Hi Antonio,

I recoded your patch with some changes, mainly in gspca.h. If it is
OK for you, may you sign it?

Best regards.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/


patch.pat
Description: Binary data


[PATCH] bt819: cleanup v4l2_subdev_notify() parameters

2010-01-16 Thread Németh Márton
From: Márton Németh nm...@freemail.hu

The 3rd parameter v4l2_subdev_notify() is passed to the notify() callback
which is a pointer, see media/v4l2-subdev.h and media/v4l2-device.h.

This will remove the following sparse warning (see make C=1):
 * Using plain integer as NULL pointer

Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 5bcdcc072b6d linux/drivers/media/video/bt819.c
--- a/linux/drivers/media/video/bt819.c Sat Jan 16 07:25:43 2010 +0100
+++ b/linux/drivers/media/video/bt819.c Sat Jan 16 18:04:27 2010 +0100
@@ -260,7 +260,7 @@
v4l2_err(sd, no notify found!\n);

if (std  V4L2_STD_NTSC) {
-   v4l2_subdev_notify(sd, BT819_FIFO_RESET_LOW, 0);
+   v4l2_subdev_notify(sd, BT819_FIFO_RESET_LOW, NULL);
bt819_setbit(decoder, 0x01, 0, 1);
bt819_setbit(decoder, 0x01, 1, 0);
bt819_setbit(decoder, 0x01, 5, 0);
@@ -269,7 +269,7 @@
/* bt819_setbit(decoder, 0x1a,  5, 1); */
timing = timing_data[1];
} else if (std  V4L2_STD_PAL) {
-   v4l2_subdev_notify(sd, BT819_FIFO_RESET_LOW, 0);
+   v4l2_subdev_notify(sd, BT819_FIFO_RESET_LOW, NULL);
bt819_setbit(decoder, 0x01, 0, 1);
bt819_setbit(decoder, 0x01, 1, 1);
bt819_setbit(decoder, 0x01, 5, 1);
@@ -294,7 +294,7 @@
bt819_write(decoder, 0x08, (timing-hscale  8)  0xff);
bt819_write(decoder, 0x09, timing-hscale  0xff);
decoder-norm = std;
-   v4l2_subdev_notify(sd, BT819_FIFO_RESET_HIGH, 0);
+   v4l2_subdev_notify(sd, BT819_FIFO_RESET_HIGH, NULL);
return 0;
 }

@@ -312,7 +312,7 @@
v4l2_err(sd, no notify found!\n);

if (decoder-input != input) {
-   v4l2_subdev_notify(sd, BT819_FIFO_RESET_LOW, 0);
+   v4l2_subdev_notify(sd, BT819_FIFO_RESET_LOW, NULL);
decoder-input = input;
/* select mode */
if (decoder-input == 0) {
@@ -322,7 +322,7 @@
bt819_setbit(decoder, 0x0b, 6, 1);
bt819_setbit(decoder, 0x1a, 1, 0);
}
-   v4l2_subdev_notify(sd, BT819_FIFO_RESET_HIGH, 0);
+   v4l2_subdev_notify(sd, BT819_FIFO_RESET_HIGH, NULL);
}
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: PULL http://jusst.de/hg/stv090x

2010-01-16 Thread Manu Abraham
On Sat, Jan 16, 2010 at 5:14 PM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 Hi Andreas,

 Andreas Regel wrote:

 you don't have to look at stv090x_i2c_gate_ctrl alone. stv090x driver
 contains code like this:

     if (stv090x_i2c_gate_ctrl(fe, 1)  0)
         goto err;

     tuner access

     if (stv090x_i2c_gate_ctrl(fe, 0)  0)
         goto err;

 Ok. It is very unusual to have a lock internally like the above, since
 the code becomes poorly documented.


That's how a tuner is accessed for any dvb device.


 In the cases that we want to do things like that, it is documented like:

     if (stv090x_gate_enable_lock(fe)  0)
         goto err;

     tuner access

     if (stv090x_gate_disable_unlock(fe, 0)  0)
         goto err;



To me, that looks horrible and do non-intuitive. I would have to read
those functions additionally to understand the implications of the
same. What you suggest, will look to a user at initial glance it would
seem that you are trying to lock register access, while it is not.

I don't agree with your comment on this one.


 This way, it is clear to anyone that is reviewing the code that the functions
 are returning with the lock on a different state and prevent the kernel 
 janitors
 to send patches that will try to fix the lock.

 I bet that their coccinelle rules will generate some false alarms with the 
 current code.


We will wait and see, since there is nothing wrong in the semantic
construct in there. It is just that the gate control for that device
is slightly different from other devices, due to the difference in the
device type and the mode of operation.


Regards,
Manu
--
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


camera with high framerate

2010-01-16 Thread rath

Hi,

I'm searching a v4l supported webcam with a framerate higher than 30fps. I 
found the Playstation Eye and it seems to have a framerate of up to 120fps 
@320x240 pixels.
Does this camera support a resolution of 160x120 pixels? How are the images 
transfered over usb (jpeg, rgb, yuv)?


Are there any other cameras avaiable with a minimum framerate of 60fps?

Regards, Joern 


--
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] dib0090: cleanup dib0090_dcc_freq()

2010-01-16 Thread Németh Márton
From: Márton Németh nm...@freemail.hu

'extern' is not needed at function definition.

This will remove the following sparse warning (see make C=1):
 * function 'dib0090_dcc_freq' with external linkage has definition

Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 5bcdcc072b6d linux/drivers/media/dvb/frontends/dib0090.c
--- a/linux/drivers/media/dvb/frontends/dib0090.c   Sat Jan 16 07:25:43 
2010 +0100
+++ b/linux/drivers/media/dvb/frontends/dib0090.c   Sat Jan 16 18:33:43 
2010 +0100
@@ -283,7 +283,7 @@
return 0;
 }

-extern void dib0090_dcc_freq(struct dvb_frontend *fe, u8 fast)
+void dib0090_dcc_freq(struct dvb_frontend *fe, u8 fast)
 {
struct dib0090_state *state = fe-tuner_priv;
if (fast)
--
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


TT S2-3200 Infrared

2010-01-16 Thread Alexander Dilevskiy

Hi guys!

I was playing with my Technotrend S2-3200 card (bidget-ci driver) and 
found the driver selected a wrong IR remote keymap 
(ir_codes_budget_ci_old instead of ir_codes_tt_1500) because my 
subsystem_device ID 0x1019 was not present in the corresponding

switch (budget_ci-budget.dev-pci-subsystem_device).

Adding case 0x1019: fixed the issue.

Shall I just post the patch to this maillist or send it to the budget-ci 
driver maintainer (who's that guy?) ?



Regards,
Alex
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: PULL http://jusst.de/hg/stv090x

2010-01-16 Thread Oliver Endriss
Hi,

Mauro Carvalho Chehab wrote:
 Hi Andreas,
 
 Andreas Regel wrote:
  
  you don't have to look at stv090x_i2c_gate_ctrl alone. stv090x driver
  contains code like this:
  
  if (stv090x_i2c_gate_ctrl(fe, 1)  0)
  goto err;
  
  tuner access
  
  if (stv090x_i2c_gate_ctrl(fe, 0)  0)
  goto err;
 
 Ok. It is very unusual to have a lock internally like the above, since
 the code becomes poorly documented.
 
 In the cases that we want to do things like that, it is documented like:
 
  if (stv090x_gate_enable_lock(fe)  0)
  goto err;
  
  tuner access
  
  if (stv090x_gate_disable_unlock(fe, 0)  0)
  goto err;
 
 This way, it is clear to anyone that is reviewing the code that the functions
 are returning with the lock on a different state and prevent the kernel 
 janitors
 to send patches that will try to fix the lock.

You cannot do that, because there is _one_ entry in
struct dvb_frontend_ops:
.i2c_gate_ctrl = stv090x_i2c_gate_ctrl;
This function must open/close the I2C gate.

 ...
 After the patch, the lock is fine, but we still need to better document it,
 in order to save time from reviewers and janitors.

I agree that some comments should be added to stv090x_i2c_gate_ctrl,
explaining why the mutex is required.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/

--
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: camera with high framerate

2010-01-16 Thread Jean-Francois Moine
On Sat, 16 Jan 2010 18:33:54 +0100
rath maili...@hardware-datenbank.de wrote:

 I'm searching a v4l supported webcam with a framerate higher than
 30fps. I found the Playstation Eye and it seems to have a framerate
 of up to 120fps @320x240 pixels.
 Does this camera support a resolution of 160x120 pixels? How are the
 images transfered over usb (jpeg, rgb, yuv)?

Hi Joern,

The resolutions are only 640x480 and 320x240. The images are transfered
in YUYV (16 bits YUV 4:2:2).

Regards.

-- 
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: [PATCH] disable building cx23885 before 2.6.33

2010-01-16 Thread Andy Walls
On Sat, 2010-01-16 at 17:02 +0100, Németh Márton wrote:
 From: Márton Németh nm...@freemail.hu
 
 The cx23885 driver does not compile before Linux kernel 2.6.33 because of
 incompatible fifo API changes. Disable this driver being built before
 2.6.33.
 
 Signed-off-by: Márton Németh nm...@freemail.hu

Nak.

1. You forgot meye - it's broken as well in the same way.
2. Douglas has issuesd a PULL request for a back port fix that will
resolve the issue.

Regards,
Andy

 ---
 diff -r 5bcdcc072b6d v4l/versions.txt
 --- a/v4l/versions.txtSat Jan 16 07:25:43 2010 +0100
 +++ b/v4l/versions.txtSat Jan 16 16:56:28 2010 +0100
 @@ -1,6 +1,10 @@
  # Use this for stuff for drivers that don't compile
  [2.6.99]
 
 +[2.6.33]
 +# Incompatible fifo API changes, see linux/kfifo.h
 +VIDEO_CX23885
 +
  [2.6.32]
  # These rely on arch support that wasn't available until 2.6.32
  VIDEO_SH_MOBILE_CEU
 


--
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 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

2010-01-16 Thread Hans Verkuil
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:Sat Jan 16 19:00:09 CET 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14007:b48871e88d7d
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.33-rc2-armv5: OK
linux-2.6.32-armv5-davinci: WARNINGS
linux-2.6.33-rc2-armv5-davinci: WARNINGS
linux-2.6.30-armv5-ixp: WARNINGS
linux-2.6.31-armv5-ixp: WARNINGS
linux-2.6.32-armv5-ixp: WARNINGS
linux-2.6.33-rc2-armv5-ixp: WARNINGS
linux-2.6.30-armv5-omap2: WARNINGS
linux-2.6.31-armv5-omap2: WARNINGS
linux-2.6.32-armv5-omap2: WARNINGS
linux-2.6.33-rc2-armv5-omap2: WARNINGS
linux-2.6.22.19-i686: WARNINGS
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: ERRORS
linux-2.6.31-i686: ERRORS
linux-2.6.32-i686: ERRORS
linux-2.6.33-rc2-i686: WARNINGS
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.32-m32r: OK
linux-2.6.33-rc2-m32r: OK
linux-2.6.30-mips: WARNINGS
linux-2.6.31-mips: WARNINGS
linux-2.6.32-mips: WARNINGS
linux-2.6.33-rc2-mips: WARNINGS
linux-2.6.30-powerpc64: ERRORS
linux-2.6.31-powerpc64: ERRORS
linux-2.6.32-powerpc64: ERRORS
linux-2.6.33-rc2-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: WARNINGS
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: ERRORS
linux-2.6.31-x86_64: ERRORS
linux-2.6.32-x86_64: ERRORS
linux-2.6.33-rc2-x86_64: WARNINGS
spec: OK
sparse (linux-2.6.32): ERRORS
sparse (linux-2.6.33-rc2): 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: WARNINGS
linux-2.6.20.21-i686: WARNINGS
linux-2.6.21.7-i686: WARNINGS
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: WARNINGS
linux-2.6.20.21-x86_64: WARNINGS
linux-2.6.21.7-x86_64: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Need testers: cx23885 IR Rx for TeVii S470 and HVR-1250

2010-01-16 Thread Andy Walls
On Sat, 2010-01-16 at 16:00 +0200, Igor M. Liplianin wrote:
 On 16 января 2010 06:02:41 Andy Walls wrote:
  Hi,
 
  I've got reworked changes for the IR for the TeVii S470 and the HVR-1250
  at
 
  http://linuxtv.org/hg/~awalls/cx23885-ir2
 
  Thanks to loaner HVR-1250 hardware from Devin Heitmueller,
  I've solved the infinite interrupt problem with the CX23885 AV core and
  have reworked the change set against the latest v4l-dvb.
 
  Please test.
 
  Note
 
  1. the parameters for the IR controller setup in
  linux/drivers/video/cx23885-input.c may need to be tweaked to set the
  proper params.modulation and params.invert_level before you get
  keypresses decoded.
 
 It works properly with settings
 
   params.modulation = false;
   params.invert_level = true;

Thanks.  I have checked in a change the code for this.


 But after couple seconds :(
 
 cx25840 3-0044: IRQ Status:  tsr rsr rto
 cx25840 3-0044: IRQ Enables: rse rte roe
 cx25840 3-0044: rx read:9046778 ns  mark
 cx25840 3-0044: rx read:2206333 ns  space
 cx25840 3-0044: rx read: 606926 ns  mark
 cx25840 3-0044: rx read: end of rx
 cx25840 3-0044: IRQ Status:  tsr rsr rto
 cx25840 3-0044: IRQ Enables: rse rte roe
 cx25840 3-0044: rx read:9055815 ns  mark
 cx25840 3-0044: rx read:2203519 ns  space
 cx25840 3-0044: rx read: 582481 ns  mark
 cx25840 3-0044: rx read: end of rx

This is still good. :)

Those are NEC repeat sequences, but you probably know that already.


 irq 16: nobody cared (try booting with the irqpoll option)
 Pid: 2971, comm: X Not tainted 2.6.33-rc4 #3
 Call Trace:
  [c1054700] ? __report_bad_irq+0x24/0x69
[...]
  [c1425105] ? syscall_call+0x7/0xb
 handlers:
 [c1332132] (usb_hcd_irq+0x0/0x59)
 [f8aafd88] (cx23885_irq+0x0/0x4e0 [cx23885])


I have checked in more changes to 

http://linuxtv.org/hg/~awalls/cx23885-ir2

Please test again using these module parameters:

modprobe cx25840 ir_debug=2 debug=2
modprobe cx23885 ir_input_debug=2 irq_debug=7 debug=7


I am looking for logging of the interrupt statuses and enables.  They
should look something like this:


 kernel: cx23885[0]/0: pci_status: 0x0800  pci_mask: 0x0801
 [...]
 kernel: cx23885[0]/0:  (PCI_MSK_AV_CORE   0x0800)
 kernel: cx25840 6-0044: AV Core IRQ status (entry): ir
 kernel: cx25840 6-0044: AV Core ir IRQ status: 0x31 disables: 0x20
 kernel: cx25840 6-0044: IR IRQ Status:  tsr rsr rto
 kernel: cx25840 6-0044: IR IRQ Enables: rse rte roe
 kernel: cx25840 6-0044: AV Core audio IRQ status: 0x80 disables: 0xff
 kernel: cx25840 6-0044: AV Core audio MC IRQ status: 0x2000 enables: 0x
 kernel: cx25840 6-0044: AV Core video IRQ status: 0x01a7 disables: 0x
 kernel: cx25840 6-0044: AV Core IRQ status (exit):   


But I was able to reproduce something like this when changing enable the
TSR interrupt enables using v4l2-dbg to change the register manually:

 kernel: cx23885[0]/0: pci_status: 0x0830  pci_mask: 0x0801
 [...]
 kernel: cx23885[0]/0:  (PCI_MSK_AV_CORE   0x0800)
 kernel: cx25840 6-0044: AV Core IRQ status (entry):   
 no irq flags (all 0's)
 kernel: cx25840 6-0044: AV Core ir IRQ status: 0x00 disables: 0x00
 all 0's
 kernel: cx25840 6-0044: AV Core audio IRQ status: 0x00 disables: 0x00 
 all 0's
 kernel: cx25840 6-0044: AV Core audio MC IRQ status: 0x enables: 0x   
 all 0's
 kernel: cx25840 6-0044: AV Core video IRQ status: 0x disables: 0x 
 all 0's
 kernel: cx25840 6-0044: AV Core IRQ status (exit):   

So there are some conditions where the AV Core can signal an interrupt,
but not be ready to be read over the I2C bus.

I have added code to count when these happen and handle them as spurious
interrupts.  However, if the code gets too many (20) consecutive
spurious interrupts without at least one real one, it disables the AV
Core interrupt.


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


Re: camera with high framerate

2010-01-16 Thread rath
Okay, are there some other cameras avaiable with 160x120 pixels or output in 
rgb? I only have an ARM Cortex-A8 with 500MHz to process the image data and 
converting between different pixelformats take a long time. So it would be 
fine if a resolution of 160x120 pixels is supported or the output is in rgb.


- Original Message - 
From: Jean-Francois Moine moin...@free.fr

To: rath maili...@hardware-datenbank.de
Cc: linux-media@vger.kernel.org
Sent: Saturday, January 16, 2010 7:14 PM
Subject: Re: camera with high framerate


On Sat, 16 Jan 2010 18:33:54 +0100
rath maili...@hardware-datenbank.de wrote:


I'm searching a v4l supported webcam with a framerate higher than
30fps. I found the Playstation Eye and it seems to have a framerate
of up to 120fps @320x240 pixels.
Does this camera support a resolution of 160x120 pixels? How are the
images transfered over usb (jpeg, rgb, yuv)?


Hi Joern,

The resolutions are only 640x480 and 320x240. The images are transfered
in YUYV (16 bits YUV 4:2:2).

Regards.

--
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: camera with high framerate

2010-01-16 Thread Michael Trimarchi

rath wrote:
Okay, are there some other cameras avaiable with 160x120 pixels or 
output in rgb? I only have an ARM Cortex-A8 with 500MHz to process the 
image data and converting between different pixelformats take a long 
time. So it would be fine if a resolution of 160x120 pixels is supported 
or the output is in rgb.


ov538-ov7690 solution

static const struct v4l2_pix_format vga_mode[] = {

   { 176, 144, V4L2_PIX_FMT_YUYV, V4L2_FIELD_NONE,
.bytesperline = 176 * 2,
.sizeimage = 176 * 144 * 2,
.colorspace = V4L2_COLORSPACE_SRGB,
.priv = size176_144 },

I think that it has the 160x120 resolution too, but I don't write the code for 
that.
The sensor arrive at 60 fps in QVGA mode

Michael



- Original Message - From: Jean-Francois Moine moin...@free.fr
To: rath maili...@hardware-datenbank.de
Cc: linux-media@vger.kernel.org
Sent: Saturday, January 16, 2010 7:14 PM
Subject: Re: camera with high framerate


On Sat, 16 Jan 2010 18:33:54 +0100
rath maili...@hardware-datenbank.de wrote:


I'm searching a v4l supported webcam with a framerate higher than
30fps. I found the Playstation Eye and it seems to have a framerate
of up to 120fps @320x240 pixels.
Does this camera support a resolution of 160x120 pixels? How are the
images transfered over usb (jpeg, rgb, yuv)?


Hi Joern,

The resolutions are only 640x480 and 320x240. The images are transfered
in YUYV (16 bits YUV 4:2:2).

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


Re: [PATCH] ov534: allow enumerating supported framerates

2010-01-16 Thread Antonio Ospite
On Sat, 16 Jan 2010 17:47:49 +0100
Jean-Francois Moine moin...@free.fr wrote:

 Hi Antonio,
 
 I recoded your patch with some changes, mainly in gspca.h. If it is
 OK for you, may you sign it?
 

Ok, that's even better.

Signed-off-by: Antonio Ospite osp...@studenti.unina.it

 Best regards.
 
 -- 
 Ken ar c'hentañ   | ** Breizh ha Linux atav! **
 Jef   |   http://moinejf.free.fr/

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


pgpY6YNSsoTvG.pgp
Description: PGP signature


[PATCH] ov534: fix end of frame handling, make the camera work again.

2010-01-16 Thread Antonio Ospite
Fix a regression, probably introduced in the driver split, which made
the ov534 driver unusable: every last packet was discarded because we
were mis-calculating the frame size before actually adding the packet.

Plus, the debug message should reflect that we discard also packets
beyond the expected frame size.

Signed-off-by: Antonio Ospite osp...@studenti.unina.it
Cc: Max Thrun bear2...@gmail.com
---

Max, can you test this as well? This should be better than removing all
the discard logic at once. After this is in I'll keep working on your
changes.

Jean-Francois, if this is proven to be the right thing to do, it should
go mainline along with the driver split.

Thanks,
   Antonio Ospite

Index: gspca/linux/drivers/media/video/gspca/ov534.c
===
--- gspca.orig/linux/drivers/media/video/gspca/ov534.c
+++ gspca/linux/drivers/media/video/gspca/ov534.c
@@ -992,9 +992,9 @@
frame = gspca_get_i_frame(gspca_dev);
if (frame == NULL)
goto discard;
-   if (frame-data_end - frame-data !=
+   if (frame-data_end - frame-data + (len - 12) !=
gspca_dev-width * gspca_dev-height * 2) {
-   PDEBUG(D_PACK, short frame);
+   PDEBUG(D_PACK, wrong sized frame);
goto discard;
}
gspca_frame_add(gspca_dev, LAST_PACKET,
--
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: Need testers: cx23885 IR Rx for TeVii S470 and HVR-1250

2010-01-16 Thread Igor M. Liplianin
On 16 января 2010 21:55:52 Andy Walls wrote:
  cx25840 3-0044: IRQ Status:  tsr rsr rto
  cx25840 3-0044: IRQ Enables: rse rte roe
  cx25840 3-0044: rx read:9046778 ns  mark
  cx25840 3-0044: rx read:2206333 ns  space
  cx25840 3-0044: rx read: 606926 ns  mark
  cx25840 3-0044: rx read: end of rx
  cx25840 3-0044: IRQ Status:  tsr rsr rto
  cx25840 3-0044: IRQ Enables: rse rte roe
  cx25840 3-0044: rx read:9055815 ns  mark
  cx25840 3-0044: rx read:2203519 ns  space
  cx25840 3-0044: rx read: 582481 ns  mark
  cx25840 3-0044: rx read: end of rx

 This is still good. :)

 Those are NEC repeat sequences, but you probably know that already.
Remote works until that point


  irq 16: nobody cared (try booting with the irqpoll option)
  Pid: 2971, comm: X Not tainted 2.6.33-rc4 #3
  Call Trace:
   [c1054700] ? __report_bad_irq+0x24/0x69

 [...]

   [c1425105] ? syscall_call+0x7/0xb
  handlers:
  [c1332132] (usb_hcd_irq+0x0/0x59)
  [f8aafd88] (cx23885_irq+0x0/0x4e0 [cx23885])

 I have checked in more changes to

   http://linuxtv.org/hg/~awalls/cx23885-ir2

 Please test again using these module parameters:

   modprobe cx25840 ir_debug=2 debug=2
   modprobe cx23885 ir_input_debug=2 irq_debug=7 debug=7


 I am looking for logging of the interrupt statuses and enables.  They
 should look something like this:


  kernel: cx23885[0]/0: pci_status: 0x0800  pci_mask: 0x0801
  [...]
  kernel: cx23885[0]/0:  (PCI_MSK_AV_CORE   0x0800)
  kernel: cx25840 6-0044: AV Core IRQ status (entry): ir
  kernel: cx25840 6-0044: AV Core ir IRQ status: 0x31 disables: 0x20
  kernel: cx25840 6-0044: IR IRQ Status:  tsr rsr rto
  kernel: cx25840 6-0044: IR IRQ Enables: rse rte roe
  kernel: cx25840 6-0044: AV Core audio IRQ status: 0x80 disables: 0xff
  kernel: cx25840 6-0044: AV Core audio MC IRQ status: 0x2000 enables:
 0x kernel: cx25840 6-0044: AV Core video IRQ status: 0x01a7 disables:
 0x kernel: cx25840 6-0044: AV Core IRQ status (exit):


 But I was able to reproduce something like this when changing enable the
 TSR interrupt enables using v4l2-dbg to change the register manually:

  kernel: cx23885[0]/0: pci_status: 0x0830  pci_mask: 0x0801
  [...]
  kernel: cx23885[0]/0:  (PCI_MSK_AV_CORE   0x0800)
  kernel: cx25840 6-0044: AV Core IRQ status (entry):   
 no irq flags (all 0's) kernel: cx25840 6-0044: AV Core ir IRQ
 status: 0x00 disables: 0x00 all 0's kernel: cx25840
 6-0044: AV Core audio IRQ status: 0x00 disables: 0x00  all 0's
 kernel: cx25840 6-0044: AV Core audio MC IRQ status: 0x enables: 0x
    all 0's kernel: cx25840 6-0044: AV Core video IRQ status: 0x
 disables: 0x  all 0's kernel: cx25840 6-0044: AV Core IRQ
 status (exit):

 So there are some conditions where the AV Core can signal an interrupt,
 but not be ready to be read over the I2C bus.

 I have added code to count when these happen and handle them as spurious
 interrupts.  However, if the code gets too many (20) consecutive
 spurious interrupts without at least one real one, it disables the AV
 Core interrupt.


 Regards,
 Andy
Spurious interrupts counter reaches #20 almost immediately after modprobe.
There is no time to press a key.

DVB: registering adapter 0 frontend 0 (Montage Technology DS3000/TS2020)...
cx23885_dev_checkrevision() Hardware revision = 0xb0
cx23885[0]/0: found at :01:00.0, rev: 2, irq: 16, latency: 0, mmio: 
0xfe80
cx23885 :01:00.0: setting latency timer to 64
IRQ 16/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs
cx23885[0]/0: pci_status: 0x083f4000  pci_mask: 0x0800
cx23885[0]/0: vida_status: 0x vida_mask: 0x count: 0x0
cx23885[0]/0: ts1_status: 0x  ts1_mask: 0x count: 0x0
cx23885[0]/0: ts2_status: 0x  ts2_mask: 0x count: 0xc7381f2a
cx23885[0]/0:  (PCI_MSK_AV_CORE   0x0800)
cx25840 3-0044: AV Core IRQ status (entry):   
cx25840 3-0044: AV Core ir IRQ status: 0x00 disables: 0x00
cx25840 3-0044: AV Core audio IRQ status: 0x00 disables: 0x00
cx25840 3-0044: AV Core audio MC IRQ status: 0x enables: 0x
cx25840 3-0044: AV Core video IRQ status: 0x disables: 0x
cx25840 3-0044: AV Core IRQ status (exit):   
cx23885[0]/0:  consecutive spurious AV Core interrupt #1
[...]
cx23885[0]/0: pci_status: 0x08004000  pci_mask: 0x0800
cx23885[0]/0: vida_status: 0x vida_mask: 0x count: 0x0
cx23885[0]/0: ts1_status: 0x  ts1_mask: 0x count: 0x0
cx23885[0]/0: ts2_status: 0x  ts2_mask: 0x count: 0xc7381f2a
cx23885[0]/0:  (PCI_MSK_AV_CORE   0x0800)
cx25840 3-0044: AV Core IRQ status (entry):   
cx25840 3-0044: AV Core ir IRQ status: 0x00 disables: 0x00
cx25840 3-0044: AV Core audio IRQ status: 0x00 disables: 0x00
cx25840 3-0044: AV Core audio MC IRQ status: 0x enables: 0x
cx25840 3-0044: AV Core video IRQ status: 0x 

Re: [PATCH] ov534: fix end of frame handling, make the camera work again.

2010-01-16 Thread Max Thrun
Thanks for the patch Antonio

I can confirm that this patch does fix the problem, definitely needs
to be merged asap as the webcam is unusable without.

- Max Thrun
--
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: How to use saa7134 gpio via gpio-sysfs?

2010-01-16 Thread hermann pitton

Am Samstag, den 16.01.2010, 04:15 -0800 schrieb Trent Piepho:
 On Sat, 16 Jan 2010, hermann pitton wrote:
  Am Freitag, den 15.01.2010, 17:27 -0800 schrieb Trent Piepho:
   On Sat, 16 Jan 2010, hermann pitton wrote:
Am Dienstag, den 12.01.2010, 04:13 +0100 schrieb hermann pitton:
  gpio-sysfs creates
  /sys/class/gpio/export
  /sys/class/gpio/import
  but no gpion entries so far.
  
   The saa713x driver predates the generic gpio layer by years and years, so
   it doesn't use it.  It also doesn't need to use it.  Since the gpios are
   managed by the saa713x driver, and they also used by the saa713x driver,
   there is no need to interface two different drivers together.  There are
   tons of drivers for devices that have gpios like this, but they don't use
   the gpio layer.
  
   But with gpio access via sysfs for generic gpios, there is something 
   useful
   about having the saa713x driver support generic gpios.  IIRC, somehow 
   wrote
   a gpio only bt848 driver that didn't do anything but export gpios.
  
   In order to do this, you'll have to write code for the saa7134 driver to
   have it register with the gpio layer.  I think you could still have the
   saa7134 driver itself use its gpio directly.  That would avoid a
   performance penalty in the driver.
 
  Thanks for more details, but I'm still wondering what pins ever could be
  interesting in userland, given that they are all treated such different
  per device, and we count up to 200 different boards these days.
 
 There are some cards for intended for survilence or embedded applications
 that have headers on them to connect things to the GPIOs.  Like alarms or
 camera controllers and stuff like that.
 
 The GPIO only bttv driver was created by someone who just soldered a bunch
 of wires on a cheap bt848 card, you can get them for just a few dollars, as
 it was a cheap and easy way to get a bunch of gpios in a pc.  See his page
 here http://www.bu3sch.de/joomla/index.php/bt8xx-based-gpio-card
 
 There are cards you can get that just have GPIOs, but they end up being
 rather expensive.  Here's one:
 http://www.acromag.com/parts.cfm?Model_ID=317Product_Function_ID=4Category_ID=18Group_ID=1
 Way fancier than a tv card, but it's $600.
 
 I think if I was doing the coding, I'd add a field in the card description
 for what GPIOs should be exported.  I.e., which ones have an external
 header.  Maybe in addition to, or instead of, I'd have a module option that
 would cause GPIOs to be exported.  A bitmask of which to export would be
 enough.

Cool stuff!

Are we aware of boards under mass production connecting unused gpios to
a panel already, providing external gpio functionality?

The RTD one in question seems not to do so yet.

http://www.rtd.com/pc104/UM/video/VFG7350ER.htm

Thanks,
Hermann


--
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: How to use saa7134 gpio via gpio-sysfs?

2010-01-16 Thread hermann pitton

Am Sonntag, den 17.01.2010, 01:08 +0100 schrieb hermann pitton:
 Am Samstag, den 16.01.2010, 04:15 -0800 schrieb Trent Piepho:
  On Sat, 16 Jan 2010, hermann pitton wrote:
   Am Freitag, den 15.01.2010, 17:27 -0800 schrieb Trent Piepho:
On Sat, 16 Jan 2010, hermann pitton wrote:
 Am Dienstag, den 12.01.2010, 04:13 +0100 schrieb hermann pitton:
   gpio-sysfs creates
   /sys/class/gpio/export
   /sys/class/gpio/import
   but no gpion entries so far.
   
The saa713x driver predates the generic gpio layer by years and years, 
so
it doesn't use it.  It also doesn't need to use it.  Since the gpios are
managed by the saa713x driver, and they also used by the saa713x driver,
there is no need to interface two different drivers together.  There are
tons of drivers for devices that have gpios like this, but they don't 
use
the gpio layer.
   
But with gpio access via sysfs for generic gpios, there is something 
useful
about having the saa713x driver support generic gpios.  IIRC, somehow 
wrote
a gpio only bt848 driver that didn't do anything but export gpios.
   
In order to do this, you'll have to write code for the saa7134 driver to
have it register with the gpio layer.  I think you could still have the
saa7134 driver itself use its gpio directly.  That would avoid a
performance penalty in the driver.
  
   Thanks for more details, but I'm still wondering what pins ever could be
   interesting in userland, given that they are all treated such different
   per device, and we count up to 200 different boards these days.
  
  There are some cards for intended for survilence or embedded applications
  that have headers on them to connect things to the GPIOs.  Like alarms or
  camera controllers and stuff like that.
  
  The GPIO only bttv driver was created by someone who just soldered a bunch
  of wires on a cheap bt848 card, you can get them for just a few dollars, as
  it was a cheap and easy way to get a bunch of gpios in a pc.  See his page
  here http://www.bu3sch.de/joomla/index.php/bt8xx-based-gpio-card
  
  There are cards you can get that just have GPIOs, but they end up being
  rather expensive.  Here's one:
  http://www.acromag.com/parts.cfm?Model_ID=317Product_Function_ID=4Category_ID=18Group_ID=1
  Way fancier than a tv card, but it's $600.
  
  I think if I was doing the coding, I'd add a field in the card description
  for what GPIOs should be exported.  I.e., which ones have an external
  header.  Maybe in addition to, or instead of, I'd have a module option that
  would cause GPIOs to be exported.  A bitmask of which to export would be
  enough.
 
 Cool stuff!
 
 Are we aware of boards under mass production connecting unused gpios to
 a panel already, providing external gpio functionality?
 
 The RTD one in question seems not to do so yet.
 
 http://www.rtd.com/pc104/UM/video/VFG7350ER.htm

Damned, seems the opto-isolated I/Os might be in question.

For the RTD stuff we don't have any high resolution photographs or
anything else ...


--
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: Need testers: cx23885 IR Rx for TeVii S470 and HVR-1250

2010-01-16 Thread Andy Walls
On Sat, 2010-01-16 at 23:56 +0200, Igor M. Liplianin wrote:
 On 16 января 2010 21:55:52 Andy Walls wrote:
   cx25840 3-0044: IRQ Status:  tsr rsr rto
   cx25840 3-0044: IRQ Enables: rse rte roe
   cx25840 3-0044: rx read:9046778 ns  mark
   cx25840 3-0044: rx read:2206333 ns  space
   cx25840 3-0044: rx read: 606926 ns  mark
   cx25840 3-0044: rx read: end of rx
   cx25840 3-0044: IRQ Status:  tsr rsr rto
   cx25840 3-0044: IRQ Enables: rse rte roe
   cx25840 3-0044: rx read:9055815 ns  mark
   cx25840 3-0044: rx read:2203519 ns  space
   cx25840 3-0044: rx read: 582481 ns  mark
   cx25840 3-0044: rx read: end of rx
 
  This is still good. :)
 
  Those are NEC repeat sequences, but you probably know that already.
 Remote works until that point
 
 
   irq 16: nobody cared (try booting with the irqpoll option)
   Pid: 2971, comm: X Not tainted 2.6.33-rc4 #3
   Call Trace:
[c1054700] ? __report_bad_irq+0x24/0x69
 
  [...]
 
[c1425105] ? syscall_call+0x7/0xb
   handlers:
   [c1332132] (usb_hcd_irq+0x0/0x59)
   [f8aafd88] (cx23885_irq+0x0/0x4e0 [cx23885])
 
  I have checked in more changes to
 
  http://linuxtv.org/hg/~awalls/cx23885-ir2
 
  Please test again using these module parameters:
 
  modprobe cx25840 ir_debug=2 debug=2
  modprobe cx23885 ir_input_debug=2 irq_debug=7 debug=7
 
 
  I am looking for logging of the interrupt statuses and enables.  They
  should look something like this:
 
 
   kernel: cx23885[0]/0: pci_status: 0x0800  pci_mask: 0x0801
   [...]
   kernel: cx23885[0]/0:  (PCI_MSK_AV_CORE   0x0800)
   kernel: cx25840 6-0044: AV Core IRQ status (entry): ir
   kernel: cx25840 6-0044: AV Core ir IRQ status: 0x31 disables: 0x20
   kernel: cx25840 6-0044: IR IRQ Status:  tsr rsr rto
   kernel: cx25840 6-0044: IR IRQ Enables: rse rte roe
   kernel: cx25840 6-0044: AV Core audio IRQ status: 0x80 disables: 0xff
   kernel: cx25840 6-0044: AV Core audio MC IRQ status: 0x2000 enables:
  0x kernel: cx25840 6-0044: AV Core video IRQ status: 0x01a7 disables:
  0x kernel: cx25840 6-0044: AV Core IRQ status (exit):
 
 
  But I was able to reproduce something like this when changing enable the
  TSR interrupt enables using v4l2-dbg to change the register manually:
 
   kernel: cx23885[0]/0: pci_status: 0x0830  pci_mask: 0x0801
   [...]
   kernel: cx23885[0]/0:  (PCI_MSK_AV_CORE   0x0800)
   kernel: cx25840 6-0044: AV Core IRQ status (entry):   
  no irq flags (all 0's) kernel: cx25840 6-0044: AV Core ir IRQ
  status: 0x00 disables: 0x00 all 0's kernel: cx25840
  6-0044: AV Core audio IRQ status: 0x00 disables: 0x00  all 0's
  kernel: cx25840 6-0044: AV Core audio MC IRQ status: 0x enables: 0x
 all 0's kernel: cx25840 6-0044: AV Core video IRQ status: 0x
  disables: 0x  all 0's kernel: cx25840 6-0044: AV Core IRQ
  status (exit):
 
  So there are some conditions where the AV Core can signal an interrupt,
  but not be ready to be read over the I2C bus.
 
  I have added code to count when these happen and handle them as spurious
  interrupts.  However, if the code gets too many (20) consecutive
  spurious interrupts without at least one real one, it disables the AV
  Core interrupt.
 
 
  Regards,
  Andy
 Spurious interrupts counter reaches #20 almost immediately after modprobe.
 There is no time to press a key.
 
 DVB: registering adapter 0 frontend 0 (Montage Technology DS3000/TS2020)...
 cx23885_dev_checkrevision() Hardware revision = 0xb0
 cx23885[0]/0: found at :01:00.0, rev: 2, irq: 16, latency: 0, mmio: 
 0xfe80
 cx23885 :01:00.0: setting latency timer to 64
 IRQ 16/cx23885[0]: IRQF_DISABLED is not guaranteed on shared IRQs
 cx23885[0]/0: pci_status: 0x083f4000  pci_mask: 0x0800
 cx23885[0]/0: vida_status: 0x vida_mask: 0x count: 0x0
 cx23885[0]/0: ts1_status: 0x  ts1_mask: 0x count: 0x0
 cx23885[0]/0: ts2_status: 0x  ts2_mask: 0x count: 0xc7381f2a
 cx23885[0]/0:  (PCI_MSK_AV_CORE   0x0800)
 cx25840 3-0044: AV Core IRQ status (entry):   
 cx25840 3-0044: AV Core ir IRQ status: 0x00 disables: 0x00
 cx25840 3-0044: AV Core audio IRQ status: 0x00 disables: 0x00
 cx25840 3-0044: AV Core audio MC IRQ status: 0x enables: 0x
 cx25840 3-0044: AV Core video IRQ status: 0x disables: 0x
 cx25840 3-0044: AV Core IRQ status (exit):   
 cx23885[0]/0:  consecutive spurious AV Core interrupt #1
 [...]
 cx23885[0]/0: pci_status: 0x08004000  pci_mask: 0x0800
 cx23885[0]/0: vida_status: 0x vida_mask: 0x count: 0x0
 cx23885[0]/0: ts1_status: 0x  ts1_mask: 0x count: 0x0
 cx23885[0]/0: ts2_status: 0x  ts2_mask: 0x count: 0xc7381f2a
 cx23885[0]/0:  (PCI_MSK_AV_CORE   0x0800)
 cx25840 3-0044: AV Core IRQ status (entry):   
 cx25840 3-0044: AV Core ir IRQ status: 0x00 disables: 0x00
 cx25840 

I2C transaction questions: irq context and client locking

2010-01-16 Thread Andy Walls
Jean, All,

I have a few basic questions related to the cx23885 driver and
processing interrupts from a device connected over an I2C bus.

1. Under what conditions, if any, would it be safe to perform I2C reads
and writes in an irq handler context?  The cx23885 i2c implementation
doesn't appear to schedule() or try and grab a mutex, so I'm pretty sure
it doesn't sleep.

2. Is there any built in locking mechanism built in to the I2C subsystem
so a caller can get exclusive access to an I2C client on a bus? I know
there is an adapter mutex to avoid collisions at a transfer level.  I
was looking for something that could be used at the transaction or
multi-transaction level.  The cx25840 driver has gems like this in it:

u8 cx25840_read(struct i2c_client * client, u16 addr)
{
u8 buffer[2];
buffer[0] = addr  8;
buffer[1] = addr  0xff;

if (i2c_master_send(client, buffer, 2)  2)
return 0;

if (i2c_master_recv(client, buffer, 1)  1)
return 0;

return buffer[0];
}

So a read transaction is two separate transfers.  I see some problems
with this function:

a. when called from a process or workqueue context, the read transaction
can be corrupted if an interrupt handler came in and accessed the i2c
client.

b  two near simultaneous calls from a workqueue or process context can
get interleaved and corrupt the transactions

c. if this were called from an irqs_disabled() context and the bus
adapter mutex can't be obtained, the EAGAIN is thrown away. :(
(Is it even safe to do mutex_trylock() from an irq context?)


I suppose I'll just have to disable the interuupt from the device and
push everything off to a workqueue when an interrupt comes in.  Then
once the workhandler is done accessing the device, it can re-enable the
interrupt.  That still leaves me with possible collisions from multipe
process or workqueue contexts.

Do you have any thoughts?

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


[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/

2010-01-16 Thread Jean-Francois Moine
Hi Mauro,

Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb

for the following 9 changesets:

01/09: gspca - zc3xx: Change the resolutions of some sensors.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=b2c81ce31b88

02/09: gspca - pac7302/pac7311: Remove the unused page loading.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=8c4f87786f70

03/09: gspca - pac7302: Use usb_err to propagate USB errors.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=89e8a8fb18ab

04/09: gspca - pac7311: Use usb_err to propagate USB errors.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=ec69be3f2189

05/09: gspca - main: Clear any previous USB error when starting the transfer.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=0e786e0e1304

06/09: gspca - ov534_9: Propagate USB errors to higher level.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=86ddca1f84e3

07/09: gspca - ov534: Allow enumerating supported framerates.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=df30e531917f

08/09: gspca - ov534: Fix end of frame handling.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=f5ed66e36d53

09/09: gspca - sq905c: Fix a compilation warning.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=e7e9bfc2ecf0


 gspca.c   |2 
 gspca.h   |2 
 ov534.c   |   19 
 ov534_9.c |   18 ++--
 pac7302.c |  263 +++---
 pac7311.c |  212 +++--
 sq905c.c  |2 
 zc3xx.c   |   52 ++--
 8 files changed, 255 insertions(+), 315 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: Kworld 315U and SAA7113?

2010-01-16 Thread Franklin Meng
Devin, 

  I'm actually not really concerned about it's
 interaction
  with a demod.
   I'm more worried about other products that have
  saa711[345] that use
  a bridge other than em28xx.  The introduction of
 power
  management
  could always expose bugs in those bridges (I had this
  problem in
  several different cases where I had to fix problems
 in
  other drivers
  because of the introduction of power management).
  

I retested my device and tried several different GPIO sequences but so far 
every time I change between the Analog and digital interface, the SAA7113 needs 
to be reinitialized.  I tried leaving both the digital and analog interfaces 
enabled by setting the GPIO to 7c but then the LG demod does not initialize.  

Either way it looks like I will have to reinitialize the device after switching 
between interfaces.  

Other than that do you want me to remove the suspend GPIO?  Since I don't have 
the equipment to measure the power, I don't know for a fact if the device 
really has been put in a suspend state or not.  

Thanks,
Franklin Meng


  
--
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