[patch] [media] saa7164: poll mask set incorrectly

[Dan Carpenter]

list_first_entry() always returns non-null here.  I think the intent was
to test whether there were any entries in the used list.

Signed-off-by: Dan Carpenter 
---
I don't have this hardware so I can't test this.  Please check
carefully.

diff --git a/drivers/media/video/saa7164/saa7164-encoder.c 
b/drivers/media/video/saa7164/saa7164-encoder.c
index cbb53d0..f4b8ac7 100644
--- a/drivers/media/video/saa7164/saa7164-encoder.c
+++ b/drivers/media/video/saa7164/saa7164-encoder.c
@@ -1238,7 +1238,6 @@ static unsigned int fops_poll(struct file *file, 
poll_table *wait)
 {
struct saa7164_encoder_fh *fh = (struct saa7164_encoder_fh 
*)file->private_data;
struct saa7164_port *port = fh->port;
-   struct saa7164_user_buffer *ubuf;
unsigned int mask = 0;
 
port->last_poll_msecs_diff = port->last_poll_msecs;
@@ -1271,10 +1270,7 @@ static unsigned int fops_poll(struct file *file, 
poll_table *wait)
}
 
/* Pull the first buffer from the used list */
-   ubuf = list_first_entry(&port->list_buf_used.list,
-   struct saa7164_user_buffer, list);
-
-   if (ubuf)
+   if (!list_empty(&port->list_buf_used.list))
mask |= POLLIN | POLLRDNORM;
 
return mask;
diff --git a/drivers/media/video/saa7164/saa7164-vbi.c 
b/drivers/media/video/saa7164/saa7164-vbi.c
index 323c7cd..8025631 100644
--- a/drivers/media/video/saa7164/saa7164-vbi.c
+++ b/drivers/media/video/saa7164/saa7164-vbi.c
@@ -1186,7 +1186,6 @@ static unsigned int fops_poll(struct file *file, 
poll_table *wait)
 {
struct saa7164_vbi_fh *fh = (struct saa7164_vbi_fh *)file->private_data;
struct saa7164_port *port = fh->port;
-   struct saa7164_user_buffer *ubuf;
unsigned int mask = 0;
 
port->last_poll_msecs_diff = port->last_poll_msecs;
@@ -1219,10 +1218,7 @@ static unsigned int fops_poll(struct file *file, 
poll_table *wait)
}
 
/* Pull the first buffer from the used list */
-   ubuf = list_first_entry(&port->list_buf_used.list,
-   struct saa7164_user_buffer, list);
-
-   if (ubuf)
+   if (!list_empty(&port->list_buf_used.list))
mask |= POLLIN | POLLRDNORM;
 
return mask;
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Media framework backwards compatibility

[Lane Brooks]

Laurent,

Thanks for the quick feedback. See my comments below:

On 11/23/2010 04:45 PM, Laurent Pinchart wrote:

On Tuesday 23 November 2010 23:29:10 Lane Brooks wrote:Laurent,

If the links are setup to the resizer, then it seems that user space
applications should be able to talk the resizer output (/dev/video3)
like a traditional V4L2 device and need not worry about the new media
framework. It even seems possible for the resizer to allow the final
link format to be adjusted so that the user space application can
actually adjust the resizer subdev output format across the range of
valid resizer options based on the format of the resizer input pad. If
the resizer output device node worked this way, then our camera would
work with all the existing V4L2 applications with the simple caveat that
the user has to run a separate setup application first.

The resizer output device node does not currently behave this way, and I
am not sure why. These are the reasons that I can think of as to why:
1. It has not been implemented this way yet.
2. I am doing something incorrectly with the media-ctl application.
3. It not intended to work this way (by the new media framework design
principles).
4. It cannot work this way because of some reason I am not considering.

It's probably a combination of 1 and "it cannot work this way because of
reasons I can't remember at 1AM" :-)

The ISP video device nodes implementation doesn't initialize vfh->format when
the device node is opened. I think this should be fixed by querying to
connected subdevice for its current format. Of course there could be no
connected subdevice when the video device node is opened, in which case the
format can't be initialized. Pure V4L2 applications must not try to use the
video device nodes before the pipeline is initialized.
I'll look into implementing this. This is mostly what I am looking for 
and hopefully won't be too involved to implement.

Regarding adjusting the format at the output of the connected subdevice when
the video device node format is set, that might be possible to implement, but
we will run into several issues. One of them is that applications currently
can open the video device nodes, set the format and request buffers without
influencing the ISP at all. The format set on the video device node will be
checked against the format on the connected pad at streamon time. This allows
preallocating buffers for snapshot capture to lower snapshot latency. Making
set_format configure the connected subdev directly would break this
How does calling set_format on the subdev pad at the same as the device 
node prevent preallocating buffers? I don't really understand the ISP 
buffering, so I think at this point I will look into implementing the 
previous option and then perhaps I will have a better understanding of 
the issue you raise here. I think it is only the resizer that would need 
this capability. I am bringing it up as a nice to have, but we can 
certainly live without it if it does not fit into the design goals of 
the framework.


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

Re: Media framework backwards compatibility

[Laurent Pinchart]

Hi Lane,

On Tuesday 23 November 2010 23:29:10 Lane Brooks wrote:
> Laurent,
> 
> Things in general are working with our camera implementation using the
> OMAP ISP module. There is, however, a lingering issue that I now need to
> work out regarding the fact that most user space applications do not
> work with our camera because of the new media framework.
> 
> Currently, the only way we have to use our camera is through a custom
> user space application we wrote (that makes heavy use of the media-ctl
> user space application for setting up the media links). What I am hoping
> for, though, is the ability to setup the media links from the media-ctl
> application and then have a typical V4L2 user space application use the
> OMAP ISP resizer output device node as usual.
> 
> Here is what I would like to do:
> 
> 1. Setup the links to the resizer using a command line app (like
> media-ctl).
> 2. Point a typical V4L2 application (like gstreamer or ffmpeg)
> to read from the resizer output device node and have it negotiate the
> format using traditional V4L2 ioctls (VIDIOC_G_FMT/VIDIOC_S_FMT).
> 
> If the links are setup to the resizer, then it seems that user space
> applications should be able to talk the resizer output (/dev/video3)
> like a traditional V4L2 device and need not worry about the new media
> framework. It even seems possible for the resizer to allow the final
> link format to be adjusted so that the user space application can
> actually adjust the resizer subdev output format across the range of
> valid resizer options based on the format of the resizer input pad. If
> the resizer output device node worked this way, then our camera would
> work with all the existing V4L2 applications with the simple caveat that
> the user has to run a separate setup application first.
> 
> The resizer output device node does not currently behave this way, and I
> am not sure why. These are the reasons that I can think of as to why:
> 1. It has not been implemented this way yet.
> 2. I am doing something incorrectly with the media-ctl application.
> 3. It not intended to work this way (by the new media framework design
> principles).
> 4. It cannot work this way because of some reason I am not considering.
> 
> I haven't looked at the resizer code yet, but if the answer is 1, then I
> will take a look at implementing it as I described. Otherwise, let me know.

It's probably a combination of 1 and "it cannot work this way because of 
reasons I can't remember at 1AM" :-)

The ISP video device nodes implementation doesn't initialize vfh->format when 
the device node is opened. I think this should be fixed by querying to 
connected subdevice for its current format. Of course there could be no 
connected subdevice when the video device node is opened, in which case the 
format can't be initialized. Pure V4L2 applications must not try to use the 
video device nodes before the pipeline is initialized.

Regarding adjusting the format at the output of the connected subdevice when 
the video device node format is set, that might be possible to implement, but 
we will run into several issues. One of them is that applications currently 
can open the video device nodes, set the format and request buffers without 
influencing the ISP at all. The format set on the video device node will be 
checked against the format on the connected pad at streamon time. This allows 
preallocating buffers for snapshot capture to lower snapshot latency. Making 
set_format configure the connected subdev directly would break this.

-- 
Regards,

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

Re: issues with af9015

[Damjan Marion]

On Nov 12, 2010, at 9:32 PM, Damjan Marion wrote:
> 
> Hi,
> 
> I have same issue with two different af9015 cards made by 2 different 
> manufacturers with 2 different frontends.
> 
> When card is used with tvheadend software which constantly does idle 
> scanning, after 1-2 days it starts showing following dmesgs:
> 
> [342924.332308] tda18218: i2c wr failed ret:-1 reg:1a len:3
> [342925.152277] af9015: command failed:1
> [342925.152293] tda18218: i2c wr failed ret:-1 reg:1a len:3
> [342925.973596] af9015: command failed:1
> [342925.973610] tda18218: i2c wr failed ret:-1 reg:1a len:3
> 
> Only way to recover it from this state is unplugging. Rebooting doesn't help 
> as card stays powered during reboot.
> 
> Any idea what can cause this? Can I do any further debugging steps?
> 
> Thanks,
> 
> damjan
> 

2nd try
--
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

Media framework backwards compatibility

[Lane Brooks]

Laurent,

Things in general are working with our camera implementation using the 
OMAP ISP module. There is, however, a lingering issue that I now need to 
work out regarding the fact that most user space applications do not 
work with our camera because of the new media framework.


Currently, the only way we have to use our camera is through a custom 
user space application we wrote (that makes heavy use of the media-ctl 
user space application for setting up the media links). What I am hoping 
for, though, is the ability to setup the media links from the media-ctl 
application and then have a typical V4L2 user space application use the 
OMAP ISP resizer output device node as usual.


Here is what I would like to do:

1. Setup the links to the resizer using a command line app (like media-ctl).
2. Point a typical V4L2 application (like gstreamer or ffmpeg) to read 
from the resizer output device node and have it negotiate the format 
using traditional V4L2 ioctls (VIDIOC_G_FMT/VIDIOC_S_FMT).


If the links are setup to the resizer, then it seems that user space 
applications should be able to talk the resizer output (/dev/video3) 
like a traditional V4L2 device and need not worry about the new media 
framework. It even seems possible for the resizer to allow the final 
link format to be adjusted so that the user space application can 
actually adjust the resizer subdev output format across the range of 
valid resizer options based on the format of the resizer input pad. If 
the resizer output device node worked this way, then our camera would 
work with all the existing V4L2 applications with the simple caveat that 
the user has to run a separate setup application first.


The resizer output device node does not currently behave this way, and I 
am not sure why. These are the reasons that I can think of as to why:

1. It has not been implemented this way yet.
2. I am doing something incorrectly with the media-ctl application.
3. It not intended to work this way (by the new media framework design 
principles).

4. It cannot work this way because of some reason I am not considering.

I haven't looked at the resizer code yet, but if the answer is 1, then I 
will take a look at implementing it as I described. Otherwise, let me know.


Thanks,
Lane

--
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: Thoughts about suspending DVB C PCI device transparently

[Marko Ristola]

Hi.

Thank you for noticing my old email.

My observation of working suspend/resume implementation was,
that the needed amount of code for suspend and resume functions
was very small and easy. I reorganized mantis_pci.c so that both
module initialization and suspend/resume could use the same
functions for DVB device initialization.

Mantis structure needed maintenance of status before suspend
so that the status could be restored afterwards:
- power state (had feature to turn tuner off when idle).
- get_frontend(fe, param) content.
- number of feeds before suspend.

Each sub-device (C-file) needed it's own "suspend()" and "resume()" function
and these functions had to be called in the right order, starting
from mantis_pci.c's functions, some maintained IRQ states. After powering
and initializing all hardware, frontend was tuned back to state before suspend,
FE lock waited and DMA transfer turned back on.

Other kernel parts (the framework) took care that
no user space program will interfere during the resume process.

Media/dvb-core didn't need any changes for this to work.

Regards,
Marko Ristola

20.11.2010 14:57, Richard Zidlicky wrote:

Hi,

found this old email when searching for suspend issues, seems like a good idea.
Just wondering - how many eg dvb drivers are there with working 
suspend/hibernate
(all buses, not just PCI)? Me thinks only a small fraction, the rest will crash
unless blacklisted by pm-utils?

I don't know any that works, but maybe there are a few of them.


Would it be worth to code a generic approach working around drivers that need 
to be
blacklisted? It seems that because of eg firmware loading this might be the 
only way
to get dvb drivers behave?

Sharing the approach would work, but code sharing might not be worth it.
Maybe putting some knowledge into small functions to ease up bus initialization
would help: driver developer would need as few knowledge from the bus as 
possible.
A document and a reference implementation would help others to add 
suspend/resume
into their simple drivers. Maybe users and developers want nicer suspend/resume
implementation now compared to the old times. Is the demand high enough now?


Richard


Once in a time I wrote into Mantis driver Suspend / resume
code. The idea was, that bridge driver (mantis_dvb.c) will
handle the suspend / resume transparently to the application.

With a PCI device this was rather easy to achieve.
With xine, there was just a glitch with video and audio
after resume.

So after suspend, frontend was tuned into the original
frequency, and the DMA transfer state was restored.

Suspend:
1. Turn off possible DMA transfer if active (feeds>  0)
2. Remember tuner power on state.
3. Do tuner and fronted power off.

Resume:
1. Restore frontend and tuner power.
2. (feeds>  0)? Set frequency for the tuner.
3. (feeds>  0)? Restore DMA transfer into previous state.

What do you think about this?
I need some feedback: is it worth coding?
Other needed code is usual suspend / resume stuff.

Is it worth powering off the tuner, if it isn't
used?

For my current usage, powering off the unused tuner
gives more power savings than implementing suspend/resume.

Marko Ristola

--

// suspend to standby, ram or disk.
int mantis_dvb_suspend(struct mantis_pci *mantis, pm_message_t
 prevState, pm_message_t mesg)
{
 if (mantis->feeds>  0)
mantis_dma_stop(mantis);

 if (mantis->has_power)
 mantis_fe_powerdown(mantis); // power off tuner.

 return 0;
}

void mantis_dvb_resume(struct mantis_pci *mantis, pm_message_t prevMesg)
{
// power on frontend and tuner.
mantis_frontend_tuner_init(mantis);

if (mantis->feeds>  0&&  mantis->fe->ops.tuner_ops.init)
 (mantis->fe->ops.init)(mantis->fe);

 if (mantis->feeds>  0) {
 (mantis->fe->ops.set_frontend)(mantis->fe, NULL);
mantis_dma_start(mantis);
 }
}

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

[PATCH] media: fix casting issues in timberdale logiwin

[Jarod Wilson]

I get warnings about casting to and from pointers and integers of
different sizes w/current code, this silences them.

Signed-off-by: Jarod Wilson 
---
 drivers/media/video/timblogiw.c |6 --
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/video/timblogiw.c b/drivers/media/video/timblogiw.c
index 48989e5..4da3625 100644
--- a/drivers/media/video/timblogiw.c
+++ b/drivers/media/video/timblogiw.c
@@ -148,7 +148,9 @@ static void timblogiw_dma_cb(void *data)
 
 static bool timblogiw_dma_filter_fn(struct dma_chan *chan, void *filter_param)
 {
-   return chan->chan_id == (int)filter_param;
+   int chan_id = *(int *)filter_param;
+
+   return chan->chan_id == chan_id;
 }
 
 /* IOCTL functions */
@@ -670,7 +672,7 @@ static int timblogiw_open(struct file *file)
 
/* find the DMA channel */
fh->chan = dma_request_channel(mask, timblogiw_dma_filter_fn,
-   (void *)lw->pdata.dma_channel);
+   (void *)(unsigned long)lw->pdata.dma_channel);
if (!fh->chan) {
dev_err(&vdev->dev, "Failed to get DMA channel\n");
kfree(fh);
-- 
1.7.1


-- 
Jarod Wilson
ja...@redhat.com

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

Re: [linux-dvb] [bug] AF9015 message "WARNING: >>> tuning failed!!!"

[Paul Gover]

On Wednesday 06 October 2010 22:29:35 Antti Palosaari wrote:
> On 10/06/2010 11:36 PM, dave cunningham wrote:
> > In message <4cacd0f3.6030...@iki.fi>, Antti Palosaari wrote
> > 
> >> It is QT1010 tuner driver issue. None is working for that currently or
> >> in near future. Feel free to fix :]
> > 
> > The wiki appears to show this stick as working.
> > .
> > 
> > Is this information incorrect or is it hit and miss depending on the
> > host system?
> 
> It "works" but performance is poor. Usually it locks when RF signal is
> weak. If you fix bug around line 381 in qt1010.c it will work much
> better. But if you fix that it will break devices zl10353+qt1010 since
> zl10353 driver misses AGC configuration.
> 
> Antti

Antti,

I took a look at qt1010.c, but didn't see what the bug was.  I was hoping to 
see a FIXME or BUG or some comment; any comment ;-)

But then I went back to my traces.  They said my AF9015 detected an MT2060 
tuner, not a QT1010.  Does this mean the QT1010 comment was wrong?  The 
detection code that said so looks to be part of the AF9015/9013 support, maybe 
they use the same code.  Whatever, you will know, and I certainly don't.  The 
tuner code certainly uses the QT1010 driver and not the MT2060 driver, if I 
understood the traces correctly.  

FWIW, I think you are right about AGC; when Kaffeine scans for channels, it 
gives a few fleeting signal levels about 50% but fails to identify anything.  
My previous DVB-T stick, different older chip, produced 100% signal solidly, 
and Kaffeine identified more than 80 channels.

I think this bug renders the AF9015 in this configuration virtually useless in 
Linux; the signal is enough for the Windoze tuner bloatware supplied with it 
to find all the channels, but not a thing in Linux.

Sorry for coming back on this so much later; I've been busy doing house 
repair.  Also, I stopped following the mailing list - I was getting swamped 
with stuff and it seems to make yahoo break KDE PIM.  If I should post this via 
the list, please say, and I'll start obeying the rules!

Thanks in advance for any guidance.
--
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-T2 tuner dismantled: PCTV Nanostick T2 290e

[Steve Kerrison]

Quick correction: The tuner is TDA18271HDC2 not TDA18271HDA2; it's dark
and I'm tired.

Photos are now available at http://www.stevekerrison.com/290e/pics.html

The most interesting are the two PCB shots.

Tuner: http://www.stevekerrison.com/290e/img/tuner.jpg 
Controller/Demod: http://www.stevekerrison.com/290e/img/hastalavista.jpg

I'll put this information into the wiki when I have a chance, and when I
can take some better photos in daylight.

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 



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

[cron job] v4l-dvb daily build: WARNINGS

[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:Tue Nov 23 19:00:22 CET 2010
git master:   59365d136d205cc20fe666ca7f89b1c5001b0d5a
git media-master: gcc version:  i686-linux-gcc (GCC) 4.5.1
host hardware:x86_64
host os:  2.6.32.5

linux-git-armv5: WARNINGS
linux-git-armv5-davinci: WARNINGS
linux-git-armv5-ixp: WARNINGS
linux-git-armv5-omap2: WARNINGS
linux-git-i686: WARNINGS
linux-git-m32r: WARNINGS
linux-git-mips: WARNINGS
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
spec-git: OK
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.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

DVB-T2 tuner dismantled: PCTV Nanostick T2 290e

[Steve Kerrison]

Hello everyone,

One of these arrived at my door today, the world's first USB DVB-T2
tuner. So PCs can finally receive Freeview HD here in the UK... but only
on Windows.

My experience with Linux kernel development is more or less zilch - more
of a spectator sport for me, although I've been subscribed to
linux-media for a couple of months now. I will help how I can, but I
expect that by myself, this would take an awful long time and never make
it into the kernel. So everyone's help is appreciated.

Pics to follow once my camera battery is recharged, but here is
preliminary info:

dmesg
-

[27892.030018] usb 2-2: new high speed USB device using ehci_hcd and
address 54

lsusb
-

Bus 002 Device 054: ID 2013:024f Unknown (Pinnacle?) 
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  idVendor   0x2013 Unknown (Pinnacle?)
  idProduct  0x024f 
  bcdDevice1.00
  iManufacturer   1 PCTV Systems
  iProduct2 PCTV 290e
  iSerial 3 0006LL9R
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength   55
bNumInterfaces  1
bConfigurationValue 1
iConfiguration  0 
bmAttributes 0x80
  (Bus Powered)
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes1
  Transfer TypeIsochronous
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x  1x 0 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85  EP 5 IN
bmAttributes1
  Transfer TypeIsochronous
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x  1x 0 bytes
bInterval   1
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   1
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass  0 
  bInterfaceProtocol  0 
  iInterface  0 
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes1
  Transfer TypeIsochronous
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x03ac  1x 940 bytes
bInterval   1
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85  EP 5 IN
bmAttributes1
  Transfer TypeIsochronous
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x03ac  1x 940 bytes
bInterval   1
Device Qualifier (for other device speed):
  bLength10
  bDescriptorType 6
  bcdUSB   2.00
  bDeviceClass0 (Defined at Interface level)
  bDeviceSubClass 0 
  bDeviceProtocol 0 
  bMaxPacketSize064
  bNumConfigurations  1
Device Status: 0x
  (Bus Powered)

PCB
---

It's a very small (smaller than most USB-stick tuners) device,
implemented on two PCBs sandwiched together.

Tuner: NXP TDA18271HDA2
USB IC: Empia em28174 (is this part of the 2874 family, the 2871, or
something else?
http://www.linuxtv.org/wiki/index.php/Em28xx_devices#em2874 )
Demod: Sony CXD2820R

The demod is no surprise given it's about the only T2 compatible demod
out there (LSI might have one too, if memory serves).

So, what's next? Any PCTV Linux driver contributors active here? I will
next attempt to find a datasheet for the Sony demod, then grab some
usbsnoop data, although the only Windows machine I have that can get
near a fixed antenna is Atom powered... so it ain't great.

Questions, requests, demands and insults are all welcomed.

Regards,
-- 
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/ 


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the bod

Re: linux-next: Tree for November 23

[Anca Emanuel]

Stephen, It is possible to have an automatic test report for
(in)successful boot on major 5 distributions ?
--
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 November 23

[Anca Emanuel]

I get an panic from this version on my PC. Last time I checked was
something like 10 days ago (running "next" fine).
Kernel 2.6.37-rc3 running ok here, Intel Core Duo, Ubuntu 10.10.
--
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 FOR 2.6.37] Revert "V4L/DVB: v4l2-dev: remove unnecessary lock around atomic clear_bit"

[Laurent Pinchart]

Hi Hans,

On Tuesday 23 November 2010 10:47:10 Hans Verkuil wrote:
> On Tuesday, November 23, 2010 01:21:45 Laurent Pinchart wrote:
> > On Tuesday 23 November 2010 01:14:28 Hans Verkuil wrote:
> > > On Monday, November 22, 2010 12:20:25 Hans Verkuil wrote:
> > > > On Monday, November 22, 2010 11:21:27 Laurent Pinchart wrote:
> > > > > Removing the mutex_lock/unlock around clear_bit allowed
> > > > > device_unregister() to race with v4l2_open(). The device can be
> > > > > unregistered  between the video_devdata() and video_get() calls.
> > > > > 
> > > > > Revert the patch to fix the problem.
> > > > > 
> > > > > This reverts commit dd0daf2a6fb6bec436a3ef68bd585ea09a2a54b7.
> > > > > 
> > > > > Signed-off-by: Laurent Pinchart 
> > > > 
> > > > Acked-by: Hans Verkuil 
> > > 
> > > Change of mind, I nack this.
> > > 
> > > I realized that the mutex should be around device_unregister, not
> > > around the clear_bit. The mutex protects access to vdev->dev and not
> > > vdev->flags since that's atomic anyway.
> > 
> > device_unregister() will end up calling v4l2_device_release(), which also
> > locks videodev_lock. That will result in a deadlock.
> 
> True. (Note to myself: don't post past midnight...)
> 
> But a mutex around clear_bit doesn't help either. Unless v4l2_open will
> test for this bit just before the video_get(). E.g. by replacing 'if (vdev
> == NULL)' with 'if (vdev == NULL || !video_is_registered(vdev))'.
> 
> I think that will do the trick.

Sounds good to me. Do you want to submit a patch ? :-)

-- 
Regards,

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

Re: linux-next: Tree for November 23

[Zimny Lech]

Slawa,

2010/11/23 Stephen Rothwell :
> Hi all,
>
> Changes since 20101122:

WARNING: modpost: Found 14 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
  GEN .version
  CHK include/generated/compile.h
  UPD include/generated/compile.h
  CC  init/version.o
  LD  init/built-in.o
  LD  .tmp_vmlinux1
drivers/built-in.o: In function `timblogiw_close':
/home/test/linux-2.6/drivers/media/video/timblogiw.c:704: undefined
reference to `dma_release_channel'
drivers/built-in.o: In function `buffer_release':
/home/test/linux-2.6/drivers/media/video/timblogiw.c:595: undefined
reference to `dma_sync_wait'
drivers/built-in.o: In function `timblogiw_open':
/home/test/linux-2.6/drivers/media/video/timblogiw.c:671: undefined
reference to `__dma_request_channel'
make[1]: *** [.tmp_vmlinux1] Error 1
make: *** [sub-make] Error 2



-- 
Slawa!
N.P.S.

Chwała tobie, Szatanie, cześć na wysokościach
Nieba, gdzie królowałeś, chwała w głębokościach
Piekła, gdzie zwyciężony, trwasz w dumnym milczeniu!
Uczyń, niechaj ma dusza spocznie z Tobą w cieniu
Drzewa Wiedzy, gdy swoje konary rozwinie,
Jak sklepienie kościoła, który nie przeminie!
--
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

ir-kbd-i2c.c: Multiple events from single keypress

[Pavel Hofman]

Hi,

The remote Control coming with Hauppauge HVR1110 (module ir-kbd-i2c, the
gray model hauppauge=1) produces multiple events from single even short
key presses on archlinux, kernel 2.6.35.

The variable old in struct IR_i2c:

/* Used to avoid fast repeating */
unsigned char  old;

does not seem to be used anywhere in the code.

Please is there a way to solve this problem in the driver, or is it
necessary to handle the superfluous multiple events in lircd? The former
 would let us use the simple inputlircd :-)

If it is possible/feasible, please let me know what debuging information
to provide.

Thanks a lot in advance,

Pavel Hofman.





--
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 FOR 2.6.37] Revert "V4L/DVB: v4l2-dev: remove unnecessary lock around atomic clear_bit"

[Hans Verkuil]

On Tuesday, November 23, 2010 01:21:45 Laurent Pinchart wrote:
> Hi Hans,
> 
> On Tuesday 23 November 2010 01:14:28 Hans Verkuil wrote:
> > On Monday, November 22, 2010 12:20:25 Hans Verkuil wrote:
> > > On Monday, November 22, 2010 11:21:27 Laurent Pinchart wrote:
> > > > Removing the mutex_lock/unlock around clear_bit allowed
> > > > device_unregister() to race with v4l2_open(). The device can be
> > > > unregistered  between the video_devdata() and video_get() calls.
> > > > 
> > > > Revert the patch to fix the problem.
> > > > 
> > > > This reverts commit dd0daf2a6fb6bec436a3ef68bd585ea09a2a54b7.
> > > > 
> > > > Signed-off-by: Laurent Pinchart 
> > > 
> > > Acked-by: Hans Verkuil 
> > 
> > Change of mind, I nack this.
> > 
> > I realized that the mutex should be around device_unregister, not around
> > the clear_bit. The mutex protects access to vdev->dev and not vdev->flags
> > since that's atomic anyway.
> 
> device_unregister() will end up calling v4l2_device_release(), which also 
> locks videodev_lock. That will result in a deadlock.

True. (Note to myself: don't post past midnight...)

But a mutex around clear_bit doesn't help either. Unless v4l2_open will test
for this bit just before the video_get(). E.g. by replacing 'if (vdev == NULL)'
with 'if (vdev == NULL || !video_is_registered(vdev))'.

I think that will do the trick.

Regards,

Hans

-- 
Hans Verkuil - video4linux developer - sponsored by Cisco
--
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: [omap3isp RFC][RESEND PATCH v2 0/4] Improve inter subdev interaction

[David Cohen]

Hi Sergio,

On Mon, Nov 22, 2010 at 08:53:53PM +0100, ext Sergio Aguirre wrote:
> (Resending...)
> 
> Hi,
> 
> These are some patches to make these operations more generic:
> - Clock control is being controlled in a very crude manner by
>   subdevices, it should be centralized in isp.c.
> - LSC prefetch wait check is reading a main ISP register, so move
>   it to isp.c
> - Abstract SBL busy check: we don't want a submodule thinkering
>   with main ISP registers. That should be done in the main isp.c
> 
> Also, remove main ISP register dump from CSI2 specific dump. We
> should be using isp_print_status if we'll like to know main ISP
> regdump.
> 
> Comments are welcome. More cleanups for better subdevice isolation
> are on the way.
> 
> Regards,
> Sergio
> 
> Changelog:
> v2:
> - Improved logic in isp subdevs clock control (Thanks David Cohen)
> - Renamed ispccdc_lsc_wait_prefetch -> isp_ccdc_* to be clear on
>   function declaration new location (isp.c) (Thanks David and Laurent)

This version looks good for me.

Regards,

David Cohen

> 
> v1:
> - Initial version
> 
> Sergio Aguirre (4):
>   omap3isp: Abstract isp subdevs clock control
>   omap3isp: Move CCDC LSC prefetch wait to main isp code
>   omap3isp: sbl: Abstract SBL busy check
>   omap3isp: csi2: Don't dump ISP main registers
> 
>  drivers/media/video/isp/isp.c|   87 
> ++
>  drivers/media/video/isp/isp.h|   16 ++
>  drivers/media/video/isp/ispccdc.c|   42 ++---
>  drivers/media/video/isp/ispcsi2.c|7 ---
>  drivers/media/video/isp/isppreview.c |6 +--
>  drivers/media/video/isp/ispresizer.c |6 +--
>  6 files changed, 111 insertions(+), 53 deletions(-)
--
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