Hi Daniel,
Sorry for the delayed reply. I actually did reply five days ago but
the message got dropped by the ML filter because my phone apparently
formatted it into HTML content. Resending here...
Do you have a contact at Trident I can ask to get access to that
data sheet? I have been
This patch series fixes up some issues with the tm6000 driver. These
patches were tested with a Cinergy Hybrid XE which is the only one I
have access to, so it would be nice if someone with access to the other
supported devices could take this series for a test run.
Among the changes are several
In radio mode, no frequency offset is needed. While at it, split off the
frequency offset computation for digital TV into a separate function.
---
drivers/media/common/tuners/tuner-xc2028.c | 137 +++-
1 files changed, 75 insertions(+), 62 deletions(-)
diff --git
In radio mode, the correct input is rinput. The pseudo index 5 is used
but cannot be used to index the vinput array because that only has 3
elements.
---
drivers/staging/tm6000/tm6000-stds.c | 28 +++-
1 files changed, 15 insertions(+), 13 deletions(-)
diff --git
This commit fixes a number of coding style issues as well as some issues
reported by checkpatch and sparse.
---
drivers/staging/tm6000/tm6000-alsa.c |4 +-
drivers/staging/tm6000/tm6000-cards.c | 18 ++---
drivers/staging/tm6000/tm6000-core.c | 17 ++---
---
drivers/staging/tm6000/tm6000-core.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index e14bd3d..2c156dd 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++
When loading the firmware, complete each chunk by sending an I2C flush
command to the frontend. Some devices like the tm6000 seem to require
this to properly flush the I2C buffers.
The current code in tm6000 executes the flush command once after each
I2C transfer, which slows down the firmware
This brings the IRQ callback implementation more in line with how other
drivers do it.
---
drivers/staging/tm6000/tm6000-video.c | 14 +-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-video.c
b/drivers/staging/tm6000/tm6000-video.c
---
drivers/staging/tm6000/tm6000-cards.c |5 +
drivers/staging/tm6000/tm6000-i2c.c |5 -
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 202f454..c3b84c9 100644
---
The TM6010 supports much larger I2C transfers than currently specified.
In fact the Windows driver seems to use 81 bytes per packet by default.
This commit improves the speed of firmware loading a bit.
---
drivers/staging/tm6000/tm6000-cards.c |1 +
drivers/staging/tm6000/tm6000-i2c.c |
The register ACTIVE_VIDEO_IF register should be named ACTIVE_IF since it
controls more than just the video interface.
---
drivers/staging/tm6000/tm6000-alsa.c |4 ++--
drivers/staging/tm6000/tm6000-core.c | 12 ++--
drivers/staging/tm6000/tm6000-regs.h |4 +++-
3 files changed,
Video data is useless in radio mode, so the corresponding interface can
be safely disabled. This should reduce the amount of isochronous traffic
noticeably.
---
drivers/staging/tm6000/tm6000-core.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git
This commit introduces the usb_lock mutex to ensure that a USB request
always gets the proper response. While this is currently not really
necessary it will become important as there are more users.
---
drivers/staging/tm6000/tm6000-cards.c |1 +
drivers/staging/tm6000/tm6000-core.c |3
This commit uses sentinel entries to terminate the TV standard register
tables instead of hard-coding their size, allowing further entries to be
added more easily. It is also more space-efficient if the tables have a
varying number of entries.
---
drivers/staging/tm6000/tm6000-stds.c | 610
When the USB device is disconnected, the device usage bit is not cleared
properly. This leads to errors when a device is unplugged and replugged
several times until all TM6000_MAXBOARDS bits are used and keeps the
driver from binding to the device.
---
drivers/staging/tm6000/tm6000-cards.c |5
Instead of selecting the default interface setting when preparing
isochronous transfers, select it on the first call to open() to make
sure it is available earlier.
---
drivers/staging/tm6000/tm6000-video.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git
When the last user closes the device, perform a lightweight reset of the
device to bring it into a well-known state.
Note that this is not always enough with the TM6010, which sometimes
needs a hard reset to get into a working state again.
---
drivers/staging/tm6000/tm6000-core.c | 43
This fixes a memory leak where isochronous buffers would be set up for
each video buffer, while it is sufficient to set them up only once per
device.
---
drivers/staging/tm6000/tm6000-video.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git
---
drivers/staging/tm6000/tm6000-stds.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-stds.c
b/drivers/staging/tm6000/tm6000-stds.c
index f44451b..9a4145d 100644
--- a/drivers/staging/tm6000/tm6000-stds.c
+++
When releasing hardware resources, the DMA buffer allocated to the PCM
device needs to be freed to prevent a memory leak.
---
drivers/staging/tm6000/tm6000-alsa.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-alsa.c
If the radio device is opened there is no need to initialize the video
buffer queue because it is not used.
---
drivers/staging/tm6000/tm6000-video.c | 18 ++
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-video.c
---
drivers/staging/tm6000/tm6000-cards.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 94fd138..ab3aa2c 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++
Implicitly setting the tuner frequency each time the device is opened
seems no longer necessary, so it is removed. This speeds up opening the
device by about 120 ms.
It also avoids excessive firmware reloads because the default will load
the BASE and F8MHZ type firmwares independent of which
On Wed, Aug 3, 2011 at 17:12, Jordan Crouse jcro...@codeaurora.org wrote:
On 08/03/2011 03:33 AM, Tom Cooksey wrote:
Passing buffer meta-data around was also discussed yesterday. Again, the
general consensus seemed to be that this data should be kept out of the
kernel. The userspace
Hi,
On Wed, 3 Aug 2011 09:39:46 +0200 (CEST)
Patrick Boettcher pboettc...@kernellabs.com wrote:
Hi Florian,
I'm not sure whether I still have exactly this box. There were two
versions and I got rid of at least one of them.
I moved recently into a new house and right now a lot of
From: Julia Lawall ju...@diku.dk
Delete nontrivial initialization that is immediately overwritten by the
result of an allocation function.
The semantic match that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@
type T;
identifier i;
expression e;
@@
(
T i =
On Thu, Aug 04, 2011 at 12:21:29PM +0200, Florian Mickler wrote:
Mauro, what to do?
Apply the fix which Tino tested, perhaps? :P (obviously).
The bug is present in 3.0 so it should be tagged for stable as well.
regards,
dan carpenter
--
To unsubscribe from this list: send the line
On Thu, Aug 4, 2011 at 3:58 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Wed, Aug 3, 2011 at 17:12, Jordan Crouse jcro...@codeaurora.org wrote:
On 08/03/2011 03:33 AM, Tom Cooksey wrote:
Passing buffer meta-data around was also discussed yesterday. Again, the
general consensus seemed to
Hi,
On 08/03/2011 10:36 PM, Mauro Carvalho Chehab wrote:
Em 03-08-2011 16:53, Theodore Kilgore escreveu:
snip snip
Mauro,
Not saying that you need to change the program for this session to deal
with this topic, but an old and vexing problem is dual-mode devices. It is
an issue which needs
On Thu, Aug 4, 2011 at 13:14, Clark, Rob r...@ti.com wrote:
hmm, there would be a dmabuf-private ptr in struct dmabuf. Normally
that should be for private data of the buffer allocator, but I guess
it could be (ab)used for under the hood communication between drivers
a platform specific way.
Em 03-08-2011 20:20, Theodore Kilgore escreveu:
On Wed, 3 Aug 2011, Mauro Carvalho Chehab wrote:
Em 03-08-2011 16:53, Theodore Kilgore escreveu:
On Wed, 3 Aug 2011, Mauro Carvalho Chehab wrote:
As already announced, we're continuing the planning for this year's
media subsystem
Em 04-08-2011 08:39, Hans de Goede escreveu:
Hi,
On 08/03/2011 10:36 PM, Mauro Carvalho Chehab wrote:
Em 03-08-2011 16:53, Theodore Kilgore escreveu:
snip snip
Mauro,
Not saying that you need to change the program for this session to deal
with this topic, but an old and vexing
On 03/08/11 16:33, Patrick Boettcher wrote:
Hi Mauro,
Would you please pull from
git://linuxtv.org/pb/media_tree.git for_v3.0
for the following to changesets:
[media] dib0700: protect the dib0700 buffer access
[media] DiBcom: protect the I2C bufer access
These patches seem to fix
On Mon, 11 Jul 2011 12:23:28 +0100
David Waring david.war...@rd.bbc.co.uk wrote:
I'm currently using 3 of these USB sticks on a PC with the videolan.org
dvblast program to multicast the UK Freeview DVB-T muxes on our local
network. I'm also using a PCTV nanostick 290e to multicast the DVB-T2
Dear Uwe,
could you please give me some advice once more? It seems I'm not able to
make mx2_camera working by myself.
I have tried dma memory allocation in my board file in several ways, but
nothing seems to work. I use Video capture example for v4l2 for testing.
regards
Jan
Hello Jan,
On Thu, Aug 04, 2011 at 03:11:11PM +0200, Jan Pohanka wrote:
Dear Uwe,
could you please give me some advice once more? It seems I'm not
able to make mx2_camera working by myself.
I have tried dma memory allocation in my board file in several ways,
but nothing seems to work. I use
To the best of my knowledge, you did. I cc'd Patrick and Olivier who are
involved
with dib ...
On Sun, 10 Jul 2011 09:22:05 +0200
cedric.dew...@telfort.nl wrote:
-- Oorspronkelijk bericht --
Date: Fri, 24 Jun 2011 11:01:37 +0200
From: cedric.dew...@telfort.nl
To:
- Make sure the initial frontend event on FE_SET_FRONTEND gets
enqueued before the frontend thread wakes up.
Signed-off-by: Andreas Oberritter o...@linuxtv.org
---
drivers/media/dvb/dvb-core/dvb_frontend.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
- FE_SET_FRONTEND triggers a frontend event, which uses stale data.
Modify it to use the data given by the user.
- Fixes a regression caused by a5959dbea37973a2440eeba39fba32c79d862ec2.
Signed-off-by: Andreas Oberritter o...@linuxtv.org
---
drivers/media/dvb/dvb-core/dvb_frontend.c |7
- Old events aren't very useful, so clear them before adding
the first event after an attempt to tune.
Signed-off-by: Andreas Oberritter o...@linuxtv.org
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git
- dvb_frontend_add_event:
- fepriv-parameters_out isn't protected by events-mtx, so
move the call to fe-ops.get_frontend out of the locked area.
- move the assignment of e-status into the locked area.
- dvb_frontend_get_event:
- use direct assignment instead of memcpy.
-
Add buffer length to sanity checks for QBUF.
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
---
drivers/media/video/omap3isp/ispqueue.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispqueue.c
On Thu, Aug 4, 2011 at 7:34 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Thu, Aug 4, 2011 at 13:14, Clark, Rob r...@ti.com wrote:
hmm, there would be a dmabuf-private ptr in struct dmabuf. Normally
that should be for private data of the buffer allocator, but I guess
it could be (ab)used
On Thu, 04 Aug 2011 09:40:18 -0300
Mauro Carvalho Chehab mche...@redhat.com wrote:
What we need for this is a simple API (new v4l ioctl's I guess) for the
stillcam mode of these dual mode cameras (stillcam + webcam). So that the
webcam drivers can grow code to also allow access to the
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:Thu Aug 4 19:00:33 CEST 2011
git hash:46540f7ac646ada7f22912ea7ea9b761ff5c4718
gcc version: i686-linux-gcc (GCC)
(re-adding all from the original CC-list, please, don't drop anyone)
On Thu, 4 Aug 2011, Jean-Francois Moine wrote:
On Thu, 04 Aug 2011 09:40:18 -0300
Mauro Carvalho Chehab mche...@redhat.com wrote:
What we need for this is a simple API (new v4l ioctl's I guess) for the
stillcam mode
Em 04-08-2011 15:37, Theodore Kilgore escreveu:
Yes, that kind of thing is an obvious problem. Actually, though, it may be
that this had just better not happen. For some of the hardware that I know
of, it could be a real problem no matter what approach would be taken. For
example, certain
On Thursday 04 August 2011, Theodore Kilgore wrote:
As far as I know, /dev/sdx signifies a device which is accessible by
something like the USB mass storage protocols, at the very least. So, if
that fits the camera, fine. But most of the cameras in question are Class
Proprietary. Thus, not
On Thu, 4 Aug 2011, Mauro Carvalho Chehab wrote:
Em 04-08-2011 15:37, Theodore Kilgore escreveu:
Yes, that kind of thing is an obvious problem. Actually, though, it may
be
that this had just better not happen. For some of the hardware that I
know
of, it could be a real problem no
On Thursday 04 August 2011, Mauro Carvalho Chehab wrote:
That'd also be my understanding. There are already several standard ways
to access data on still cameras: mass-storage, PTP, MTP, why invent Yet
Another One? Just learn to share a device between several existing
drivers.
For
Em 04-08-2011 18:38, Adam Baker escreveu:
On Thursday 04 August 2011, Mauro Carvalho Chehab wrote:
That'd also be my understanding. There are already several standard ways
to access data on still cameras: mass-storage, PTP, MTP, why invent Yet
Another One? Just learn to share a device
On Thu, 4 Aug 2011, Adam Baker wrote:
On Thursday 04 August 2011, Theodore Kilgore wrote:
As far as I know, /dev/sdx signifies a device which is accessible by
something like the USB mass storage protocols, at the very least. So, if
that fits the camera, fine. But most of the cameras in
Em 04-08-2011 18:16, Theodore Kilgore escreveu:
This sounds to be a good theme for the Workshop, or even to KS/2011.
Thanks. Do you recall when and where is KS/2011 going to take place?
The media workshop happens together with the KS/2011. Sunday is an
exclusive day for the workshops,
Hi Sarah/Greg,
Em 09-06-2011 21:21, Sarah Sharp escreveu:
I'm pleased to announce a USB mini-summit at LinuxCon Vancouver.
What: USB mini-summit
When: Tuesday, August 16th, all day
Where:At the conference venue, room TBD pending confirmation from
Angela Brown.
Proposed
On Thu, 4 Aug 2011, Adam Baker wrote:
On Thursday 04 August 2011, Mauro Carvalho Chehab wrote:
That'd also be my understanding. There are already several standard ways
to access data on still cameras: mass-storage, PTP, MTP, why invent Yet
Another One? Just learn to share a device
On Thu, 4 Aug 2011, Mauro Carvalho Chehab wrote:
Em 04-08-2011 18:16, Theodore Kilgore escreveu:
This sounds to be a good theme for the Workshop, or even to KS/2011.
Thanks. Do you recall when and where is KS/2011 going to take place?
The media workshop happens together with the
On Thu, Aug 04, 2011 at 07:21:47PM -0300, Mauro Carvalho Chehab wrote:
I know that this problem were somewhat solved for 3G modems, with the usage
of the userspace problem usb_modeswitch, and with some quirks for the USB
storage driver, but I'm not sure if such tricks will scale forever, as
On Thursday 04 August 2011, Theodore Kilgore wrote:
On Thu, 4 Aug 2011, Adam Baker wrote:
On Thursday 04 August 2011, Theodore Kilgore wrote:
As far as I know, /dev/sdx signifies a device which is accessible by
something like the USB mass storage protocols, at the very least. So,
if
Hello,
I have done some updates. MXL5005S based RTL2831U devices didn't worked
due to bug. That's main visible change. Secondly I added basic support
for RTL2832U to rtl28xx driver. And implemented I2C as I see it really
is, I think it is almost perfect now. It works fine my RTL2832U device
with
On Fri, 5 Aug 2011, Adam Baker wrote:
On Thursday 04 August 2011, Theodore Kilgore wrote:
On Thu, 4 Aug 2011, Adam Baker wrote:
On Thursday 04 August 2011, Theodore Kilgore wrote:
As far as I know, /dev/sdx signifies a device which is accessible by
something like the USB mass
Em 04-08-2011 20:22, Matthew Dharm escreveu:
On Thu, Aug 4, 2011 at 3:56 PM, Greg KH g...@kroah.com
mailto:g...@kroah.com wrote:
On Thu, Aug 04, 2011 at 07:21:47PM -0300, Mauro Carvalho Chehab wrote:
I know that this problem were somewhat solved for 3G modems, with the
usage
On Thu, 4 Aug 2011, Greg KH wrote:
On Thu, Aug 04, 2011 at 07:21:47PM -0300, Mauro Carvalho Chehab wrote:
I know that this problem were somewhat solved for 3G modems, with the usage
of the userspace problem usb_modeswitch, and with some quirks for the USB
storage driver, but I'm not sure
Hi,
I compiled and installed v4l-utils on Ubuntu 11.04 machine.
After this installation while running qv4l2 I am getting following
error.
qv4l2: symbol lookup error: qv4l2: undefined symbol:
libv4l2_default_dev_ops
Kindly help getting to the roots of this problem,
Note:
I am using following
63 matches
Mail list logo
