On Wed, 27 Mar 2013 21:07:41 +0100
Frank Schäfer wrote:
> Some devices without DVB support (such as the "Terratec Grabby" and
> "Easycap DC-60") provide isochronous DVB USB endpoints with
> wMaxPacketSize set to 0 bytes for all alt settings.
>
> Ignore these endpoints and avoid registering a DVB
On Thu, Mar 28, 2013 at 01:21:08AM -0400, David Miller wrote:
> From: Simon Horman
> Date: Thu, 28 Mar 2013 13:38:25 +0900
>
> > Add a new constant ETH_P_802_3_MIN, the minimum ethernet type for
> > an 802.3 frame. Frames with a lower value in the ethernet type field
> > are Ethernet II.
> >
> >
From: Simon Horman
Date: Thu, 28 Mar 2013 13:38:25 +0900
> Add a new constant ETH_P_802_3_MIN, the minimum ethernet type for
> an 802.3 frame. Frames with a lower value in the ethernet type field
> are Ethernet II.
>
> Also update all the users of this value that David Miller and
> I could find
On Wed, Mar 27, 2013 at 7:17 PM, Sylwester Nawrocki
wrote:
> On 03/27/2013 05:31 AM, Arun Kumar K wrote:
>> On Wed, Mar 27, 2013 at 4:21 AM, Sylwester Nawrocki
>> wrote:
>>> On 03/26/2013 01:17 PM, Arun Kumar K wrote:
> [...]
>> Only issue is with the context sharing.
>> Right now you can see tha
Add a new constant ETH_P_802_3_MIN, the minimum ethernet type for
an 802.3 frame. Frames with a lower value in the ethernet type field
are Ethernet II.
Also update all the users of this value that David Miller and
I could find to use the new constant.
Also correct a bug in util.c. The comparison
Hi Enric,
On Wednesday 27 March 2013 20:32:45 Enric Balletbo Serra wrote:
> Hi all,
>
> I've a problem running OMAP3 ISP with current 3.9-rc4. I tried to run the
> Laurent's live application to capture data from my mt9v034 sensor but kernel
> shows a possible circular locking dependency. Also th
Hi Hans,
On Wednesday 27 March 2013 11:54:34 Hans Verkuil wrote:
> Now that the VIDIOC_DBG_G_CHIP_NAME ioctl has been added to the v4l2 API I
> started work on removing the VIDIOC_DBG_G_CHIP_IDENT support in existing
> drivers. Based on that effort I realized that there are a few things that
> cou
This sensor is used by the "SpeedLink Vicious And Devine Laplace webcam" and
others. It supports resolutions up to 1600x1200 (at 7-8 fps), but for
resolutions higher than 640x480, further driver changes will be necessary,
such as sensor output resolution switching (including further configuration
c
OmniVision sensors are used as well in Empiatech based cameras such as the
"SpeedLink Vicious And Devine Laplace" webcam (EM2765 + Omnivision OV2640).
With this patch applied, OminiVision sensors with 8 bit address and register
width are detected (recent models have a 16 bit address width and use d
The Windows driver also probes at least two further i2c addresses (0x22 >> 1
and 0x66 >> 1). I've got some hints that they are very likely used by Samsung
and Kodak sensors, which are known to be used in Empia devices, too.
We havn't seen any devices using these sensors yet and don't know how to pr
Other sensors like the ones from OmniVision need a different probing procedure,
so it makes sense have separate functions for each manufacturer/sensor type.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-camera.c | 23 +++
1 Datei geändert, 19 Zeilen hinzu
em28xx-cards.c is very large and the sensor/camera related code is growing,
so move this code to a separate source code file em28xx-camera.c.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/Makefile|2 +-
drivers/media/usb/em28xx/em28xx-camera.c | 189 +
Add further Micron chip IDs to be able to identify all Micron sensors listed
by Empiatech.
Also probe the two alternate i2c addresses used by Micron sensors with 8 bit
address and 16 bit register width.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-camera.c | 126
Now that the board hints and the sensor initialization/configuration have been
separated, em28xx_detect_sensor() is the better name for this function.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-cards.c |7 +++
1 Datei geändert, 3 Zeilen hinzugefügt(+), 4 Zeilen entf
The current board hint code is mixed together with the sensor detection and
initialization code. It actually selects a board depending on the detected
sensor type only, with the result that 3 of the 6 webcam boards are currently
dead.
Separate it and move it to em28xx_hint_board() which already co
Sensor detection and initialization/configuration are currently mixed together.
This works as long as all devices with a particular sensor are working with the
same board configuration. In the long run, this will be not sufficient, so
separate these both steps to make the code more flexible and fut
This patch series improves the sensor device support/code.
The changes include
- splitting sensor detection, board hints and sensor
initialization/configuration (patches 1 and 2)
- moving the sensor specific code to a separate source code file (patch 4)
- improving/extending sensor probing and ide
On Wed, Mar 27, 2013 at 2:18 PM, Jiri Kosina wrote:
> On Tue, 19 Mar 2013, Alexey Klimov wrote:
>
>> Yes, i just checked how hid_ignore() works and prepared dirty fix to
>> test in almost the same way like it's done for Keene usb driver. I
>> will send correct fix in next few days.
>
> Any news on
Am 27.03.2013 19:04, schrieb Timo Teras:
> On Wed, 27 Mar 2013 19:57:49 +0200
> Timo Teras wrote:
>
>> The errors are weird. strace gives:
>> open("/dev/bus/usb/005/028", O_RDONLY) = -1 ENOENT (No such file or
>> directory) open("/dev/bus/usb/005/028", O_RDONLY) = -1 ENOENT (No
>> such file or d
Masterkit MA901 usb radio device shares USB ID with Atmel V-USB devices.
This patch adds additional checks in usb_ma901radio_probe() and if
product or manufacturer doesn't match we return -ENODEV and don't
continue. This allows hid drivers to handle not MA901 device.
Signed-off-by: Alexey Klimov
This patch reverts commit 0322bd3980b3ebf7dde8474e22614cb443d6479a and
adds checks in hid_ignore() for Masterkit MA901 usb radio device. This
usb radio device shares USB ID with many Atmel V-USB (and probably
other) devices so patch sorts things out by checking name, vendor,
product of hid device.
Some devices without DVB support (such as the "Terratec Grabby" and
"Easycap DC-60") provide isochronous DVB USB endpoints with wMaxPacketSize set
to 0 bytes for all alt settings.
Ignore these endpoints and avoid registering a DVB device node and loading the
DVB driver extension.
Signed-off-by: F
Hi all,
I've a problem running OMAP3 ISP with current 3.9-rc4. I tried to run
the Laurent's live application to capture data from my mt9v034 sensor
but kernel shows a possible circular locking dependency. Also the
captured images are wrong and I see garbage. The same environment
worked for me wit
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: Wed Mar 27 19:00:21 CET 2013
git branch: test
git hash: 004e45d736bfe62159bd4dc1549eff414bd27496
gcc versio
On Wed, 27 Mar 2013 19:57:49 +0200
Timo Teras wrote:
> The errors are weird. strace gives:
> open("/dev/bus/usb/005/028", O_RDONLY) = -1 ENOENT (No such file or
> directory) open("/dev/bus/usb/005/028", O_RDONLY) = -1 ENOENT (No
> such file or directory)
>
> # ls /dev/bus/usb/005/
> 001 003
On Wed, 27 Mar 2013 18:37:26 +0100
Frank Schäfer wrote:
> Am 25.03.2013 18:08, schrieb Timo Teras:
> > I just bought a Terratec Grabby hardware revision 2 in hopes that it
> > would work on my linux box.
> >
> > But alas, I got only sound working. It seems that analog video
> > picture grabbing d
On 03/27/2013 03:01 AM, Mike Turquette wrote:
> Quoting Prasanna Kumar (2013-03-25 22:20:51)
>> From: Prasanna Kumar
>>
>> According to Common Clock framework , modified the method of getting
Huh ? Could you explain in detail what exactly in this patch is related
to the Common Clock Framework ? I
Am 25.03.2013 18:08, schrieb Timo Teras:
> I just bought a Terratec Grabby hardware revision 2 in hopes that it
> would work on my linux box.
>
> But alas, I got only sound working. It seems that analog video picture
> grabbing does not work.
>
> I tried kernels 3.4.34-grsec, 3.7.1 (vanilla), 3.8.2
On Tue, 26 Mar 2013 10:20:56 +0200
Timo Teras wrote:
> I did manage to get decent traces with USBlyzer evaluation version.
Nothing _that_ exciting there. Though, there's quite a bit of
differences on certain register writes. I tried copying the changed
parts, but did not really help.
Turning on
On 03/27/2013 05:31 AM, Arun Kumar K wrote:
> On Wed, Mar 27, 2013 at 4:21 AM, Sylwester Nawrocki
> wrote:
>> On 03/26/2013 01:17 PM, Arun Kumar K wrote:
[...]
> Only issue is with the context sharing.
> Right now you can see that the fimc-is context is shared between all
> the subdevs.
> As all o
Hi Kamil,
Thank you for the review.
Please find my response inline.
On Wed, Mar 27, 2013 at 4:54 PM, Kamil Debski wrote:
> Hi,
>
>> From: Arun Kumar K [mailto:arun...@samsung.com]
>> Sent: Tuesday, March 26, 2013 8:28 AM
>>
>> MFC v6 needs minimum number of output buffers to be queued for encode
Hi,
> From: Arun Kumar K [mailto:arun...@samsung.com]
> Sent: Tuesday, March 26, 2013 8:28 AM
>
> MFC v6 needs minimum number of output buffers to be queued for encoder
> depending on the stream type and profile.
> For achieving this the sequence for allocating buffers at the encoder
> is modifie
Em Wed, 27 Mar 2013 11:39:27 +0100 (CET)
Jiri Kosina escreveu:
> On Sun, 24 Mar 2013, Masanari Iida wrote:
>
> > Correct spelling typos.
> >
> > Signed-off-by: Masanari Iida
>
> I can take this one. Thanks.
Hi Jiri,
I merged this already on my tree:
commit 842059aa4796d7c59bc3801d48896ba06
Now that the VIDIOC_DBG_G_CHIP_NAME ioctl has been added to the v4l2 API I
started work on removing the VIDIOC_DBG_G_CHIP_IDENT support in existing
drivers. Based on that effort I realized that there are a few things that
could be improved.
One thing that Laurent pointed out is that this ioctl sho
Hi,
On 27 March 2013 15:53, Inki Dae wrote:
> 2013/3/20 Vikas Sajjan :
>> While migrating to common clock framework (CCF), found that the FIMD clocks
>> were pulled down by the CCF.
>> If CCF finds any clock(s) which has NOT been claimed by any of the
>> drivers, then such clock(s) are PULLed low
On Sun, 24 Mar 2013, Masanari Iida wrote:
> Correct spelling typos.
>
> Signed-off-by: Masanari Iida
I can take this one. Thanks.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More major
2013/3/20 Vikas Sajjan :
> While migrating to common clock framework (CCF), found that the FIMD clocks
> were pulled down by the CCF.
> If CCF finds any clock(s) which has NOT been claimed by any of the
> drivers, then such clock(s) are PULLed low by CCF.
>
> By calling clk_prepare_enable() for FIM
On Wed March 27 2013 11:11:53 Laurent Pinchart wrote:
> Hi Hans,
>
> On Wednesday 27 March 2013 09:41:33 Hans Verkuil wrote:
> > On Wed March 27 2013 02:11:23 Laurent Pinchart wrote:
> > > On Monday 18 March 2013 17:38:16 Hans Verkuil wrote:
> > > > From: Hans Verkuil
> > > >
> > > > Simplify th
On Tue, 19 Mar 2013, Alexey Klimov wrote:
> Yes, i just checked how hid_ignore() works and prepared dirty fix to
> test in almost the same way like it's done for Keene usb driver. I
> will send correct fix in next few days.
Any news on this, please?
--
Jiri Kosina
SUSE Labs
--
To unsubscribe fr
Hi Hans,
On Wednesday 27 March 2013 09:41:33 Hans Verkuil wrote:
> On Wed March 27 2013 02:11:23 Laurent Pinchart wrote:
> > On Monday 18 March 2013 17:38:16 Hans Verkuil wrote:
> > > From: Hans Verkuil
> > >
> > > Simplify the debugging ioctls by creating the VIDIOC_DBG_G_CHIP_NAME
> > > ioctl.
On Wed March 27 2013 02:11:23 Laurent Pinchart wrote:
> Hi Hans,
>
> On Monday 18 March 2013 17:38:16 Hans Verkuil wrote:
> > From: Hans Verkuil
> >
> > Simplify the debugging ioctls by creating the VIDIOC_DBG_G_CHIP_NAME ioctl.
> > This will eventually replace VIDIOC_DBG_G_CHIP_IDENT. Chip matc
41 matches
Mail list logo
