This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Sun Mar 3 19:00:34 CET 2013
git branch: for_v3.9
git hash: ed72d37a33fdf43dc47787fe220532cdec9da528
gcc ve
Streaming doesn't work with the EM2765 if bit 5 of the output format register
0x27 is set.
It's actually not clear if really has to be set for the other chips, but for
now let's keep it to avoid regressions and add a comment to the code.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/
The Windows driver writes the output resolution to registers 0x34 (width / 16)
and 0x35 (height / 16) always.
We don't know yet what these registers are used for.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-core.c |7 +++
drivers/media/usb/em28xx/em28xx-reg.h |6
This chip can be found in the SpeedLink VAD Laplace webcam (1ae7:9003 and
1ae7:9004).
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-cards.c | 13 -
drivers/media/usb/em28xx/em28xx-reg.h |1 +
drivers/media/usb/em28xx/em28xx.h |1 +
3 Dateien geän
The em25xx/em276x/em277x/em278x frame data format is different to the one used
by the em2710/em2750/em28xx chips.
With the recent cleanups and reorganization of the frame data processing code it
can be easily extended to support these devices.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/e
The webcam "SpeedLink VAD Laplace" (em2765 + ov2640) uses a special algorithm
for i2c communication with the sensor, which is connected to a second i2c bus.
We don't know yet how to find out which devices support/use it.
It's very likely used by all em25xx and em276x+ bridges.
Tests with other em2
This patch series adds basic support for the em25xx/276x/7x/8x camera bridges.
These devices differ from the em2710/2750 and em28xx bridges in several points:
1) a second i2c bus is provided which has to be accessed with a different
read/write algorithm (=> patch 1)
2) a different frame data fo
If the eeprom key isn't valid, either a different (currently unknown) format
is used or the eeprom is corrupted.
In both cases it doesn't make sense to interpret the data.
Also print an error message.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-i2c.c |8 ++--
1 Datei
The data is stored as little endian in the eeprom.
Hence the correct data types should be used and the data should be converted
to the machine endianess before using it.
The eeprom id (key) also isn't a 32 bit value but 4 separate bytes instead.
Signed-off-by: Frank Schäfer
---
drivers/media/usb
We currently reserve an array of 256 bytes for the eeprom content in the device
struct. For eeproms with 16 bit address width it might even be necessary to
increase the buffer size further.
Having such a big chunk of memory reserved even if the device has no eeprom and
keeping it after it has alre
Newer devices (em2874, em2884, em28174, em25xx, em27[6,7,8]x) use eeproms with
16 bit instead of 8 bit address width.
The used eeprom type depends on the chip type, which makes sure eeproms can't
be damaged.
This patch adds basic support for 16 bit eeproms only, which includes
- reading the conten
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-cards.c |1 +
1 Datei geändert, 1 Zeile hinzugefügt(+)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 2e3d3ad..5a5b637 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
The new eeproms with 16 address width still have the the device config dataset
(the content of the old 8 bit eeproms) embedded.
Hauppauge also continues to include the tveeprom data structure inside this
dataset in their devices.
The start address of the dataset depends on the start address of the
The current code first configures register EM28XX_R06_I2C_CLK, which includes
i2c speed, ack, wait and (on some devices) i2c bus selection.
The register value usually comes from the board definition.
em28xx_i2c_register() is called afterwards, which also tries to read the eeprom.
If the device uses
Add a helper function for reading data blocks from i2c devices with 8 or 16 bit
address width and 8 bit register width.
This allows us to reduce the size of new code added by the following patches.
Works only for devices with activated register auto incrementation.
Signed-off-by: Frank Schäfer
--
The current code uses only a single debug level and all debug messages are
printed for i2c_debug >= 2 only. So debug level 1 is actually the same as
level 0, which is odd.
Users expect debugging messages to become enabled for anything else than
debug level 0.
Fix it and simplify the code a bit by
There is only a single place where the dprintk2 macro is used, so get rid of it.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-i2c.c | 17 ++---
1 Datei geändert, 6 Zeilen hinzugefügt(+), 11 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-i2c.c
Reduces the number of characters/lines, unifies the code and improves
readability.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-i2c.c | 55 ++---
1 Datei geändert, 24 Zeilen hinzugefügt(+), 31 Zeilen entfernt(-)
diff --git a/drivers/media/usb/e
The first 3 patches clean up / simplify the debugging and info messages a bit.
Patches 4, 5 and 6 fix two bugs I've noticed while working on the eeprom stuff.
Patches 7-10 add support for the newer eeproms with 16 bit address width.
This allows us to display the eeprom content, to calculate the e
Em Sun, 03 Mar 2013 11:50:25 -0300
Alfredo Jesús Delaiti escreveu:
> The new data replacement in mb86a20s
>
> /*
> * Initialization sequence: Use whatevere default values that PV SBTVD
> * does on its initialisation, obtained via USB snoop
> */
> static struct regdata mb86a20s_init[] = {
Em Sun, 03 Mar 2013 11:50:25 -0300
Alfredo Jesús Delaiti escreveu:
> Hi Mauro and others from the list
> I searched for a plan B to get the data bus and after several
> alternative plans that were available to me was to do a logic analyzer
> (http://tfla-01.berlios.de).
Yeah, that should work
As the device got re-initialized, the stats should vanish
until the device gets lock again.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/mb86a20s.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/drivers/media/dvb-frontends/mb
Putting em28xx in suspend mode when a feed stops is just plain
wrong. Every time a new PES filter is changed, the DVB demux
code will stop the current feed, and then start a new one.
If are there any code that switches off the frontend, via
some GPIO setting, this would make the DVB fail.
This cond
Instead of using 3.3 MHz IF, use 4MHz. That's the standard
value for the demod, and, while it can be adjusted, 3.3 MHz
is out of the recommended range. So, let's stick with the
default.
With regards to the IF voltage level, instead of using
0.5 V(p-p) for IF, use 2V, giving a 12dB gain.
The rationa
State 9 means TS started to be output, and it should be
associated with FE_HAS_SYNC.
The mb86a20scan get CNR statistics at state 7, when frame sync
is obtained.
As CNR may help to adjust the antenna, provide it earlier.
A latter patch could eventually start outputing MER measures
earlier, but th
Instead of hardcoding a fixed IF frequency of 3.3 MHz, use
the IF frequency provided by the tuner driver.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/mb86a20s.c | 57 +++---
1 file changed, 53 insertions(+), 4 deletions(-)
diff --git a/driver
While working to add support for a new device, I discovered a
series of issues with mb86a20s and one with em28xx.
While here, I also changed cx231xx to improve its signal
detection, by using a different IF frequency and increasing the
IF signal level from the tuner by 12dB.
Mauro Carvalho Chehab
Getting signal strength requires some loop poking with I2C.
Don't let it happen too fast.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/mb86a20s.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb-frontends/mb86
Use the AGC settings present on a newer device.
The initial settings were taken from one of the first devices with
mb86a20s, and there are several reports that this is not working
properly on some places.
So, instead of keeping using it, get the parameters taken from a
newer device. Tests are wel
Signal strength is always available. There's no reason to reset
it, as it has its own logic to reset it already.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/mb86a20s.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/drivers/me
Always init the frontend when set_frontend is called. The rationale
is: it was noticed that, on some devices, it fails to lock with a
different channel. It seems that some other registers need to be
restored to its initial state, when the channel changes.
As it is better to reset everything, even
A register typo made the calculation to not work. Fix it.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/mb86a20s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/drivers/media/dvb-frontends/mb86a20s.c
index e22
There are a few debug tests that are shown with dev_err() or
dev_info(). Replace them by dev_dbg().
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb-frontends/mb86a20s.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb-frontends/mb86a20s.c
b/
On Sun, Mar 3, 2013 at 4:37 AM, Rémi Denis-Courmont wrote:
> Hello,
>
> Trying to use USERPTR buffers with UVC, user space gets stuck either in
> poll(POLLIN) or in ioctl(VIDIOC_DQBUF). It seems the UVC driver never ever
> returns a frame in USERPTR mode. The symptoms are identical with ke
Hi Mauro and others from the list
El 06/02/13 11:12, Alfredo Jesús Delaiti escribió:
Hi
El 28/01/13 17:47, Alfredo Jesús Delaiti escribió:
Hi
El 28/01/13 07:23, Mauro Carvalho Chehab escribió:
Em Sun, 27 Jan 2013 18:48:57 -0300
Alfredo Jesús Delaiti escreveu:
Hi
El 27/01/13 13:16, Mauro C
Hello,
Trying to use USERPTR buffers with UVC, user space gets stuck either in
poll(POLLIN) or in ioctl(VIDIOC_DQBUF). It seems the UVC driver never ever
returns a frame in USERPTR mode. The symptoms are identical with kernel
versions 3.6, 3.7 and 3.8. I also tested 3.2, but it did not
On Sun March 3 2013 02:53:42 Cesar Eduardo Barros wrote:
> This file was moved to drivers/media/common/ by commit 6259582 ([media]
> cx2341x: move from media/i2c to media/common).
>
> Cc: Hans Verkuil
> Cc: linux-media@vger.kernel.org
> Signed-off-by: Cesar Eduardo Barros
> ---
> MAINTAINERS |
37 matches
Mail list logo
