Re: [RFC] V4L2 events with extensible payload
On Mon February 11 2013 23:32:33 Sylwester Nawrocki wrote:
>
> Hi All,
>
> I have run recently into a situation where it would be useful to have
> a data structure within the struct v4l2_event::u union of size greater
> than 64 bytes, which is the current size of the union.
>
> Currently struct v4l2_event looks like this [1], and I have been thinking
> about extending it with a 'size' member that would be telling the actual
> size of the payload data structure and a pointer to a specific event data
> structure would be added to the union u.
>
> [1] http://lxr.linux.no/#linux+v3.7.4/include/uapi/linux/videodev2.h#L1798
>
> struct v4l2_event_ext1 {
> __u8data[96];
> };
>
> struct v4l2_event {
> __u32 type;
> union {
> struct v4l2_event_vsync vsync;
> struct v4l2_event_ctrlctrl;
> struct v4l2_event_frame_sync frame_sync;
> struct v4l2_event_ext1*ext1;
> __u8 data[64];
> } u;
> __u32pending;
> __u32sequence;
> struct timespec timestamp;
> __u32id;
> __u32size;
> __u32reserved[7];
> };
>
> Then before VIDIOC_DQBUF ioctl an application would have allocated a
> buffer for the event and would set 'size' to the size of this buffer.
> If the size would have been to small for a next event to be dequeued
> from the kernel an ioctl would return -ENOSPC errno.
>
> Everything seemed nice and straightforward until I have discovered that
> VIDIOC_DQEVENT ioctl doesn't allow to pass anything from user space to
> the kernel, because it is defined with _IOR().
>
> And here come my questions:
>
> 1. Is the event payload supposed to be relatively small and the interface
> is deliberately defined to disallow passing anything with the payload
> greater than 64 B ? In order to keep it a rather lightweight interface
> and anything that needs more data should use other/new ioctls ?
Yes, that was the original design philisophy. In particular because events
can be generated from interrupt context and you cannot allocate memory in
interrupt context. Note that the original design had one event queue for
each filehandle containing all types of events. That made it basically
impossible to have variable sized payloads without having to allocate
memory for each payload.
The idea that I had in mind was that if you need larger payloads then
the event should provide a cookie of some sort that you can use with another
ioctl to get hold of the full payload.
The later redesign (one queue per filehandle per event type) would have
made that much easier since you could allocate the needed payload data
when the event is subscribed, but by then the ioctl was already defined as
IOR.
> 2. If answer to 1. is 'no', then what would be a best way to proceed to
> make the event's payload more flexible ? Would creating a new ioctl to
> dequeue events be way to go ?
>
> I am asking mostly in context of the face detection feature in the
> Exynos4x12 SoC camera ISP. Similarly, the v4l2 event payload size was a
> limitation during development of a driver for the face detection IP block
> available in OMAP4 SoCs by Ming Lei [2]:
>
> "From the start, I hope that the event interface can be used to retrieve
> object detection result.
>
> When I found it is difficult to fit 'struct v4l2_od_object' into 64 bytes,
> I decide to introduce two IOCTLs for the purpose."
>
> I thought it would have been better to make the event interface more
> flexible and reuse the existing infrastructure, rather than inventing new
> ioctls for the purpose and reimplementing similar set of features.
>
>
> Any suggestions, thoughts are warm welcome.
I don't think changing DQEVENT is the right approach. While possible, it
would create more confusion than it solves IMHO. What might be better (just
brainstorming here) is to add a DQEVENT_PAYLOAD ioctl. The DQEVENT will give
you the required size of the payload and the sequence number can be used as
the cookie. Only the payload of the last dequeued event can be retrieved
that way, which shouldn't be an issue as far as I can tell.
Hmm, strictly speaking you do not need the sequence number if you just return
the payload of the last event, but it's probably a good sanity check.
Internally this can be implemented by allocating the payload memory when the
event is subscribed or when the event is generated. The first method is best
if events need to be generated during interrupt context, the second method
is best if the payload can be large and differs in size for each event. Of
course, in that case the event can never be generated from interrupt context.
You probably want to have the choice which method to use.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More maj
[PATCH] CHROMIUM: dma-buf: restore args on failure of dma_buf_mmap
From: John Sheu
Callers to dma_buf_mmap expect to fput() the vma struct's vm_file
themselves on failure. Not restoring the struct's data on failure
causes a double-decrement of the vm_file's refcount.
Signed-off-by: John Sheu
---
drivers/base/dma-buf.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 09e6878..06c6225 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -536,6 +536,9 @@ EXPORT_SYMBOL_GPL(dma_buf_kunmap);
int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma,
unsigned long pgoff)
{
+ struct file *oldfile;
+ int ret;
+
if (WARN_ON(!dmabuf || !vma))
return -EINVAL;
@@ -549,15 +552,21 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct
vm_area_struct *vma,
return -EINVAL;
/* readjust the vma */
- if (vma->vm_file)
- fput(vma->vm_file);
-
+ get_file(dmabuf->file);
+ oldfile = vma->vm_file;
vma->vm_file = dmabuf->file;
- get_file(vma->vm_file);
-
vma->vm_pgoff = pgoff;
- return dmabuf->ops->mmap(dmabuf, vma);
+ ret = dmabuf->ops->mmap(dmabuf, vma);
+ if (ret) {
+ /* restore old parameters on failure */
+ vma->vm_file = oldfile;
+ fput(dmabuf->file);
+ } else {
+ if (oldfile)
+ fput(oldfile);
+ }
+ return ret;
}
EXPORT_SYMBOL_GPL(dma_buf_mmap);
--
1.7.8.6
--
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] radio-si470x doc: add info about v4l2-ctl and sox+alsa
Patch adds information about using v4l2-ctl utility to tune the si470x radio and example how to use sox+alsa to redirect sound from radio sound device to another sound device. Signed-off-by: Alexey Klimov diff --git a/Documentation/video4linux/si470x.txt b/Documentation/video4linux/si470x.txt index 3a7823e..98c3292 100644 --- a/Documentation/video4linux/si470x.txt +++ b/Documentation/video4linux/si470x.txt @@ -53,6 +53,9 @@ Testing is usually done with most application under Debian/testing: - kradio - Comfortable Radio Application for KDE - radio - ncurses-based radio application - mplayer - The Ultimate Movie Player For Linux +- v4l2-ctl - Collection of command line video4linux utilities +For example, you can use: +v4l2-ctl -d /dev/radio0 --set-ctrl=volume=10,mute=0 --set-freq=95.21 --all There is also a library libv4l, which can be used. It's going to have a function for frequency seeking, either by using hardware functionality as in radio-si470x @@ -75,8 +78,10 @@ commands. Please adjust the audio devices to your needs (/dev/dsp* and hw:x,x). If you just want to test audio (very poor quality): cat /dev/dsp1 > /dev/dsp -If you use OSS try: +If you use sox + OSS try: sox -2 --endian little -r 96000 -t oss /dev/dsp1 -t oss /dev/dsp +or using sox + alsa: +sox --endian little -c 2 -S -r 96000 -t alsa hw:1 -t alsa -r 96000 hw:0 If you use arts try: arecord -D hw:1,0 -r96000 -c2 -f S16_LE | artsdsp aplay -B - -- 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 v3 0/6] Driver for Si476x series of chips
Hello Andrey, Mauro, Hans, On Tue, Oct 23, 2012 at 6:44 PM, Andrey Smirnov wrote: > This is a third version of the patchset originaly posted here: > https://lkml.org/lkml/2012/9/13/590 > > Second version of the patch was posted here: > https://lkml.org/lkml/2012/10/5/598 > > To save everyone's time I'll repost the original description of it: > > This patchset contains a driver for a Silicon Laboratories 476x series > of radio tuners. The driver itself is implemented as an MFD devices > comprised of three parts: > 1. Core device that provides all the other devices with basic > functionality and locking scheme. > 2. Radio device that translates between V4L2 subsystem requests into > Core device commands. > 3. Codec device that does similar to the earlier described task, but > for ALSA SoC subsystem. > > v3 of this driver has following changes: > - All custom ioctls were moved to be V4L2 controls or debugfs files > - Chip properties handling was moved to regmap API, so this should >allow for cleaner code, and hopefully more consistent behaviour of >the driver during switch between AM/FM(wich involevs power-cycling >of the chip) > > I was hoping to not touch the code of the codec driver, since Mark has > already appplied the previous version, but because of the last item I > had to. > > Unfotunately, since my ARM setup runs only 3.1 kernel, I was only able > to test this driver on a standalone USB-connected board that has a > dedicated Cortex M3 working as a transparent USB to I2C bridge which > was connected to a off-the-shelf x86-64 laptop running Ubuntu with > custom kernel compile form git.linuxtv.org/media_tree.git. Which means > that I was unable to test the change in the codec code, except for the > fact the it compiles. > > > Here is v4l2-compliance output for one of the tuners(as per Hans' > request): [] > Andrey Smirnov (6): > Add header files and Kbuild plumbing for SI476x MFD core > Add the main bulk of core driver for SI476x code > Add commands abstraction layer for SI476X MFD > Add chip properties handling code for SI476X MFD > Add a V4L2 driver for SI476X MFD > Add a codec driver for SI476X MFD What is the final destiny of this patch series? I found that only "codec driver for SI476X MFD" is pushed in kernel 3.8 by Mark Brown and that's all, is it? I can't find this patch series on patchwork.linuxtv.org or in media git trees, for example, scheduled for 3.9. I also see that comments for this patches aren't answered and looks like v4 is necessary. Andrey, do you plan to make v4 series? May be it was already emailed but i can't find it. Maybe review or comments from alsa and mfd communities are missed? So, without v4 it will not find its way into kernel, right? -- Best regards, Klimov Alexey -- 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
[RFC] V4L2 events with extensible payload
Hi All,
I have run recently into a situation where it would be useful to have
a data structure within the struct v4l2_event::u union of size greater
than 64 bytes, which is the current size of the union.
Currently struct v4l2_event looks like this [1], and I have been thinking
about extending it with a 'size' member that would be telling the actual
size of the payload data structure and a pointer to a specific event data
structure would be added to the union u.
[1] http://lxr.linux.no/#linux+v3.7.4/include/uapi/linux/videodev2.h#L1798
struct v4l2_event_ext1 {
__u8data[96];
};
struct v4l2_event {
__u32 type;
union {
struct v4l2_event_vsync vsync;
struct v4l2_event_ctrlctrl;
struct v4l2_event_frame_sync frame_sync;
struct v4l2_event_ext1*ext1;
__u8 data[64];
} u;
__u32pending;
__u32sequence;
struct timespec timestamp;
__u32id;
__u32size;
__u32reserved[7];
};
Then before VIDIOC_DQBUF ioctl an application would have allocated a
buffer for the event and would set 'size' to the size of this buffer.
If the size would have been to small for a next event to be dequeued
from the kernel an ioctl would return -ENOSPC errno.
Everything seemed nice and straightforward until I have discovered that
VIDIOC_DQEVENT ioctl doesn't allow to pass anything from user space to
the kernel, because it is defined with _IOR().
And here come my questions:
1. Is the event payload supposed to be relatively small and the interface
is deliberately defined to disallow passing anything with the payload
greater than 64 B ? In order to keep it a rather lightweight interface
and anything that needs more data should use other/new ioctls ?
2. If answer to 1. is 'no', then what would be a best way to proceed to
make the event's payload more flexible ? Would creating a new ioctl to
dequeue events be way to go ?
I am asking mostly in context of the face detection feature in the
Exynos4x12 SoC camera ISP. Similarly, the v4l2 event payload size was a
limitation during development of a driver for the face detection IP block
available in OMAP4 SoCs by Ming Lei [2]:
"From the start, I hope that the event interface can be used to retrieve
object detection result.
When I found it is difficult to fit 'struct v4l2_od_object' into 64 bytes,
I decide to introduce two IOCTLs for the purpose."
I thought it would have been better to make the event interface more
flexible and reuse the existing infrastructure, rather than inventing new
ioctls for the purpose and reimplementing similar set of features.
Any suggestions, thoughts are warm welcome.
[2] http://patchwork.linuxtv.org/patch/8814
--
Regards,
Sylwester
--
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 v4 02/10] s5p-fimc: Add device tree support for FIMC devices
On 02/09/2013 03:29 PM, Sylwester Nawrocki wrote: > On 02/09/2013 01:32 AM, Stephen Warren wrote: >> On 02/08/2013 05:05 PM, Sylwester Nawrocki wrote: >>> On 02/09/2013 12:21 AM, Stephen Warren wrote: On 02/08/2013 04:16 PM, Sylwester Nawrocki wrote: > On 02/07/2013 12:40 AM, Stephen Warren wrote: >>> diff --git >>> a/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt >>> b/Documentation/devicetree/bindings/media/soc/samsung-fimc.txt >> >>> +Samsung S5P/EXYNOS SoC Camera Subsystem (FIMC) >>> +-- ... >>> +For every fimc node a numbered alias should be present in the >>> aliases node. >>> +Aliases are of the form fimc, whereis an integer (0...N) >>> specifying >>> +the IP's instance index. ... >>> Different compatible values might not work, when for example there >>> are 3 IPs out of 4 of one type and the fourth one of another type. >>> It wouldn't even by really different types, just quirks/little >>> differences between them, e.g. no data path routed to one of other IPs. >> >> I was thinking of using feature-/quirk-oriented properties. For example, >> if there's a port on 3 of the 4 devices to connect to some other IP >> block, simply include a boolean property to indicate whether that port >> is present. It would be in 3 of the nodes but not the 4th. > > Yes, I could add several properties corresponding to all members of this > [3] data structure. But still it is needed to clearly identify the IP > block in a set of the hardware instances. Why? What decisions will be made based on the identify of the IP block instance that wouldn't be covered by DT properties that describe which features/bugs/... the IP block instance has? >>> Then to connect e.g. MIPI-CSIS.0 to FIMC.2 at run time an index of the >>> MIPI-CSIS needs to be written to the FIMC.2 data input control register. >>> Even though MIPI-CSIS.N are same in terms of hardware structure they >>> still >>> need to be distinguished as separate instances. >> >> Oh, so you're using the alias ID as the value to write into the FIMC.2 >> register for that. I'm not 100% familiar with aliases, but they seem >> like a more user-oriented naming thing to me, whereas values for hooking >> up intra-SoC routing are an unrelated namespace semantically, even if >> the values happen to line up right now. Perhaps rather than a Boolean >> property I mentioned above, use a custom property to indicate the ID >> that the FIMC.2 object knows the MIPI-CSIS.0 object as? While this seems > > That could be 'reg' property in the MIPI-CSIS.0 'port' subnode that > links it to the image sensor node ([4], line 165). Because MIPI-CSIS IP > blocks are immutably connected to the SoC camera physical MIPI CSI-2 > interfaces, and the physical camera ports have fixed assignment to the > MIPI-CSIS devices.. This way we could drop alias ID for the MIPI-CSIS > nodes. And their instance index that is required for the top level > driver which exposes topology and the routing capabilities to user space > could be restored from the reg property value by subtracting a fixed > offset. I suppose that would work. It feels a little indirect, and I think means that the driver needs to go find some child node defining its end of some link, then find the node representing the other end of the link, then read properties out of that other node to find the value. That seems a little unusual, but I guess it would work. I'm not sure of the long-term implications of doing that kind of thing. You'd want to run the idea past some DT maintainers/experts. ... > I can see aliases used in bindings of multiple devices: uart, spi, sound > interfaces, gpio, ... And all bindings seem to impose some rules on how > their aliases are created. Do you have specific examples? I really don't think the bindings should be dictating the alias values. >> After all, what happens in some later SoC where you have two different >> types of module that feed into the common module, such that type A >> sources have IDs 0..3 in the common module, and type B sources have IDs >> 4..7 in the common module - you wouldn't want to require alias ISs 4..7 >> for the type B DT nodes. > > There is no need to write alias ID directly into registers, and actually > it doesn't really happen. But we need to know that, for example camera A > is connected to physical MIPI CSI-2 channel 0 and to capture video with > DMA engine of FIMC.2 we need to set FIMC.2 input register to link it to > MIPI-CSIS 0. OK, so the IDs are selecting which register to write, or which mux settings to access. That's pretty much semantically the same thing. -- 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: media_tree daily build: ERRORS
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: Mon Feb 11 19:00:17 CET 2013 git branch: for_v3.9 git hash: 4880f56438ef56457edd5548b257382761591998 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8.03-marune linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: ERRORS linux-git-arm-omap: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-rc4-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-rc4-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API 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: [git:v4l-dvb/for_v3.9] [media] fc0011: Return early, if the frequency is already tuned
Can you please revert this one again? It might cause issues if the dvb device
is reset/reinitialized.
On Fri, 08 Feb 2013 20:51:36 +0100
Mauro Carvalho Chehab wrote:
> This is an automatic generated email to let you know that the following patch
> were queued at the
> http://git.linuxtv.org/media_tree.git tree:
>
> Subject: [media] fc0011: Return early, if the frequency is already tuned
> Author: Michael Büsch
> Date:Thu Feb 7 12:21:06 2013 -0300
>
> Return early, if we already tuned to a frequency.
>
> Signed-off-by: Michael Buesch
> Signed-off-by: Mauro Carvalho Chehab
>
> drivers/media/tuners/fc0011.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> ---
>
> http://git.linuxtv.org/media_tree.git?a=commitdiff;h=a92591a7112042f92b609be42bc332d989776e9b
>
> diff --git a/drivers/media/tuners/fc0011.c b/drivers/media/tuners/fc0011.c
> index 3932aa8..18caab1 100644
> --- a/drivers/media/tuners/fc0011.c
> +++ b/drivers/media/tuners/fc0011.c
> @@ -187,6 +187,9 @@ static int fc0011_set_params(struct dvb_frontend *fe)
> u8 fa, fp, vco_sel, vco_cal;
> u8 regs[FC11_NR_REGS] = { };
>
> + if (priv->frequency == p->frequency)
> + return 0;
> +
> regs[FC11_REG_7] = 0x0F;
> regs[FC11_REG_8] = 0x3E;
> regs[FC11_REG_10] = 0xB8;
>
--
Greetings, Michael.
PGP: 908D8B0E
signature.asc
Description: PGP signature
[PATCH] staging: media: Remove unnecessary OOM messages
alloc failures already get standardized OOM
messages and a dump_stack.
Signed-off-by: Joe Perches
---
drivers/staging/media/as102/as102_usb_drv.c | 4 +---
drivers/staging/media/go7007/go7007-fw.c| 24 +++-
drivers/staging/media/go7007/s2250-loader.c | 5 ++---
drivers/staging/media/lirc/lirc_imon.c | 3 ---
drivers/staging/media/lirc/lirc_sasem.c | 6 --
5 files changed, 10 insertions(+), 32 deletions(-)
diff --git a/drivers/staging/media/as102/as102_usb_drv.c
b/drivers/staging/media/as102/as102_usb_drv.c
index aaf1bc2..9f275f0 100644
--- a/drivers/staging/media/as102/as102_usb_drv.c
+++ b/drivers/staging/media/as102/as102_usb_drv.c
@@ -374,10 +374,8 @@ static int as102_usb_probe(struct usb_interface *intf,
}
as102_dev = kzalloc(sizeof(struct as102_dev_t), GFP_KERNEL);
- if (as102_dev == NULL) {
- dev_err(&intf->dev, "%s: kzalloc failed\n", __func__);
+ if (as102_dev == NULL)
return -ENOMEM;
- }
/* Assign the user-friendly device name */
for (i = 0; i < ARRAY_SIZE(as102_usb_id_table); i++) {
diff --git a/drivers/staging/media/go7007/go7007-fw.c
b/drivers/staging/media/go7007/go7007-fw.c
index f99c05b..a5ede1c 100644
--- a/drivers/staging/media/go7007/go7007-fw.c
+++ b/drivers/staging/media/go7007/go7007-fw.c
@@ -381,11 +381,8 @@ static int gen_mjpeghdr_to_package(struct go7007 *go,
__le16 *code, int space)
int size = 0, i, off = 0, chunk;
buf = kzalloc(4096, GFP_KERNEL);
- if (buf == NULL) {
- dev_err(go->dev,
- "unable to allocate 4096 bytes for firmware
construction\n");
+ if (buf == NULL)
return -1;
- }
for (i = 1; i < 32; ++i) {
mjpeg_frame_header(go, buf + size, i);
@@ -651,11 +648,9 @@ static int gen_mpeg1hdr_to_package(struct go7007 *go,
int i, off = 0, chunk;
buf = kzalloc(5120, GFP_KERNEL);
- if (buf == NULL) {
- dev_err(go->dev,
- "unable to allocate 5120 bytes for firmware
construction\n");
+ if (buf == NULL)
return -1;
- }
+
framelen[0] = mpeg1_frame_header(go, buf, 0, 1, PFRAME);
if (go->interlace_coding)
framelen[0] += mpeg1_frame_header(go, buf + framelen[0] / 8,
@@ -838,11 +833,9 @@ static int gen_mpeg4hdr_to_package(struct go7007 *go,
int i, off = 0, chunk;
buf = kzalloc(5120, GFP_KERNEL);
- if (buf == NULL) {
- dev_err(go->dev,
- "unable to allocate 5120 bytes for firmware
construction\n");
+ if (buf == NULL)
return -1;
- }
+
framelen[0] = mpeg4_frame_header(go, buf, 0, PFRAME);
i = 368;
framelen[1] = mpeg4_frame_header(go, buf + i, 0, BFRAME_PRE);
@@ -1582,12 +1575,9 @@ int go7007_construct_fw_image(struct go7007 *go, u8
**fw, int *fwlen)
return -1;
}
code = kzalloc(codespace * 2, GFP_KERNEL);
- if (code == NULL) {
- dev_err(go->dev,
- "unable to allocate %d bytes for firmware
construction\n",
- codespace * 2);
+ if (code == NULL)
goto fw_failed;
- }
+
src = (__le16 *)fw_entry->data;
srclen = fw_entry->size / 2;
while (srclen >= 2) {
diff --git a/drivers/staging/media/go7007/s2250-loader.c
b/drivers/staging/media/go7007/s2250-loader.c
index f57eb3b..72e5175 100644
--- a/drivers/staging/media/go7007/s2250-loader.c
+++ b/drivers/staging/media/go7007/s2250-loader.c
@@ -81,10 +81,9 @@ static int s2250loader_probe(struct usb_interface *interface,
/* Allocate dev data structure */
s = kmalloc(sizeof(device_extension_t), GFP_KERNEL);
- if (s == NULL) {
- dev_err(&interface->dev, "Out of memory\n");
+ if (s == NULL)
goto failed;
- }
+
s2250_dev_table[minor] = s;
dev_info(&interface->dev,
diff --git a/drivers/staging/media/lirc/lirc_imon.c
b/drivers/staging/media/lirc/lirc_imon.c
index 343c622..0a2c45d 100644
--- a/drivers/staging/media/lirc/lirc_imon.c
+++ b/drivers/staging/media/lirc/lirc_imon.c
@@ -744,7 +744,6 @@ static int imon_probe(struct usb_interface *interface,
context = kzalloc(sizeof(struct imon_context), GFP_KERNEL);
if (!context) {
- dev_err(dev, "%s: kzalloc failed for context\n", __func__);
alloc_status = 1;
goto alloc_status_switch;
}
@@ -826,13 +825,11 @@ static int imon_probe(struct usb_interface *interface,
driver = kzalloc(sizeof(struct lirc_driver), GFP_KERNEL);
if (!driver) {
- dev_err(dev, "%s: kzalloc failed for lirc_driver\n", __func__);
alloc_status = 2;
goto alloc_status_switch;
}
rbuf = kmalloc(sizeof(struct lirc_b
[PATCH] em28xx: bump driver version to 0.2.0
The em28xx driver has changed much, especially since kernel 3.8.
So it's time to bump the driver version.
Changes since kernel 3.8:
- converted the driver to videobuf2
- converted the driver to the v4l2-ctrl framework
- added USB bulk transfer support
- use USB bulk transfers by default for webcams (allows streaming from multiple
devices at the same time)
- added image quality bridge controls: contrast, brightness, saturation, blue
balance, red balance, sharpness
- removed dependency from module ir-kbd-i2c
- cleaned up the frame data processing code
- removed some unused/obsolete code
- made remote controls of devices with external (i2c) receiver/decoder work
again
- fixed audio over USB for device "Terratec Cinergy 250"
- several v4l2 compliance fixes and improvements (including fixes for ioctls
enabling/disabling)
- lots of further bug fixes and code improvements
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-video.c |2 +-
1 Datei geändert, 1 Zeile hinzugefügt(+), 1 Zeile entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 48b937d..93fc620 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -52,7 +52,7 @@
#define DRIVER_DESC "Empia em28xx based USB video device driver"
-#define EM28XX_VERSION "0.1.3"
+#define EM28XX_VERSION "0.2.0"
#define em28xx_videodbg(fmt, arg...) do {\
if (video_debug) \
--
1.7.10.4
--
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] em28xx: fix spacing and some comments in em28xx.h
Signed-off-by: Frank Schäfer --- drivers/media/usb/em28xx/em28xx.h | 95 +++-- 1 Datei geändert, 37 Zeilen hinzugefügt(+), 58 Zeilen entfernt(-) diff --git a/drivers/media/usb/em28xx/em28xx.h b/drivers/media/usb/em28xx/em28xx.h index a3c08ae..4160a2a 100644 --- a/drivers/media/usb/em28xx/em28xx.h +++ b/drivers/media/usb/em28xx/em28xx.h @@ -42,28 +42,28 @@ #include "em28xx-reg.h" /* Boards supported by driver */ -#define EM2800_BOARD_UNKNOWN 0 -#define EM2820_BOARD_UNKNOWN 1 -#define EM2820_BOARD_TERRATEC_CINERGY_250 2 -#define EM2820_BOARD_PINNACLE_USB_23 -#define EM2820_BOARD_HAUPPAUGE_WINTV_USB_2 4 -#define EM2820_BOARD_MSI_VOX_USB_2 5 -#define EM2800_BOARD_TERRATEC_CINERGY_200 6 -#define EM2800_BOARD_LEADTEK_WINFAST_USBII 7 -#define EM2800_BOARD_KWORLD_USB2800 8 -#define EM2820_BOARD_PINNACLE_DVC_90 9 -#define EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900 10 -#define EM2880_BOARD_TERRATEC_HYBRID_XS11 -#define EM2820_BOARD_KWORLD_PVRTV2800RF12 -#define EM2880_BOARD_TERRATEC_PRODIGY_XS 13 -#define EM2820_BOARD_PROLINK_PLAYTV_USB2 14 -#define EM2800_BOARD_VGEAR_POCKETTV 15 -#define EM2883_BOARD_HAUPPAUGE_WINTV_HVR_950 16 -#define EM2880_BOARD_PINNACLE_PCTV_HD_PRO 17 -#define EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900_R218 -#define EM2860_BOARD_SAA711X_REFERENCE_DESIGN 19 -#define EM2880_BOARD_AMD_ATI_TV_WONDER_HD_600 20 -#define EM2800_BOARD_GRABBEEX_USB2800 21 +#define EM2800_BOARD_UNKNOWN 0 +#define EM2820_BOARD_UNKNOWN 1 +#define EM2820_BOARD_TERRATEC_CINERGY_2502 +#define EM2820_BOARD_PINNACLE_USB_2 3 +#define EM2820_BOARD_HAUPPAUGE_WINTV_USB_2 4 +#define EM2820_BOARD_MSI_VOX_USB_2 5 +#define EM2800_BOARD_TERRATEC_CINERGY_2006 +#define EM2800_BOARD_LEADTEK_WINFAST_USBII 7 +#define EM2800_BOARD_KWORLD_USB2800 8 +#define EM2820_BOARD_PINNACLE_DVC_90 9 +#define EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900 10 +#define EM2880_BOARD_TERRATEC_HYBRID_XS 11 +#define EM2820_BOARD_KWORLD_PVRTV2800RF 12 +#define EM2880_BOARD_TERRATEC_PRODIGY_XS 13 +#define EM2820_BOARD_PROLINK_PLAYTV_USB2 14 +#define EM2800_BOARD_VGEAR_POCKETTV 15 +#define EM2883_BOARD_HAUPPAUGE_WINTV_HVR_950 16 +#define EM2880_BOARD_PINNACLE_PCTV_HD_PRO17 +#define EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900_R2 18 +#define EM2860_BOARD_SAA711X_REFERENCE_DESIGN19 +#define EM2880_BOARD_AMD_ATI_TV_WONDER_HD_60020 +#define EM2800_BOARD_GRABBEEX_USB280021 #define EM2750_BOARD_UNKNOWN 22 #define EM2750_BOARD_DLCW_13023 #define EM2820_BOARD_DLINK_USB_TV24 @@ -99,35 +99,35 @@ #define EM2882_BOARD_KWORLD_VS_DVBT 54 #define EM2882_BOARD_TERRATEC_HYBRID_XS 55 #define EM2882_BOARD_PINNACLE_HYBRID_PRO_330E56 -#define EM2883_BOARD_KWORLD_HYBRID_330U 57 +#define EM2883_BOARD_KWORLD_HYBRID_330U 57 #define EM2820_BOARD_COMPRO_VIDEOMATE_FORYOU 58 #define EM2883_BOARD_HAUPPAUGE_WINTV_HVR_850 60 #define EM2820_BOARD_PROLINK_PLAYTV_BOX4_USB261 #define EM2820_BOARD_GADMEI_TVR200 62 -#define EM2860_BOARD_KAIOMY_TVNPC_U2 63 -#define EM2860_BOARD_EASYCAP 64 +#define EM2860_BOARD_KAIOMY_TVNPC_U2 63 +#define EM2860_BOARD_EASYCAP 64 #define EM2820_BOARD_IODATA_GVMVP_SZ 65 #define EM2880_BOARD_EMPIRE_DUAL_TV 66 #define EM2860_BOARD_TERRATEC_GRABBY 67 #define EM2860_BOARD_TERRATEC_AV350 68 #define EM2882_BOARD_KWORLD_ATSC_315U69 #define EM2882_BOARD_EVGA_INDTUBE70 -#define EM2820_BOARD_SILVERCREST_WEBCAM 71 -#define EM2861_BOARD_GADMEI_UTV330PLUS 72 -#define EM2870_BOARD_REDDO_DVB_C_USB_BOX 73 +#define EM2820_BOARD_SILVERCREST_WEBCAM 71 +#define EM2861_BOARD_GADMEI_UTV330PLUS 72 +#define EM2870_BOARD_REDDO_DVB_C_USB_BOX 73 #define EM2800_BOARD_VC211A 74 #define EM2882_BOARD_DIKOM_DK300 75 #define EM2870_BOARD_KWORLD_A340 76 #define EM2874_BOARD_LEADERSHIP_ISDBT77 -#define EM28174_BOARD_PCTV_290E 78 +#define EM28174_BOARD_PCTV_290E 78 #define EM2884_BOARD_TERRATEC_H5 79 -#define EM28174_BOARD_PCTV_460E 80 +#define EM28174_BOARD_PCTV_460E 80 #define EM2884_BOARD_HAUPPAUGE_WINTV_HVR_930C81 #define EM2884_BOARD_CINERGY_HTC_STICK 82 -#define EM2860_BOARD_HT_VIDBOX_NW03 83 -#define EM2874_BOARD_MA
[PATCH] em28xx: remove some obsolete function declarations
Signed-off-by: Frank Schäfer --- drivers/media/usb/em28xx/em28xx.h |8 1 Datei geändert, 8 Zeilen entfernt(-) diff --git a/drivers/media/usb/em28xx/em28xx.h b/drivers/media/usb/em28xx/em28xx.h index 7dc27b5..a3c08ae 100644 --- a/drivers/media/usb/em28xx/em28xx.h +++ b/drivers/media/usb/em28xx/em28xx.h @@ -654,11 +654,6 @@ int em28xx_i2c_register(struct em28xx *dev); int em28xx_i2c_unregister(struct em28xx *dev); /* Provided by em28xx-core.c */ - -u32 em28xx_request_buffers(struct em28xx *dev, u32 count); -void em28xx_queue_unusedframes(struct em28xx *dev); -void em28xx_release_buffers(struct em28xx *dev); - int em28xx_read_reg_req_len(struct em28xx *dev, u8 req, u16 reg, char *buf, int len); int em28xx_read_reg_req(struct em28xx *dev, u8 req, u16 reg); @@ -691,7 +686,6 @@ int em28xx_init_usb_xfer(struct em28xx *dev, enum em28xx_mode mode, (struct em28xx *dev, struct urb *urb)); void em28xx_uninit_usb_xfer(struct em28xx *dev, enum em28xx_mode mode); void em28xx_stop_urbs(struct em28xx *dev); -int em28xx_isoc_dvb_max_packetsize(struct em28xx *dev); int em28xx_set_mode(struct em28xx *dev, enum em28xx_mode set_mode); int em28xx_gpio_set(struct em28xx *dev, struct em28xx_reg_seq *gpio); void em28xx_wake_i2c(struct em28xx *dev); @@ -710,10 +704,8 @@ int em28xx_stop_vbi_streaming(struct vb2_queue *vq); extern const struct v4l2_ctrl_ops em28xx_ctrl_ops; /* Provided by em28xx-cards.c */ -extern int em2800_variant_detect(struct usb_device *udev, int model); extern struct em28xx_board em28xx_boards[]; extern struct usb_device_id em28xx_id_table[]; -extern const unsigned int em28xx_bcount; int em28xx_tuner_callback(void *ptr, int component, int command, int arg); void em28xx_release_resources(struct em28xx *dev); -- 1.7.10.4 -- 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 4/4] em28xx: add image quality bridge controls
Add the image quality bridge controls contrast, brightness, saturation,
blue balance, red balance and sharpness.
These controls are enabled only if no subdevice provides them.
Tested with the following devices:
"Terratec Cinergy 200 USB"
"Hauppauge HVR-900"
"SilverCrest 1.3MPix webcam"
"Hauppauge WinTV USB2"
"Speedlink VAD Laplace webcam"
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-cards.c |7 +---
drivers/media/usb/em28xx/em28xx-video.c | 58 +--
2 Dateien geändert, 57 Zeilen hinzugefügt(+), 8 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-cards.c
index 0a5aa62..96de831 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3089,7 +3089,7 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
return retval;
}
- v4l2_ctrl_handler_init(hdl, 4);
+ v4l2_ctrl_handler_init(hdl, 8);
dev->v4l2_dev.ctrl_handler = hdl;
/* register i2c bus */
@@ -3158,11 +3158,6 @@ static int em28xx_init_dev(struct em28xx *dev, struct
usb_device *udev,
msleep(3);
}
- v4l2_ctrl_handler_setup(&dev->ctrl_handler);
- retval = dev->ctrl_handler.error;
- if (retval)
- goto fail;
-
retval = em28xx_register_analog_devices(dev);
if (retval < 0) {
goto fail;
diff --git a/drivers/media/usb/em28xx/em28xx-video.c
b/drivers/media/usb/em28xx/em28xx-video.c
index 86fd907..48b937d 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -782,17 +782,38 @@ void em28xx_ctrl_notify(struct v4l2_ctrl *ctrl, void
*priv)
static int em28xx_s_ctrl(struct v4l2_ctrl *ctrl)
{
struct em28xx *dev = container_of(ctrl->handler, struct em28xx,
ctrl_handler);
+ int ret = -EINVAL;
switch (ctrl->id) {
case V4L2_CID_AUDIO_MUTE:
dev->mute = ctrl->val;
+ ret = em28xx_audio_analog_set(dev);
break;
case V4L2_CID_AUDIO_VOLUME:
dev->volume = ctrl->val;
+ ret = em28xx_audio_analog_set(dev);
+ break;
+ case V4L2_CID_CONTRAST:
+ ret = em28xx_write_reg(dev, EM28XX_R20_YGAIN, ctrl->val);
+ break;
+ case V4L2_CID_BRIGHTNESS:
+ ret = em28xx_write_reg(dev, EM28XX_R21_YOFFSET, ctrl->val);
+ break;
+ case V4L2_CID_SATURATION:
+ ret = em28xx_write_reg(dev, EM28XX_R22_UVGAIN, ctrl->val);
+ break;
+ case V4L2_CID_BLUE_BALANCE:
+ ret = em28xx_write_reg(dev, EM28XX_R23_UOFFSET, ctrl->val);
+ break;
+ case V4L2_CID_RED_BALANCE:
+ ret = em28xx_write_reg(dev, EM28XX_R24_VOFFSET, ctrl->val);
+ break;
+ case V4L2_CID_SHARPNESS:
+ ret = em28xx_write_reg(dev, EM28XX_R25_SHARPNESS, ctrl->val);
break;
}
- return em28xx_audio_analog_set(dev);
+ return (ret < 0) ? ret : 0;
}
const struct v4l2_ctrl_ops em28xx_ctrl_ops = {
@@ -1784,9 +1805,42 @@ int em28xx_register_analog_devices(struct em28xx *dev)
(EM28XX_XCLK_AUDIO_UNMUTE | val));
em28xx_set_outfmt(dev);
- em28xx_colorlevels_set_default(dev);
em28xx_compression_disable(dev);
+ /* Add image controls */
+ /* NOTE: at this point, the subdevices are already registered, so bridge
+* controls are only added/enabled when no subdevice provides them */
+ if (NULL == v4l2_ctrl_find(&dev->ctrl_handler, V4L2_CID_CONTRAST))
+ v4l2_ctrl_new_std(&dev->ctrl_handler, &em28xx_ctrl_ops,
+ V4L2_CID_CONTRAST,
+ 0, 0x1f, 1, CONTRAST_DEFAULT);
+ if (NULL == v4l2_ctrl_find(&dev->ctrl_handler, V4L2_CID_BRIGHTNESS))
+ v4l2_ctrl_new_std(&dev->ctrl_handler, &em28xx_ctrl_ops,
+ V4L2_CID_BRIGHTNESS,
+ -0x80, 0x7f, 1, BRIGHTNESS_DEFAULT);
+ if (NULL == v4l2_ctrl_find(&dev->ctrl_handler, V4L2_CID_SATURATION))
+ v4l2_ctrl_new_std(&dev->ctrl_handler, &em28xx_ctrl_ops,
+ V4L2_CID_SATURATION,
+ 0, 0x1f, 1, SATURATION_DEFAULT);
+ if (NULL == v4l2_ctrl_find(&dev->ctrl_handler, V4L2_CID_BLUE_BALANCE))
+ v4l2_ctrl_new_std(&dev->ctrl_handler, &em28xx_ctrl_ops,
+ V4L2_CID_BLUE_BALANCE,
+ -0x30, 0x30, 1, BLUE_BALANCE_DEFAULT);
+ if (NULL == v4l2_ctrl_find(&dev->ctrl_handler, V4L2_CID_RED_BALANCE))
+ v4l2_ctrl_new_std(&dev->ctrl_handler, &em28xx_ctrl_ops,
+ V4L2_CID_RED_BALANCE,
+
[PATCH 3/4] em28xx: introduce #defines for the image quality default settings
The image quality default values will be used in at least two different places
and by using #defines we make sure that they are always consistent.
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx-core.c | 12 ++--
drivers/media/usb/em28xx/em28xx-reg.h | 23 +--
2 Dateien geändert, 23 Zeilen hinzugefügt(+), 12 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx-core.c
b/drivers/media/usb/em28xx/em28xx-core.c
index 26d2499..b2dcb3d 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -607,12 +607,12 @@ EXPORT_SYMBOL_GPL(em28xx_audio_setup);
int em28xx_colorlevels_set_default(struct em28xx *dev)
{
- em28xx_write_reg(dev, EM28XX_R20_YGAIN, 0x10); /* contrast */
- em28xx_write_reg(dev, EM28XX_R21_YOFFSET, 0x00);/* brightness */
- em28xx_write_reg(dev, EM28XX_R22_UVGAIN, 0x10); /* saturation */
- em28xx_write_reg(dev, EM28XX_R23_UOFFSET, 0x00);
- em28xx_write_reg(dev, EM28XX_R24_VOFFSET, 0x00);
- em28xx_write_reg(dev, EM28XX_R25_SHARPNESS, 0x00);
+ em28xx_write_reg(dev, EM28XX_R20_YGAIN, CONTRAST_DEFAULT);
+ em28xx_write_reg(dev, EM28XX_R21_YOFFSET, BRIGHTNESS_DEFAULT);
+ em28xx_write_reg(dev, EM28XX_R22_UVGAIN, SATURATION_DEFAULT);
+ em28xx_write_reg(dev, EM28XX_R23_UOFFSET, BLUE_BALANCE_DEFAULT);
+ em28xx_write_reg(dev, EM28XX_R24_VOFFSET, RED_BALANCE_DEFAULT);
+ em28xx_write_reg(dev, EM28XX_R25_SHARPNESS, SHARPNESS_DEFAULT);
em28xx_write_reg(dev, EM28XX_R14_GAMMA, 0x20);
em28xx_write_reg(dev, EM28XX_R15_RGAIN, 0x20);
diff --git a/drivers/media/usb/em28xx/em28xx-reg.h
b/drivers/media/usb/em28xx/em28xx-reg.h
index 0a3cb04..1e369ba 100644
--- a/drivers/media/usb/em28xx/em28xx-reg.h
+++ b/drivers/media/usb/em28xx/em28xx-reg.h
@@ -120,12 +120,23 @@
#define EM28XX_R1E_CWIDTH 0x1e
#define EM28XX_R1F_CHEIGHT 0x1f
-#define EM28XX_R20_YGAIN 0x20
-#define EM28XX_R21_YOFFSET 0x21
-#define EM28XX_R22_UVGAIN 0x22
-#define EM28XX_R23_UOFFSET 0x23
-#define EM28XX_R24_VOFFSET 0x24
-#define EM28XX_R25_SHARPNESS 0x25
+#define EM28XX_R20_YGAIN 0x20 /* contrast [0:4] */
+#define CONTRAST_DEFAULT 0x10
+
+#define EM28XX_R21_YOFFSET 0x21 /* brightness */ /* signed */
+#define BRIGHTNESS_DEFAULT 0x00
+
+#define EM28XX_R22_UVGAIN 0x22 /* saturation [0:4] */
+#define SATURATION_DEFAULT 0x10
+
+#define EM28XX_R23_UOFFSET 0x23 /* blue balance */ /* signed */
+#define BLUE_BALANCE_DEFAULT 0x00
+
+#define EM28XX_R24_VOFFSET 0x24 /* red balance */ /* signed */
+#define RED_BALANCE_DEFAULT 0x00
+
+#define EM28XX_R25_SHARPNESS 0x25 /* sharpness [0:4] */
+#define SHARPNESS_DEFAULT0x00
#define EM28XX_R26_COMPR 0x26
#define EM28XX_R27_OUTFMT 0x27
--
1.7.10.4
--
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 2/4] em28xx: remove unused ac97 v4l2_ctrl_handler
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx.h |2 --
1 Datei geändert, 2 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx.h
b/drivers/media/usb/em28xx/em28xx.h
index 6a9e3e1..7dc27b5 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -491,8 +491,6 @@ struct em28xx {
struct v4l2_device v4l2_dev;
struct v4l2_ctrl_handler ctrl_handler;
- /* provides ac97 mute and volume overrides */
- struct v4l2_ctrl_handler ac97_ctrl_handler;
struct em28xx_board board;
/* Webcam specific fields */
--
1.7.10.4
--
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 1/4] em28xx: remove unused image quality control functions
Signed-off-by: Frank Schäfer
---
drivers/media/usb/em28xx/em28xx.h | 66 -
1 Datei geändert, 66 Zeilen entfernt(-)
diff --git a/drivers/media/usb/em28xx/em28xx.h
b/drivers/media/usb/em28xx/em28xx.h
index 5f0b2c5..6a9e3e1 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -744,72 +744,6 @@ static inline int em28xx_compression_disable(struct em28xx
*dev)
return em28xx_write_reg(dev, EM28XX_R26_COMPR, 0x00);
}
-static inline int em28xx_contrast_get(struct em28xx *dev)
-{
- return em28xx_read_reg(dev, EM28XX_R20_YGAIN) & 0x1f;
-}
-
-static inline int em28xx_brightness_get(struct em28xx *dev)
-{
- return em28xx_read_reg(dev, EM28XX_R21_YOFFSET);
-}
-
-static inline int em28xx_saturation_get(struct em28xx *dev)
-{
- return em28xx_read_reg(dev, EM28XX_R22_UVGAIN) & 0x1f;
-}
-
-static inline int em28xx_u_balance_get(struct em28xx *dev)
-{
- return em28xx_read_reg(dev, EM28XX_R23_UOFFSET);
-}
-
-static inline int em28xx_v_balance_get(struct em28xx *dev)
-{
- return em28xx_read_reg(dev, EM28XX_R24_VOFFSET);
-}
-
-static inline int em28xx_gamma_get(struct em28xx *dev)
-{
- return em28xx_read_reg(dev, EM28XX_R14_GAMMA) & 0x3f;
-}
-
-static inline int em28xx_contrast_set(struct em28xx *dev, s32 val)
-{
- u8 tmp = (u8) val;
- return em28xx_write_regs(dev, EM28XX_R20_YGAIN, &tmp, 1);
-}
-
-static inline int em28xx_brightness_set(struct em28xx *dev, s32 val)
-{
- u8 tmp = (u8) val;
- return em28xx_write_regs(dev, EM28XX_R21_YOFFSET, &tmp, 1);
-}
-
-static inline int em28xx_saturation_set(struct em28xx *dev, s32 val)
-{
- u8 tmp = (u8) val;
- return em28xx_write_regs(dev, EM28XX_R22_UVGAIN, &tmp, 1);
-}
-
-static inline int em28xx_u_balance_set(struct em28xx *dev, s32 val)
-{
- u8 tmp = (u8) val;
- return em28xx_write_regs(dev, EM28XX_R23_UOFFSET, &tmp, 1);
-}
-
-static inline int em28xx_v_balance_set(struct em28xx *dev, s32 val)
-{
- u8 tmp = (u8) val;
- return em28xx_write_regs(dev, EM28XX_R24_VOFFSET, &tmp, 1);
-}
-
-static inline int em28xx_gamma_set(struct em28xx *dev, s32 val)
-{
- u8 tmp = (u8) val;
- return em28xx_write_regs(dev, EM28XX_R14_GAMMA, &tmp, 1);
-}
-
/*FIXME: maxw should be dependent of alt mode */
static inline unsigned int norm_maxw(struct em28xx *dev)
{
--
1.7.10.4
--
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 0/4] em28xx: add image quality bridge controls
The first two patches remove unused code. The third patch makes sure that the same image quality default settings are used everywhere in the code. The fourth patch finally adds the following image quality bridge controls: - contrast - brightness - saturation - blue balance - red balance - sharpness Tested with the following devices: "Terratec Cinergy 200 USB" "Hauppauge HVR-900" "SilverCrest 1.3MPix webcam" "Hauppauge WinTV USB2" "Speedlink VAD Laplace webcam" Frank Schäfer (4): em28xx: remove unused image quality control functions em28xx: remove unused ac97 v4l2_ctrl_handler em28xx: introduce #defines for the image quality default settings em28xx: add image quality bridge controls drivers/media/usb/em28xx/em28xx-cards.c |7 +--- drivers/media/usb/em28xx/em28xx-core.c | 12 +++--- drivers/media/usb/em28xx/em28xx-reg.h | 23 --- drivers/media/usb/em28xx/em28xx-video.c | 58 +- drivers/media/usb/em28xx/em28xx.h | 68 --- 5 Dateien geändert, 80 Zeilen hinzugefügt(+), 88 Zeilen entfernt(-) -- 1.7.10.4 -- 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: [REVIEWv2 PATCH 04/19] bttv: remove g/s_audio since there is only one audio input.
Am 11.02.2013 15:22, schrieb Hans Verkuil:
> On Sun February 10 2013 21:22:41 Frank Schäfer wrote:
>> Hmm... G/S_AUDIO is also used to query/set the capabilities and the mode
>> of an input, which IMHO makes sense even if the input is the only one
>> the device has ?
> You are right, but there are problems with the implementation in this driver.
> First of all, there is no ENUMAUDIO ioctl implemented, so applications were
> never able to enumerate the audio inputs.
Argh, ok.
> Now, it is possible to add this (and I have done this in this tree:
> http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/bttv2).
> However, the card definitions are unreliable with respect to the number of
> audio inputs. So you may end up with a driver reporting incorrect information.
>
> I tried it in the bttv2 branch and frankly it became rather messy.
>
> Given the fact that there was never an ENUMAUDIO ioctl in the first place
> I decided that it was better not to have these ioctls at all. Also, the
> V4L2_CAP_AUDIO was never set, and they are incorrect anyway for boards that
> do not have an audio input at all (common for surveillance boards).
I checked your bttv2 branch and it's looking not that bad !
If I'm understanding correctly, your main concern is, that the board
information isn't reliable/correct ?
Hmm... it seems that (although commented out) nearly all boards have the
.audio_inputs field set, which leaves rooms for hope...
OTOH, even if the board info about the audio inputs is wrong, this
wouldn't have any consequences for the video input, right ?
The additional audio inputs just won't work. And that's something we can
fix step by step (if anybody cares ;) ).
So there is no risk of regressions and a good chance to get a missing
functionality work.
In that case I would vote for adding ENUM/G/S_AUDIO.
>
> There are other drivers as well that do not implement this, so applications
> cannot rely on this ioctl being present.
Sure, they _shouldn't_.
> I will update the commit message before I do the pull request, though. It
> should be extended with the information above.
That's probably the best solution for 3.9.
Regards,
Frank
>
> Regards,
>
> Hans
>
>> Don't you think that it's also somehow inconsistent, because for the
>> video inputs (G/S_INPUT) the spec says:
>> "This ioctl will fail only when there are no video inputs, returning
>> EINVAL." ?
>>
>>
>> Regards,
>> Frank
>>
>>
>>
>> Am 10.02.2013 13:49, schrieb Hans Verkuil:
>>> From: Hans Verkuil
>>>
>>> Signed-off-by: Hans Verkuil
>>> ---
>>> drivers/media/pci/bt8xx/bttv-driver.c | 19 ---
>>> 1 file changed, 19 deletions(-)
>>>
>>> diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
>>> b/drivers/media/pci/bt8xx/bttv-driver.c
>>> index 6e61dbd..a02c031 100644
>>> --- a/drivers/media/pci/bt8xx/bttv-driver.c
>>> +++ b/drivers/media/pci/bt8xx/bttv-driver.c
>>> @@ -3138,23 +3138,6 @@ static int bttv_s_crop(struct file *file, void *f,
>>> const struct v4l2_crop *crop)
>>> return 0;
>>> }
>>>
>>> -static int bttv_g_audio(struct file *file, void *priv, struct v4l2_audio
>>> *a)
>>> -{
>>> - if (unlikely(a->index))
>>> - return -EINVAL;
>>> -
>>> - strcpy(a->name, "audio");
>>> - return 0;
>>> -}
>>> -
>>> -static int bttv_s_audio(struct file *file, void *priv, const struct
>>> v4l2_audio *a)
>>> -{
>>> - if (unlikely(a->index))
>>> - return -EINVAL;
>>> -
>>> - return 0;
>>> -}
>>> -
>>> static ssize_t bttv_read(struct file *file, char __user *data,
>>> size_t count, loff_t *ppos)
>>> {
>>> @@ -3390,8 +3373,6 @@ static const struct v4l2_ioctl_ops bttv_ioctl_ops = {
>>> .vidioc_g_fmt_vbi_cap = bttv_g_fmt_vbi_cap,
>>> .vidioc_try_fmt_vbi_cap = bttv_try_fmt_vbi_cap,
>>> .vidioc_s_fmt_vbi_cap = bttv_s_fmt_vbi_cap,
>>> - .vidioc_g_audio = bttv_g_audio,
>>> - .vidioc_s_audio = bttv_s_audio,
>>> .vidioc_cropcap = bttv_cropcap,
>>> .vidioc_reqbufs = bttv_reqbufs,
>>> .vidioc_querybuf= bttv_querybuf,
>> --
>> 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: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
On Mon, Feb 11, 2013 at 2:21 PM, Hans Verkuil wrote: > > That doesn't make sense either. Arvydas, it worked fine for you before, right? > That is, if you use e.g. v3.8-rc7 then your picture is the right side up. > It is upside down using any v3.7.x or v3.8-rc7. I didn't pay attention in the older versions, but I am aware of this issue since pre-v3. On Mon, Feb 11, 2013 at 2:41 PM, Hans de Goede wrote: > > Arvydas, can you please run "sudo dmidecode > dmi.log", and send me or > Hans V. the generated dmi.log file? Then we can add your laptop to the > upside-down model list. > $ sudo dmidecode # dmidecode 2.11 SMBIOS 2.4 present. 37 structures occupying 1499 bytes. Table at 0x000E5020. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: 305 Release Date: 02/15/2007 Address: 0xF Runtime Size: 64 kB ROM Size: 512 kB Characteristics: ISA is supported PCI is supported PC Card (PCMCIA) is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported EDD is supported 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported Smart battery is supported BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported BIOS Revision: 1.124 Firmware Revision: 168.153 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: ASUSTeK Computer Inc. Product Name: F3JC Version: 1.0 Serial Number: SSN12345678901234567 UUID: F13181DB-43CD-9AAD-CE00-0018F338B599 Wake-up Type: Power Switch SKU Number: Family: Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: ASUSTeK Computer Inc. Product Name: F3JC Version: 1.0 Serial Number: BSN12345678901234567 Asset Tag: ATN12345678901234567 Features: Board is a hosting board Board requires at least one daughter board Board is replaceable Location In Chassis: MIDDLE Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: ASUSTeK Computer Inc. Type: Notebook Lock: Not Present Version: Serial Number: Asset Tag: Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x Height: Unspecified Number Of Power Cords: 1 Contained Elements: 0 Handle 0x0004, DMI type 4, 35 bytes Processor Information Socket Designation: Socket 478 Type: Central Processor Family: Other Manufacturer: Intel ID: F6 06 00 00 FF FB EB BF Signature: Type 0, Family 6, Model 15, Stepping 6 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported) PBE (Pe
Re: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
I think the driver is not up to standard: look at the error messages. And there are a lot of "to do" because of lack of documentation. On Mon, Feb 11, 2013 at 4:55 PM, Hans de Goede wrote: > Hi, > > > On 02/11/2013 02:51 PM, Hans Verkuil wrote: >> >> On Mon February 11 2013 14:41:08 Hans de Goede wrote: >>> >>> Hi, >>> >>> On 02/11/2013 02:21 PM, Hans Verkuil wrote: On Mon February 11 2013 14:08:44 Hans de Goede wrote: > > Hi, > > Subject: stk-webcam: the initial hflip and vflip setup was the wrong > way around > > No it is not. You are right, that patch makes no sense. It was a long day :-) > On 02/10/2013 06:52 PM, Hans Verkuil wrote: >> >> From: Hans Verkuil >> >> This resulted in an upside-down picture. > > > No it does not, the laptop having an upside down mounted camera and not > being > in the dmi-table is what causes an upside down picture. For a non > upside > down camera (so no dmi-match) hflip and vflip should be 0. > > The fix for the upside-down-ness Arvydas Sidorenko reported would be to > add his laptop to the upside down table. That doesn't make sense either. Arvydas, it worked fine for you before, right? >>> >>> >>> Yes, it probably worked before, but not with... >>> That is, if you use e.g. v3.8-rc7 then your picture is the right side up. >>> >>> >>> 3.8 will show it upside down for Arvydas >>> >>> The story goes likes this: >>> >>> 1) Once upon a time the stkwebcam driver was written >>> 2) The webcam in question was used mostly in Asus laptop models, >>> including >>> the laptop of the original author of the driver, and in these models, in >>> typical Asus fashion (see the long long list for uvc cams inside >>> v4l-utils), >>> they mounted the webcam-module the wrong way up. So the hflip and vflip >>> module options were given a default value of 1 (the correct value for >>> upside down mounted models) >>> >>> 3) Years later I got a bug report from a user with a laptop with >>> stkwebcam, >>> where the module was actually mounted the right way up, and thus showed >>> upside >>> down under Linux. So now I was facing the choice of 2 options: >>> a) Add a not-upside-down list to stkwebcam, which overrules the default >>> b) Do it like all the other drivers do, and make the default right for >>> cams mounted the proper way and add an upside-down model list, with >>> models >>> where we need to flip-by-default. >>> >>> Despite knowing that going b) would cause a period of pain where we were >>> building the table (ie what we're discussing now) I opted to go for >>> option >>> b), since a) is just too ugly, and worse different from how every other >>> driver does it leading to confusion in the long run. >>> >>> IOW this is entirely my fault, and I take full responsibility for it. >> >> >> Ah, OK. Now it makes sense. I wasn't aware of this history and it >> (clearly) >> confused me greatly. >> >> Can you perhaps provide me with a patch that adds some comments to the >> source >> explaining this. And in particular with which kernel this change took >> place? > > > Feel free to copy my 1) - 3) From above to a comment, step 3 landed in > kernel 3.6 > (you doing it seems better then me doing a patch conflicting with your > patchset) > > >> The next time some poor sod (e.g. me) has to work on this the comments >> should >> explain this history. > > > Ack. > > > Regards, > > Hans > -- > 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: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
Hi, On 02/11/2013 02:51 PM, Hans Verkuil wrote: On Mon February 11 2013 14:41:08 Hans de Goede wrote: Hi, On 02/11/2013 02:21 PM, Hans Verkuil wrote: On Mon February 11 2013 14:08:44 Hans de Goede wrote: Hi, Subject: stk-webcam: the initial hflip and vflip setup was the wrong way around No it is not. You are right, that patch makes no sense. It was a long day :-) On 02/10/2013 06:52 PM, Hans Verkuil wrote: From: Hans Verkuil This resulted in an upside-down picture. No it does not, the laptop having an upside down mounted camera and not being in the dmi-table is what causes an upside down picture. For a non upside down camera (so no dmi-match) hflip and vflip should be 0. The fix for the upside-down-ness Arvydas Sidorenko reported would be to add his laptop to the upside down table. That doesn't make sense either. Arvydas, it worked fine for you before, right? Yes, it probably worked before, but not with... That is, if you use e.g. v3.8-rc7 then your picture is the right side up. 3.8 will show it upside down for Arvydas The story goes likes this: 1) Once upon a time the stkwebcam driver was written 2) The webcam in question was used mostly in Asus laptop models, including the laptop of the original author of the driver, and in these models, in typical Asus fashion (see the long long list for uvc cams inside v4l-utils), they mounted the webcam-module the wrong way up. So the hflip and vflip module options were given a default value of 1 (the correct value for upside down mounted models) 3) Years later I got a bug report from a user with a laptop with stkwebcam, where the module was actually mounted the right way up, and thus showed upside down under Linux. So now I was facing the choice of 2 options: a) Add a not-upside-down list to stkwebcam, which overrules the default b) Do it like all the other drivers do, and make the default right for cams mounted the proper way and add an upside-down model list, with models where we need to flip-by-default. Despite knowing that going b) would cause a period of pain where we were building the table (ie what we're discussing now) I opted to go for option b), since a) is just too ugly, and worse different from how every other driver does it leading to confusion in the long run. IOW this is entirely my fault, and I take full responsibility for it. Ah, OK. Now it makes sense. I wasn't aware of this history and it (clearly) confused me greatly. Can you perhaps provide me with a patch that adds some comments to the source explaining this. And in particular with which kernel this change took place? Feel free to copy my 1) - 3) From above to a comment, step 3 landed in kernel 3.6 (you doing it seems better then me doing a patch conflicting with your patchset) The next time some poor sod (e.g. me) has to work on this the comments should explain this history. Ack. Regards, Hans -- 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: [REVIEWv2 PATCH 04/19] bttv: remove g/s_audio since there is only one audio input.
On Sun February 10 2013 21:22:41 Frank Schäfer wrote:
>
> Hmm... G/S_AUDIO is also used to query/set the capabilities and the mode
> of an input, which IMHO makes sense even if the input is the only one
> the device has ?
You are right, but there are problems with the implementation in this driver.
First of all, there is no ENUMAUDIO ioctl implemented, so applications were
never able to enumerate the audio inputs.
Now, it is possible to add this (and I have done this in this tree:
http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/bttv2).
However, the card definitions are unreliable with respect to the number of
audio inputs. So you may end up with a driver reporting incorrect information.
I tried it in the bttv2 branch and frankly it became rather messy.
Given the fact that there was never an ENUMAUDIO ioctl in the first place
I decided that it was better not to have these ioctls at all. Also, the
V4L2_CAP_AUDIO was never set, and they are incorrect anyway for boards that
do not have an audio input at all (common for surveillance boards).
There are other drivers as well that do not implement this, so applications
cannot rely on this ioctl being present.
I will update the commit message before I do the pull request, though. It
should be extended with the information above.
Regards,
Hans
> Don't you think that it's also somehow inconsistent, because for the
> video inputs (G/S_INPUT) the spec says:
> "This ioctl will fail only when there are no video inputs, returning
> EINVAL." ?
>
>
> Regards,
> Frank
>
>
>
> Am 10.02.2013 13:49, schrieb Hans Verkuil:
> > From: Hans Verkuil
> >
> > Signed-off-by: Hans Verkuil
> > ---
> > drivers/media/pci/bt8xx/bttv-driver.c | 19 ---
> > 1 file changed, 19 deletions(-)
> >
> > diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
> > b/drivers/media/pci/bt8xx/bttv-driver.c
> > index 6e61dbd..a02c031 100644
> > --- a/drivers/media/pci/bt8xx/bttv-driver.c
> > +++ b/drivers/media/pci/bt8xx/bttv-driver.c
> > @@ -3138,23 +3138,6 @@ static int bttv_s_crop(struct file *file, void *f,
> > const struct v4l2_crop *crop)
> > return 0;
> > }
> >
> > -static int bttv_g_audio(struct file *file, void *priv, struct v4l2_audio
> > *a)
> > -{
> > - if (unlikely(a->index))
> > - return -EINVAL;
> > -
> > - strcpy(a->name, "audio");
> > - return 0;
> > -}
> > -
> > -static int bttv_s_audio(struct file *file, void *priv, const struct
> > v4l2_audio *a)
> > -{
> > - if (unlikely(a->index))
> > - return -EINVAL;
> > -
> > - return 0;
> > -}
> > -
> > static ssize_t bttv_read(struct file *file, char __user *data,
> > size_t count, loff_t *ppos)
> > {
> > @@ -3390,8 +3373,6 @@ static const struct v4l2_ioctl_ops bttv_ioctl_ops = {
> > .vidioc_g_fmt_vbi_cap = bttv_g_fmt_vbi_cap,
> > .vidioc_try_fmt_vbi_cap = bttv_try_fmt_vbi_cap,
> > .vidioc_s_fmt_vbi_cap = bttv_s_fmt_vbi_cap,
> > - .vidioc_g_audio = bttv_g_audio,
> > - .vidioc_s_audio = bttv_s_audio,
> > .vidioc_cropcap = bttv_cropcap,
> > .vidioc_reqbufs = bttv_reqbufs,
> > .vidioc_querybuf= bttv_querybuf,
>
> --
> 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: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
On Mon February 11 2013 14:41:08 Hans de Goede wrote: > Hi, > > On 02/11/2013 02:21 PM, Hans Verkuil wrote: > > On Mon February 11 2013 14:08:44 Hans de Goede wrote: > >> Hi, > >> > >> Subject: stk-webcam: the initial hflip and vflip setup was the wrong way > >> around > >> > >> No it is not. > > > > You are right, that patch makes no sense. It was a long day :-) > > > >> On 02/10/2013 06:52 PM, Hans Verkuil wrote: > >>> From: Hans Verkuil > >>> > >>> This resulted in an upside-down picture. > >> > >> No it does not, the laptop having an upside down mounted camera and not > >> being > >> in the dmi-table is what causes an upside down picture. For a non upside > >> down camera (so no dmi-match) hflip and vflip should be 0. > >> > >> The fix for the upside-down-ness Arvydas Sidorenko reported would be to > >> add his laptop to the upside down table. > > > > That doesn't make sense either. Arvydas, it worked fine for you before, > > right? > > Yes, it probably worked before, but not with... > > > That is, if you use e.g. v3.8-rc7 then your picture is the right side up. > > 3.8 will show it upside down for Arvydas > > The story goes likes this: > > 1) Once upon a time the stkwebcam driver was written > 2) The webcam in question was used mostly in Asus laptop models, including > the laptop of the original author of the driver, and in these models, in > typical Asus fashion (see the long long list for uvc cams inside v4l-utils), > they mounted the webcam-module the wrong way up. So the hflip and vflip > module options were given a default value of 1 (the correct value for > upside down mounted models) > > 3) Years later I got a bug report from a user with a laptop with stkwebcam, > where the module was actually mounted the right way up, and thus showed upside > down under Linux. So now I was facing the choice of 2 options: > a) Add a not-upside-down list to stkwebcam, which overrules the default > b) Do it like all the other drivers do, and make the default right for > cams mounted the proper way and add an upside-down model list, with models > where we need to flip-by-default. > > Despite knowing that going b) would cause a period of pain where we were > building the table (ie what we're discussing now) I opted to go for option > b), since a) is just too ugly, and worse different from how every other > driver does it leading to confusion in the long run. > > IOW this is entirely my fault, and I take full responsibility for it. Ah, OK. Now it makes sense. I wasn't aware of this history and it (clearly) confused me greatly. Can you perhaps provide me with a patch that adds some comments to the source explaining this. And in particular with which kernel this change took place? The next time some poor sod (e.g. me) has to work on this the comments should explain this history. > > Arvydas, can you please run "sudo dmidecode > dmi.log", and send me or > Hans V. the generated dmi.log file? Then we can add your laptop to the > upside-down model list. When I have this information I'll update my patch series and ask Arvydas to test again. Regards, Hans -- 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] block i2c tuner reads for Avermedia Twinstar in the af9035 driver
On Domingo, 10 de febrero de 2013 22:11:53 Antti Palosaari escribió:
> On 02/10/2013 09:43 PM, Jose Alberto Reguero wrote:
> > This patch block the i2c tuner reads for Avermedia Twinstar. If it's
> > needed other pids can be added.
> >
> > Signed-off-by: Jose Alberto Reguero
> >
> > diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.c
> > linux.new/drivers/media/usb/dvb-usb-v2/af9035.c
> > --- linux/drivers/media/usb/dvb-usb-v2/af9035.c 2013-01-07
> > 05:45:57.0 +0100
> > +++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.c 2013-02-08
> > 22:55:08.304089054 +0100
> > @@ -232,7 +232,11 @@ static int af9035_i2c_master_xfer(struct
> > buf[3] = 0x00; /* reg addr MSB */
> > buf[4] = 0x00; /* reg addr LSB */
> > memcpy(&buf[5], msg[0].buf, msg[0].len);
> > - ret = af9035_ctrl_msg(d, &req);
> > + if (state->block_read) {
> > + msg[1].buf[0] = 0x3f;
> > + ret = 0;
> > + } else
> > + ret = af9035_ctrl_msg(d, &req);
> > }
> > } else if (num == 1 && !(msg[0].flags & I2C_M_RD)) {
> > if (msg[0].len > 40) {
> > @@ -638,6 +642,17 @@ static int af9035_read_config(struct dvb
> > for (i = 0; i < ARRAY_SIZE(state->af9033_config); i++)
> > state->af9033_config[i].clock = clock_lut[tmp];
> >
> > + state->block_read = false;
> > +
> > + if (le16_to_cpu(d->udev->descriptor.idVendor) == USB_VID_AVERMEDIA &&
> > + le16_to_cpu(d->udev->descriptor.idProduct) ==
> > + USB_PID_AVERMEDIA_TWINSTAR) {
> > + dev_dbg(&d->udev->dev,
> > + "%s: AverMedia Twinstar: block i2c read from
> > tuner\n",
> > + __func__);
> > + state->block_read = true;
> > + }
> > +
> > return 0;
> >
> > err:
> > diff -upr linux/drivers/media/usb/dvb-usb-v2/af9035.h
> > linux.new/drivers/media/usb/dvb-usb-v2/af9035.h
> > --- linux/drivers/media/usb/dvb-usb-v2/af9035.h 2013-01-07
> > 05:45:57.0 +0100
> > +++ linux.new/drivers/media/usb/dvb-usb-v2/af9035.h 2013-02-08
> > 22:52:42.293842710 +0100
> > @@ -54,6 +54,7 @@ struct usb_req {
> > struct state {
> > u8 seq; /* packet sequence number */
> > bool dual_mode;
> > + bool block_read;
> > struct af9033_config af9033_config[2];
> > };
> >
> >
> >
>
> Could you test if faking tuner ID during attach() is enough?
>
> Also, I would like to know what is returned error code from firmware
> when it fails. Enable debugs to see it. It should print something like that:
> af9035_ctrl_msg: command=03 failed fw error=2
>
>
> diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c
> b/drivers/media/usb/dvb-usb-v2/af9035.c
> index a1e953a..5a4f28d 100644
> --- a/drivers/media/usb/dvb-usb-v2/af9035.c
> +++ b/drivers/media/usb/dvb-usb-v2/af9035.c
> @@ -1082,9 +1082,22 @@ static int af9035_tuner_attach(struct
> dvb_usb_adapter *adap)
> tuner_addr = 0x60 | 0x80; /* I2C bus hack */
> }
>
> + // fake used tuner for demod firmware / i2c adapter
> + if (adap->id == 0)
> + ret = af9035_wr_reg(d, 0x00f641,
> AF9033_TUNER_FC0011);
> + else
> + ret = af9035_wr_reg(d, 0x10f641,
> AF9033_TUNER_FC0011);
> +
> /* attach tuner */
> fe = dvb_attach(mxl5007t_attach, adap->fe[0], &d->i2c_adap,
> tuner_addr,
> &af9035_mxl5007t_config[adap->id]);
> +
> + // return correct tuner
> + if (adap->id == 0)
> + ret = af9035_wr_reg(d, 0x00f641,
> AF9033_TUNER_MXL5007T);
> + else
> + ret = af9035_wr_reg(d, 0x10f641,
> AF9033_TUNER_MXL5007T);
> +
> break;
> case AF9033_TUNER_TDA18218:
> /* attach tuner */
>
> regards
> Antti
>
>
I will try with fake tuner, but I can't test unil next weekend.
If I remember, the read operation is performed, and return good value,
but after that, all the i2c transfers fail. Seee:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg56346.html
Jose Alberto
--
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: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
Hi, On 02/11/2013 02:21 PM, Hans Verkuil wrote: On Mon February 11 2013 14:08:44 Hans de Goede wrote: Hi, Subject: stk-webcam: the initial hflip and vflip setup was the wrong way around No it is not. You are right, that patch makes no sense. It was a long day :-) On 02/10/2013 06:52 PM, Hans Verkuil wrote: From: Hans Verkuil This resulted in an upside-down picture. No it does not, the laptop having an upside down mounted camera and not being in the dmi-table is what causes an upside down picture. For a non upside down camera (so no dmi-match) hflip and vflip should be 0. The fix for the upside-down-ness Arvydas Sidorenko reported would be to add his laptop to the upside down table. That doesn't make sense either. Arvydas, it worked fine for you before, right? Yes, it probably worked before, but not with... That is, if you use e.g. v3.8-rc7 then your picture is the right side up. 3.8 will show it upside down for Arvydas The story goes likes this: 1) Once upon a time the stkwebcam driver was written 2) The webcam in question was used mostly in Asus laptop models, including the laptop of the original author of the driver, and in these models, in typical Asus fashion (see the long long list for uvc cams inside v4l-utils), they mounted the webcam-module the wrong way up. So the hflip and vflip module options were given a default value of 1 (the correct value for upside down mounted models) 3) Years later I got a bug report from a user with a laptop with stkwebcam, where the module was actually mounted the right way up, and thus showed upside down under Linux. So now I was facing the choice of 2 options: a) Add a not-upside-down list to stkwebcam, which overrules the default b) Do it like all the other drivers do, and make the default right for cams mounted the proper way and add an upside-down model list, with models where we need to flip-by-default. Despite knowing that going b) would cause a period of pain where we were building the table (ie what we're discussing now) I opted to go for option b), since a) is just too ugly, and worse different from how every other driver does it leading to confusion in the long run. IOW this is entirely my fault, and I take full responsibility for it. Arvydas, can you please run "sudo dmidecode > dmi.log", and send me or Hans V. the generated dmi.log file? Then we can add your laptop to the upside-down model list. Regards, Hans -- 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: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
On Mon February 11 2013 14:08:44 Hans de Goede wrote: > Hi, > > Subject: stk-webcam: the initial hflip and vflip setup was the wrong way > around > > No it is not. You are right, that patch makes no sense. It was a long day :-) > On 02/10/2013 06:52 PM, Hans Verkuil wrote: > > From: Hans Verkuil > > > > This resulted in an upside-down picture. > > No it does not, the laptop having an upside down mounted camera and not being > in the dmi-table is what causes an upside down picture. For a non upside > down camera (so no dmi-match) hflip and vflip should be 0. > > The fix for the upside-down-ness Arvydas Sidorenko reported would be to > add his laptop to the upside down table. That doesn't make sense either. Arvydas, it worked fine for you before, right? That is, if you use e.g. v3.8-rc7 then your picture is the right side up. Can you confirm that? Regards, Hans -- 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: [RFCv2 PATCH 01/12] stk-webcam: the initial hflip and vflip setup was the wrong way around
Hi, Subject: stk-webcam: the initial hflip and vflip setup was the wrong way around No it is not. On 02/10/2013 06:52 PM, Hans Verkuil wrote: From: Hans Verkuil This resulted in an upside-down picture. No it does not, the laptop having an upside down mounted camera and not being in the dmi-table is what causes an upside down picture. For a non upside down camera (so no dmi-match) hflip and vflip should be 0. The fix for the upside-down-ness Arvydas Sidorenko reported would be to add his laptop to the upside down table. Regards, Hans -- 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
[GIT PULL 3.9] soc-camera + sh-vou
Hi Mauro Here go a couple of improvements for 3.9. The following changes since commit a32f7d1ad3744914273c6907204c2ab3b5d496a0: Merge branch 'v4l_for_linus' into staging/for_v3.9 (2013-01-24 18:49:18 -0200) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-3.9-set_2 Julia Lawall (1): drivers/media/platform/soc_camera/pxa_camera.c: use devm_ functions Laurent Pinchart (2): sh_vou: Use video_drvdata() sh_vou: Use vou_dev instead of vou_file wherever possible drivers/media/platform/sh_vou.c| 114 +++- drivers/media/platform/soc_camera/pxa_camera.c | 65 +++-- 2 files changed, 67 insertions(+), 112 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
[GIT PULL] soc-camera 3.8 / 3.9 fixes
Hi Mauro I guess, these are too late for 3.8, so, let's push them for 3.9 too. The following changes since commit 2e51b231a8d716ea5aacde0bd95ac789cea195b0: Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux (2013-01-30 12:02:26 +1100) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git for-3.8-set_3 Guennadi Liakhovetski (2): sh-mobile-ceu-camera: fix SHARPNESS control default mt9t112: mt9t111 format set up differs from mt9t112 drivers/media/i2c/soc_camera/mt9t112.c | 18 +- .../platform/soc_camera/sh_mobile_ceu_camera.c |2 +- 2 files changed, 14 insertions(+), 6 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
