Credit Inquiries email lists
Here's a list package on sale this week only: Business/Consumer List Package US New Business Database - 4.8 million records all with emails American Consumer Database - 1,300,000 records all with emails. American Homeowners - 1 million Full Data Records all with emails All complete lists above: $295 There are more packages and not just for business. we also have healthcare, consumers and more. Contact me here for more info or to get samples: successto...@gmx.com To invoke no further correspondence status please send an email to remfi...@gmx.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/11] V4L/DVB: omap_vout: Storage class should be before const qualifier
The C99 specification states in section 6.11.5:
The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: Tobias Klauser tklau...@distanz.ch
---
drivers/media/video/omap/omap_vout.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 4c0ab49..d6a2ae1 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -128,7 +128,7 @@ module_param(debug, bool, S_IRUGO);
MODULE_PARM_DESC(debug, Debug level (0-1));
/* list of image formats supported by OMAP2 video pipelines */
-const static struct v4l2_fmtdesc omap_formats[] = {
+static const struct v4l2_fmtdesc omap_formats[] = {
{
/* Note: V4L2 defines RGB565 as:
*
--
1.6.3.3
--
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] V4L/DVB: New NXP tda18218 tuner
Signed-off-by: Nikola Pajkovsky npajk...@redhat.com
---
drivers/media/common/tuners/Kconfig |7 +
drivers/media/common/tuners/Makefile|1 +
drivers/media/common/tuners/tda18218.c | 432 +++
drivers/media/common/tuners/tda18218.h | 44 +++
drivers/media/common/tuners/tda18218_priv.h | 36 +++
drivers/media/dvb/dvb-usb/af9015.c | 13 +-
drivers/media/dvb/frontends/af9013.c| 15 +
drivers/media/dvb/frontends/af9013_priv.h |5 +-
8 files changed, 548 insertions(+), 5 deletions(-)
create mode 100644 drivers/media/common/tuners/tda18218.c
create mode 100644 drivers/media/common/tuners/tda18218.h
create mode 100644 drivers/media/common/tuners/tda18218_priv.h
diff --git a/drivers/media/common/tuners/Kconfig
b/drivers/media/common/tuners/Kconfig
index 409a426..b00c63c 100644
--- a/drivers/media/common/tuners/Kconfig
+++ b/drivers/media/common/tuners/Kconfig
@@ -179,4 +179,11 @@ config MEDIA_TUNER_MAX2165
help
A driver for the silicon tuner MAX2165 from Maxim.
+config MEDIA_TUNER_TDA18218
+ tristate NXP TDA18218 silicon tuner
+ depends on VIDEO_MEDIA I2C
+ default m if MEDIA_TUNER_CUSTOMISE
+ help
+ A driver for the silicon tuner TDA18218 from NXP.
+
endif # MEDIA_TUNER_CUSTOMISE
diff --git a/drivers/media/common/tuners/Makefile
b/drivers/media/common/tuners/Makefile
index a543852..96da03d 100644
--- a/drivers/media/common/tuners/Makefile
+++ b/drivers/media/common/tuners/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_MEDIA_TUNER_MXL5005S) += mxl5005s.o
obj-$(CONFIG_MEDIA_TUNER_MXL5007T) += mxl5007t.o
obj-$(CONFIG_MEDIA_TUNER_MC44S803) += mc44s803.o
obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o
+obj-$(CONFIG_MEDIA_TUNER_TDA18218) += tda18218.o
EXTRA_CFLAGS += -Idrivers/media/dvb/dvb-core
EXTRA_CFLAGS += -Idrivers/media/dvb/frontends
diff --git a/drivers/media/common/tuners/tda18218.c
b/drivers/media/common/tuners/tda18218.c
new file mode 100644
index 000..1860b18
--- /dev/null
+++ b/drivers/media/common/tuners/tda18218.c
@@ -0,0 +1,432 @@
+/*
+ * Driver for NXP TDA18218 silicon tuner
+ *
+ * Copyright (C) 2010 Lauris Ding ld...@gmx.de
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include tda18218.h
+#include tda18218_priv.h
+
+static int tda18218_write_reg(struct dvb_frontend *fe, u8 reg, u8 val)
+{
+ struct tda18218_priv *priv = fe-tuner_priv;
+ u8 buf[2] = { reg, val };
+ struct i2c_msg msg = { .addr = priv-cfg-i2c_address, .flags = 0,
+ .buf = buf, .len = 2 };
+ int ret;
+
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 1);
+ /* write register */
+ ret = i2c_transfer(priv-i2c, msg, 1);
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 0);
+
+ if (ret != 1)
+ printk(KERN_WARNING I2C write failed ret: %d reg: %02x\n,
ret, reg);
+
+ return (ret == 1 ? 0 : ret);
+}
+
+static int tda18218_write_regs(struct dvb_frontend *fe, u8 reg,
+ u8 *val, u8 len)
+{
+ struct tda18218_priv *priv = fe-tuner_priv;
+ u8 buf[1+len];
+ struct i2c_msg msg = {
+ .addr = priv-cfg-i2c_address,
+ .flags = 0,
+ .len = sizeof(buf),
+ .buf = buf };
+
+ int ret;
+
+ buf[0] = reg;
+ memcpy(buf[1], val, len);
+
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 1);
+ ret = i2c_transfer(priv-i2c, msg, 1);
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 1);
+
+ if (ret != 1)
+ printk(KERN_WARNING I2C write failed ret: %d reg: %02x len:
%d\n, ret, reg, len);
+
+ return (ret == 1 ? 0 : ret);
+}
+
+static int tda18218_read_regs(struct dvb_frontend *fe)
+{
+ struct tda18218_priv *priv = fe-tuner_priv;
+ u8 *regs = priv-tda18218_regs;
+ u8 buf = 0x00;
+ int ret;
+ struct i2c_msg msg[] = {
+ { .addr = 0xc0, .flags = 0,
+ .buf = buf, .len = 1 },
+ { .addr = 0xc0, .flags = I2C_M_RD,
+ .buf = regs, .len = 59 }
+ };
+
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 1);
+
+ /* read all
[PULL] nGene updates from http://linuxtv.org/hg/~endriss/ngene-new
Mauro, Please pull from http://linuxtv.org/hg/~endriss/ngene-new for the following 6 changesets: 01/06: ngene: Support new device 'Digital Devices DuoFlex S2 miniPCIe' http://endr...@linuxtv.org/hg/~endriss/ngene-new?cmd=changeset;node=691aeec6bdb2 02/06: ngene: Do not call demuxer with interrupts disabled http://endr...@linuxtv.org/hg/~endriss/ngene-new?cmd=changeset;node=dfdedb2cc2d1 03/06: ngene: Implement support for MSI http://endr...@linuxtv.org/hg/~endriss/ngene-new?cmd=changeset;node=029fc05ae78e 04/06: ngene: Make command timeout workaround configurable http://endr...@linuxtv.org/hg/~endriss/ngene-new?cmd=changeset;node=dc8862594f67 05/06: ngene: MSI cleanup http://endr...@linuxtv.org/hg/~endriss/ngene-new?cmd=changeset;node=26d2789d9f32 06/06: ngene: Remove debug message http://endr...@linuxtv.org/hg/~endriss/ngene-new?cmd=changeset;node=bbabad270bf6 ngene-cards.c | 15 ++ ngene-core.c | 82 +++--- ngene-dvb.c | 14 ++--- ngene.h |3 ++ 4 files changed, 77 insertions(+), 37 deletions(-) Thanks, Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [linux-dvb] new DVB-T initial tuning for fr-nantes
One thing that would be good to do -- for someone who is in the
area served by a transmitter -- rather than use «AUTO» for the
FEC and Guard Interval values above, would be to perform a NIT
scan on the appropriate frequencies.
This should give as a result the actual transmitter frequency
and other parameters in use, and perhaps related ones from other
sites.
These values are configured by the broadcaster and are therefore
not guaranteed to be 100% accurate, but it is more likely that
they know the values they are using -- these values can be used
to locate other transmitter frequencies, as is the well-known
case for DVB-S satellite NIT tables.
Unfortunately, the terrestrial delivery descriptors are completely
wrong in the NIT of the French terrestrial network. The NIT is the
same all over the country, which is not appropriate in a terrestrial
network, and the frequency, FEC and guard interval are wrong. The
same TS will have distinct frequencies (of course) on different
transmitters but also distinct FEC and guard interval (actually,
two combinations are used: either 2/3 1/32 or 3/4 1/8).
Recently, many transmitters have changed the modulation parameters
while staying on the same frequency. It is very difficult to keep
up to date. Between the moment when you submit a patch with the
new parameters and the moment you get the file in your distro,
the parameters may have changed again.
I think that in such a moving environment, the AUTO choice is
definitely better.
-Thierry
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
AVerMedia A336 MiniCard Hybrid DVB-T
I couldn't find any information on this card or how to support it. Here is the output of lsusb -v. This card was built into the Acer Z5600 computer I bought a couple of weeks ago. Running Ubuntu 10.04 with kernel 2.6.32; I can install newer mainline kernels if required. Bus 002 Device 005: ID 07ca:1336 AVerMedia Technologies, Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 ? bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x07ca AVerMedia Technologies, Inc. idProduct 0x1336 bcdDevice 40.01 iManufacturer 1 AVerMedia TECHNOLOGIES, Inc. iProduct 2 AVerMedia A336 MiniCard Hybrid DVB-T iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 344 bNumInterfaces 7 bConfigurationValue 1 iConfiguration 4 AVerMedia A336 MiniCard Hybrid DVB-T bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 32 AVerMedia A336 MiniCard Hybrid DVB-T Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 4 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0e EP 14 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 4 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 1 bInterfaceCount 6 bFunctionClass 255 Vendor Specific Class bFunctionSubClass 255 Vendor Specific Subclass bFunctionProtocol 255 Vendor Specific Protocol iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 7 AVerMedia A336 MiniCard Hybrid DVB-T Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8f EP 15 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 7 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 8 AVerMedia A336 MiniCard Hybrid DVB-T Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 9 AVerMedia A336 MiniCard Hybrid DVB-T Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize
Re: [linux-dvb] Leadtek DVT1000S W/ Phillips saa7134
Hi, Am Freitag, den 21.05.2010, 06:01 +1000 schrieb Nathan Metcalf: Thanks Hermann, Does this mean I need to apply that patch you linked to me? Then recompile the module and re-insert? Regards, Nathan depends on your source. The 2.6.32 has no support for that card and it depends also on further patches for tuner and demodulator However, all 4 patches in question are in this pull request Von: Mauro Carvalho Chehab mche...@redhat.com An: Linus Torvalds torva...@linux-foundation.org Kopie: Andrew Morton a...@linux-foundation.org, linux-ker...@vger.kernel.org, linux-media@vger.kernel.org Betreff: [GIT PULL for 2.6.33] V4L/DVB updates Datum: Wed, 9 Dec 2009 02:16:39 -0200 (05:16 CET) and via Michael Krufky and Michael Obst for the remote. (add the card, fix the entry, add the remote support, fix some coding style) You need a kernel = 2.6.33 or have to build and install mercurial v4l-dvb from linuxtv.org on older kernels. The current v4l-dvb is in process to gain deeper compatibility for older kernels again, see the daily mails. [cron job] v4l-dvb daily build Progress was made from 2.6.33 only a few days ago down to 2.6.25 now. My latest test was on a 2.6.29. Else you can also use a snapshot from May 04 2010, after that backward compat was limited to 2.6.33 only for a while, see the v4l-dvb daily build messages. For 2.6.32 the recent is good again. Cheers, Hermann On 20/05/10 09:28, hermann pitton wrote: Hi Nathan, Am Freitag, den 21.05.2010, 04:48 +1000 schrieb Nathan Metcalf: Hey Guys, I hope this is the correct place, I am trying to get a LEADTEK DVT1000S HD Tuner card working in Ubuntu (Latest) When I load the saa7134_dvb kernel module, there are no errors, but /dev/dvb is not created. I have tried enabling the debug=1 option when loading the module, but don't get any more useful information. Can someone please assist me? Or direct me to the correct place? Regards, Nathan Metcalf there was some buglet previously, but the card is else supported since Nov. 01 2009 on mercurial v4l-dvb and later kernels. http://linuxtv.org/hg/v4l-dvb/rev/855ee0444e61b8dfe98f495026c4e75c461ce9dd Support for the remote was also added. Cheers, Hermann -- 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 Controls State Store/Restore File Format
Hi all,
Below is a proposal for the file format to use when storing/restoring
v4l2 controls state.
I've some doubts concerning atomically set controls and string
controls (see below)
that may be inducing me on error.
The format is intended to be generic enough to support any control
class so I hope
to receive comments for any special cases that I might have missed or
overlooked.
Don't worry about bashing on the proposal to hard I have a hard skin :-D
Regards,
Paulo
-- Forwarded message --
From: Hans de Goede hdego...@redhat.com
Date: 2010/5/20
Subject: Re: [RFC] V4L2 Controls State Store/Restore File Format
To: Paulo Assis pj.as...@gmail.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com,
martin_ru...@logitech.com
Hi Paulo,
Clearly you've though quite a bit about this I had not realized
this would be this complex (with ordering issues etc.).
This looks like a good proposal to start with to me, I think it
would be good to further discuss this on the linux-media list,
where other v4l devs can read it and chime in.
Regards,
Hans
On 05/20/2010 03:11 PM, Paulo Assis wrote:
Hans,
Below is the RFC with my proposed control state file format for
store/restore functionality.
I have several doubts, mostly regarding controls that must be set
atomically with the extended control API.
The main question is:
How does an application know that a group of controls must be set atomically ?
Is this reported by the driver or is it something that the application
must know.
Also for string controls, I've only seen two implementations on RDS
controls, so I've set these with low precedence/priority order
compared with other control types.
Awaiting comments, bash it all you want :-)
Regards,
Paulo
__
[RFC] V4L2 Controls State Store/Restore File Format
VERSION
0.0.1
ABSTRACT
This document proposes a standard for the file format used by v4l2
applications to store/restore the controls state.
This unified file format allows sharing control profiles between
applications, making it much easier on both developers and users.
INTRODUCTION
V4l2 controls can be divided by classes and types.
Controls in different classes are not dependent between themselves, on
the other end if two controls belong to the same class they may or may
not be dependent.
A good example are automatic controls and their absolute counterparts,
e.g.: V4L2_CID_AUTOGAIN and V4L2_CID_GAIN.
Controls must be set following the dependency order, automatic
controls must be set first or else setting the absolute value may
fail, when that was not the intended behavior (auto disabled).
After a quick analyses of the v4l2 controls, we are left to conclude
that auto controls are in most cases of the
boolean type, with some exceptions like V4L2_CID_EXPOSURE_AUTO, that
is of the menu type.
So ordering control priority by control type seems logical and it can
be done in the following order:
1-V4L2_CTRL_TYPE_BOOLEAN
2-V4L2_CTRL_TYPE_MENU
3-V4L2_CTRL_TYPE_INTEGER
4-V4L2_CTRL_TYPE_INTEGER64
5-V4L2_CTRL_TYPE_STRING
Button controls are stateless so they can't be stored and thus are out
of the scope of this document.
Relative controls are also in effect stateless, since they will always
depend on their current state and thus can't be stored.
There are also groups of controls that must be set atomically, so
these need to be grouped together and properly identified when loading
the controls state from a file.
The proposed file format takes all of this into account and tries to
make implementation of both store and restore functionality as easy as
possible.
FILE FORMAT
The proposed file format is a regular text file with lines terminating
with the newline character '\n'.
Comments can be inserted by adding '#' at the beginning of the line,
and can safely be ignored when parsing the file.
FILE EXTENSION
Although not much relevant, the file extension makes it easy to
visually identify the file type and also for applications to list
relevant files, so we propose that v4l2 control state files be
terminated by the suffix: .v4l
FILE HEADER
The file must always start with a commented line containing the file
type identification and the version of this document on which it is
based:
#V4L2/CTRL/0.0.1
Additionally it may contain extra information like the application
name that generated the file and for usb devices the vid and pid of
the device to whom the controls relate in hexadecimal notation:
APP_NAME{application name}
VID{0x00}
PID{0x00}
CONTROLS DATA
The controls related data must be ordered by control type and for each
type the ordering must be done by control ID. Ordering by control ID
will also group the controls by class.
The exception to the above rule are controls that need to be set
atomically, these must be grouped together independent of their type.
Each control must have is data set in a single line:
RE:
Asheesh, Please re-send this patch with following:- 1) A detailed description of what you are trying to fix in each of this patch. You need to also run the checkpatch.pl script to make sure there are no errors. 2) Please make this patch based on the http://git.linuxtv.org/v4l-dvb.git master branch. I am assuming you have based it upon the Arago tree. 3) add the Signed-off-by field. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Bhardwaj, Asheesh Sent: Wednesday, May 19, 2010 12:45 PM To: linux-media@vger.kernel.org Subject: The patches will be applied to the davinci tree the ../drivers/media/video/davinci and will affect the both the capture and display drivers. Apply these patches to the git kernel. From ashee...@ti.com # This line is ignored. GIT: From: ashee...@ti.com Subject: In-Reply-To: -- 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: [PATCH] input: fix error at the default input_get_keycode call
On Thu, 20 May 2010 01:55:50 -0300, Mauro Carvalho Chehab said: [ 76.376140] BUG: unable to handle kernel NULL pointer dereference at (null) [ 76.376670] IP: [c138b6d0] input_default_getkeycode_from_index+0x40/0x60 [ 76.376670] *pde = [ 76.376670] Oops: 0002 [#1] SMP [ 76.376670] last sysfs file: /sys/devices/virtual/block/dm-5/range [ 76.376670] Modules linked in: ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 dm_mirror dm_region_hash dm_log uinput snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer snd ppdev sg parport_pc soundcore k8temp snd_page_alloc forcedeth pcspkr hwmon parport i2c_nforce2 sd_mod crc_t10dif sr_mod cdrom pata_acpi ata_generic pata_amd sata_nv floppy nouveau ttm drm_kms_helper drm i2c_algo_bit i2c_core dm_mod [last unloaded: scsi_wait_scan] [ 76.376670] [ 76.376670] Pid: 6183, comm: getkeycodes Not tainted 2.6.34 #11 C51MCP51/ [ 76.376670] EIP: 0060:[c138b6d0] EFLAGS: 00210046 CPU: 0 [ 76.376670] EIP is at input_default_getkeycode_from_index+0x40/0x60 [ 76.376670] EAX: EBX: ECX: 0002 EDX: f53ebdc8 [ 76.376670] ESI: f53ebdc8 EDI: f5daf794 EBP: f53ebdb8 ESP: f53ebdb4 [ 76.376670] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [ 76.376670] Process getkeycodes (pid: 6183, ti=f53ea000 task=f53bd060 task.ti=f53ea000) [ 76.376670] Stack: [ 76.376670] f5daf000 f53ebdec c138d233 f53ebe30 00200286 0004 [ 76.376670] 0 f53ebe2c f5da0340 c16c12cc f53ebdf8 c12f4148 [ 76.376670] 0 c12f4130 f53ebe24 c138d9f8 0002 0001 c138d980 c12f4130 [ 76.376670] Call Trace: [ 76.376670] [c138d233] ? input_get_keycode+0x73/0x90 input_default_getkeycode_from_index() returns the scancode at kt_entry.scancode pointer. Fill it with the scancode address at the function call. Thanks-to: Vladis Kletnieks valdis.kletni...@vt.edu for pointing the issue Cc: Dmitry Torokhov dmitry.torok...@gmail.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/input/input.c b/drivers/input/input.c index 3b63fad..7851d8e 100644 Still dies, but in input_set_keycode() instead... [ 35.294528] BUG: unable to handle kernel NULL pointer dereference at (null) [ 35.295005] IP: [(null)] (null) [ 35.296935] PGD 11da3c067 PUD 11d4ad067 PMD 0 [ 35.296935] Oops: 0010 [#1] PREEMPT SMP [ 35.299667] last sysfs file: /sys/devices/pci:00/:00:1a.7/usb1/idVendor [ 35.300328] CPU 0 [ 35.300328] Modules linked in: [ 35.300328] [ 35.300328] Pid: 2481, comm: keymap Not tainted 2.6.34-mmotm0519 #1 0X564R/Latitude E6500 [ 35.300328] RIP: 0010:[] [(null)] (null) [ 35.300328] RSP: 0018:88011d4d5cb0 EFLAGS: 00010046 [ 35.310163] RAX: RBX: 88011c03e000 RCX: 0081 [ 35.310163] RDX: 88011d4d5cc4 RSI: 88011d4d5cc8 RDI: 88011c03e000 [ 35.310163] RBP: 88011d4d5d28 R08: 88011e9b28e8 R09: 0001 [ 35.310163] R10: 81e0b160 R11: 0004 R12: 00a4 [ 35.310163] R13: 88011c03e830 R14: 0286 R15: 88011d4d5cc8 [ 35.310163] FS: 7f4b86283700() GS:88000260() knlGS: [ 35.319397] CS: 0010 DS: ES: CR0: 80050033 [ 35.319397] CR2: CR3: 00011d575000 CR4: 000406f0 [ 35.319397] DR0: DR1: DR2: [ 35.319397] DR3: DR6: 0ff0 DR7: 0400 [ 35.319397] Process keymap (pid: 2481, threadinfo 88011d4d4000, task 88011e9b28c0) [ 35.319397] Stack: [ 35.319397] 813bf3d1 88011d4d5cf8 00810246 008100a4 [ 35.319397] 0 0004 88011d4d5cc4 88011cf11200 [ 35.319397] 0 88011c179000 88011d4d5d28 0081 7fff9ee21fa0 [ 35.319397] Call Trace: [ 35.319397] [813bf3d1] ? input_set_keycode+0xad/0x12c [ 35.319397] [813c231d] evdev_do_ioctl+0x22b/0x79b [ 35.337913] [815a4b04] ? __mutex_lock_common+0x564/0x580 [ 35.337913] [813c28ca] ? evdev_ioctl_handler+0x3d/0x80 [ 35.341507] [813c28ca] ? evdev_ioctl_handler+0x3d/0x80 [ 35.341507] [813c28f0] evdev_ioctl_handler+0x63/0x80 [ 35.344034] [813c292a] evdev_ioctl+0xb/0xd [ 35.344034] [810ea6cd] vfs_ioctl+0x2d/0xa1 [ 35.344034] [810eac4c] do_vfs_ioctl+0x494/0x4cd [ 35.344034] [810eacdc] sys_ioctl+0x57/0x95 [ 35.344034] [8100266b] system_call_fastpath+0x16/0x1b [ 35.344034] Code: Bad RIP value. [ 35.344034] RIP [(null)] (null) [ 35.344034] RSP 88011d4d5cb0 [ 35.344034] CR2: [ 35.357018] ---[ end trace 394fa5aa8a77b6f3 ]--- pgpII4PM6eepb.pgp Description: PGP signature
Re: dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
On Thu, May 06, 2010 at 02:52:22PM -, Ang Way Chuang wrote:
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the
remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer
field on the subsequent MPEG2-TS frame.
This patch was generated and tested against v2.6.34-rc6. I suspect
that this bug was introduced in kernel version 2.6.15, but had not
verified it.
Care has been taken not to introduce more bug by fixing this bug, but
please scrutinize the code because I always produces buggy code.
Signed-off-by: Ang Way Chuang wc...@nav6.org
---
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 441c064..35a4afb 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -458,8 +458,9 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
field: %u.\n,
priv-ts_count, *from_where);
/* Drop partly decoded SNDU,
reset state, resync on PUSI. */
- if (priv-ule_skb) {
- dev_kfree_skb(
priv-ule_skb );
+ if (priv-ule_skb ||
priv-ule_sndu_remain) {
+ if (priv-ule_skb)
+ dev_kfree_skb(
priv-ule_skb );
dev-stats.rx_errors++;
dev-stats.rx_frame_errors++;
}
That code block looks odd that way, but after staring at it for a minute,
it makes sense. Another way to do it that might read cleaner (and reduce
excessive tab indent levels) would be to add a 'bool errors', then:
bool errors = false;
...
if (priv-ule_skb) {
errors = true;
dev_kfree_skb(priv-ule_skb);
}
if (errors || priv-ule_sndu_remain) {
dev-stats.rx_errors++;
dev-stats.rx_frame_errors++;
}
@@ -534,6 +535,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
from_where += 2;
}
+ priv-ule_sndu_remain = priv-ule_sndu_len + 2;
/*
* State of current TS:
* ts_remain (remaining bytes in the current TS cell)
Is this *always* true? Your description says ...the remaining 2 or 3
bytes, indicating this could sometimes need to be +3. Is +0 also a
possibility?
@@ -543,6 +545,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
*/
switch (ts_remain) {
case 1:
+ priv-ule_sndu_remain--;
priv-ule_sndu_type = from_where[0]
8;
priv-ule_sndu_type_1 = 1; /* first
byte of ule_type is set. */
ts_remain -= 1; from_where += 1;
@@ -556,6 +559,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
default: /* complete ULE header is present in
current TS. */
/* Extract ULE type field. */
if (priv-ule_sndu_type_1) {
+ priv-ule_sndu_type_1 = 0;
priv-ule_sndu_type |=
from_where[0];
from_where += 1; /* points to
payload start. */
ts_remain -= 1;
--
Jarod Wilson
ja...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] V4L/DVB: buf-dma-sg.c: support non-pageable user-allocated memory
On Thursday 06 May 2010 06:06:21, Mauro Carvalho Chehab wrote:
Hi Arnout,
Arnout Vandecappelle wrote:
videobuf_dma_init_user_locked() uses get_user_pages() to get the
virtual-to-physical address mapping for user-allocated memory.
However, the user-allocated memory may be non-pageable because it
is an I/O range or similar. get_user_pages() fails with -EFAULT
in that case.
If the user-allocated memory is physically contiguous, the approach
of V4L2_MEMORY_OVERLAY can be used. If it is not, -EFAULT is still
returned.
---
drivers/media/video/videobuf-dma-sg.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
Your patch looked sane to my eyes. I just noticed one warning at the
dprintk, when compiled with 32 bits address space, and a few coding
style issues. I needed to rebase it also, due to some changes at
videobuf.
However, you missed your SOB. Could you please send it? I'm enclosing
the version with my changes for you to sign.
---
V4L/DVB: buf-dma-sg.c: support non-pageable user-allocated memory
Date: Wed, 17 Mar 2010 22:53:05 -
From: Arnout Vandecappelle arn...@mind.be
videobuf_dma_init_user_locked() uses get_user_pages() to get the
virtual-to-physical address mapping for user-allocated memory.
However, the user-allocated memory may be non-pageable because it
is an I/O range or similar. get_user_pages() fails with -EFAULT
in that case.
If the user-allocated memory is physically contiguous, the approach
of V4L2_MEMORY_OVERLAY can be used. If it is not, -EFAULT is still
returned.
[mche...@redhat.com: Fixed CodingStyle and warning at dprintk on i386]
---
drivers/media/video/videobuf-dma-sg.c | 18 ++
drivers/media/video/videobuf-dma-sg.c | 20
1 file changed, 20 insertions(+)
--- work.orig/drivers/media/video/videobuf-dma-sg.c
+++ work/drivers/media/video/videobuf-dma-sg.c
@@ -145,6 +145,7 @@ static int videobuf_dma_init_user_locked
{
unsigned long first, last;
int err, rw = 0;
+ struct vm_area_struct *vma;
dma-direction = direction;
switch (dma-direction) {
@@ -162,6 +163,25 @@ static int videobuf_dma_init_user_locked
last = ((data+size-1) PAGE_MASK) PAGE_SHIFT;
dma-offset = data ~PAGE_MASK;
dma-nr_pages = last-first+1;
+
+ /* In case the buffer is user-allocated and is actually an IO buffer
for +some other hardware, we cannot map pages for it. It in fact
behaves +the same as an overlay. */
+ vma = find_vma(current-mm, data);
+ if (vma (vma-vm_flags VM_IO)) {
+ /* Only a single contiguous buffer is supported. */
+ if (vma-vm_end data + size) {
+ dprintk(1, init user: non-contiguous IO buffer.\n);
+ /* same error that get_user_pages() would give */
+ return -EFAULT;
+ }
+ dma-bus_addr = (vma-vm_pgoff PAGE_SHIFT) +
+ (data - vma-vm_start);
+ dprintk(1, init user IO [0x%lx+0x%lx = %d pages at 0x%llx]\n,
+ data, size, dma-nr_pages, (long long)dma-bus_addr);
+ return 0;
+ }
+
dma-pages = kmalloc(dma-nr_pages * sizeof(struct page *),
GFP_KERNEL); if (NULL == dma-pages)
return -ENOMEM;
Signed-off-by: Arnout Vandecappelle arn...@mind.be
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286540
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, BelgiumBE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 31BB CF53 8660 6F88 345D 54CC A836 5879 20D7 CF43
--
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
MMAP buffer allocation Davinci
Karicheri, Muralidharan m-karicheri2 at ti.com writes: Asheesh, Please re-send this patch with following:- 1) A detailed description of what you are trying to fix in each of this patch. You need to also run the checkpatch.pl script to make sure there are no errors. 2) Please make this patch based on the http://git.linuxtv.org/v4l-dvb.git master branch. I am assuming you have based it upon the Arago tree. 3) add the Signed-off-by field. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-karicheri2 at ti.com -Original Message- From: linux-media-owner at vger.kernel.org [mailto:linux-media- owner at vger.kernel.org] On Behalf Of Bhardwaj, Asheesh Sent: Wednesday, May 19, 2010 12:45 PM To: linux-media at vger.kernel.org Subject: The patches will be applied to the davinci tree the ../drivers/media/video/davinci and will affect the both the capture and display drivers. Apply these patches to the git kernel. From asheeshb at ti.com # This line is ignored. GIT: From: asheeshb at ti.com Subject: In-Reply-To: -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html The following portion of the mail was truncted from the originla post. Thers are 1-7 patches on this series. The kernel patches are targetted for support of memory allocation during boot time for large buffers. This will allow the user to get contiguous buffers beyond linux memory and can configure the location and size of the buffer using parametrs configured during boot time using bootargs. The current implementation will allow the application to get MMAP buffers but those buffers cannot be contiguous and create defragmentation. The approach to provide contiguous buffers is inherited from the ../drivers/media/video/sh_mobile_ceu_camera.c already exist in the community code which uses dma_alloc_coherent function to get the contiguous buffers from the memory. During runtime the driver will allocate the required buffers from the contiguous memory. The memory can be configured using the following arguments on the bootargs 1. Davinci display and vpfe cature driver davinci_display.cont2_bufsize=size of the total display buffers in bytes davinci_display.cont2_bufoffset=offset for the display buffers from linux memory in bytes vpfe_capture.cont_bufsize==size of the total capture buffers in bytes vpfe_capture.cont_bufoffset==offset for the capture buffer from linux memory bytes 2. DavinciHD VPIF display and capture driver vpif_display.cont_bufsize=size of the display buffers in bytes vpif_display.cont_bufoffset=offset for the display buffers from linux memory in bytes vpif_capture.cont_bufsize=size of the capture buffers in bytes vpif_capture.cont_bufoffset=offset for the capture buffers from linux memory in bytes The patches will be applied to the davinci tree the ../drivers/media/video/davinci and will affect the both the capture and display drivers. Apply these patches to the git kernel. -- 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 -mmotm] media: ak881x needs slab.h
From: Randy Dunlap randy.dun...@oracle.com Add slab.h to fix ak881x build: drivers/media/video/ak881x.c:265:error: implicit declaration of function 'kzalloc' drivers/media/video/ak881x.c:265:warning: assignment makes pointer from integer without a cast drivers/media/video/ak881x.c:283:error: implicit declaration of function 'kfree' Signed-off-by: Randy Dunlap randy.dun...@oracle.com Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de Cc: Mauro Carvalho Chehab mche...@infradead.org --- drivers/media/video/ak881x.c |1 + 1 file changed, 1 insertion(+) --- mmotm-2010-0519-1612.orig/drivers/media/video/ak881x.c +++ mmotm-2010-0519-1612/drivers/media/video/ak881x.c @@ -11,6 +11,7 @@ #include linux/i2c.h #include linux/init.h #include linux/platform_device.h +#include linux/slab.h #include linux/videodev2.h #include media/ak881x.h -- 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
Loosing connection on hauppauge hdvpr (fixed firmware)
Hello, I got a problem with my Hauppauge hdpvr device: After getting an involuntary firmware update of my cable-tv box (UPC Austria), the hdvpr device looses connection when a commercial appears or when the channel will be changed. They have installed a commercial-marker or other stupid thing. The hdpvr-configuration is YPbPr-analog-input and S/PDIF/toslink-digital-input. I am using the HD Fury 2-device to get the HDMI-source from the cable box. This might be the problem device and the Fury maybe cut off the connection for short time - but it isn't visible by me. Anyway, the firmware should be able to CATCH such connection-abort-problems? Plugging the HDMI-source to the TV directly will not show any problems. There are no information in the log (hdpvr debug setting is highest: 7) There is another phenomenon with the digital sound: Plugging the toslink cable from tv-box to the hdpvr device will interrupt the sound for 1-2 seconds after 5 seconds repeatedly. I'dont know if this problem is part of the kernel module but it would be nice if this could be fixed. I'm available for some testing and try-out-sessions to find out more.. Best Rene -- 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
Hardware able to reliably tune to high rate DVB-S2
Hi all, I am looking for a DVB-S/S2 card able to reliably tune to high symbol rates DVB-S2 (here I have a transponder with 45MS/s), I also need this with CI support. I have seen that mystix cards could be a good candidate but I am not sure. PCI or PCIe is OK, dual tuner is not mandatory. TIA, Bye Manu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dvb-core: Fix ULE decapsulation bug when less than 4 bytes of ULE SNDU is packed into the remaining bytes of a MPEG2-TS frame
Hi Jarod,
Thanks for the review. My answers are inlined.
Jarod Wilson wrote:
On Thu, May 06, 2010 at 02:52:22PM -, Ang Way Chuang wrote:
ULE (Unidirectional Lightweight Encapsulation RFC 4326) decapsulation
code has a bug that incorrectly treats ULE SNDU packed into the
remaining 2 or 3 bytes of a MPEG2-TS frame as having invalid pointer
field on the subsequent MPEG2-TS frame.
This patch was generated and tested against v2.6.34-rc6. I suspect
that this bug was introduced in kernel version 2.6.15, but had not
verified it.
Care has been taken not to introduce more bug by fixing this bug, but
please scrutinize the code because I always produces buggy code.
Signed-off-by: Ang Way Chuang wc...@nav6.org
---
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 441c064..35a4afb 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -458,8 +458,9 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
field: %u.\n,
priv-ts_count, *from_where);
/* Drop partly decoded SNDU,
reset state, resync on PUSI. */
- if (priv-ule_skb) {
- dev_kfree_skb(
priv-ule_skb );
+ if (priv-ule_skb ||
priv-ule_sndu_remain) {
+ if (priv-ule_skb)
+ dev_kfree_skb(
priv-ule_skb );
dev-stats.rx_errors++;
dev-stats.rx_frame_errors++;
}
That code block looks odd that way, but after staring at it for a minute,
it makes sense. Another way to do it that might read cleaner (and reduce
excessive tab indent levels) would be to add a 'bool errors', then:
bool errors = false;
...
if (priv-ule_skb) {
errors = true;
dev_kfree_skb(priv-ule_skb);
}
if (errors || priv-ule_sndu_remain) {
dev-stats.rx_errors++;
dev-stats.rx_frame_errors++;
}
Yeap, I'm a lazy person.
@@ -534,6 +535,7 @@ static void dvb_net_ule( struct net_device *dev, const u8
*buf, size_t buf_len )
from_where += 2;
}
+ priv-ule_sndu_remain = priv-ule_sndu_len + 2;
/*
* State of current TS:
* ts_remain (remaining bytes in the current TS cell)
Is this *always* true? Your description says ...the remaining 2 or 3
bytes, indicating this could sometimes need to be +3. Is +0 also a
possibility?
Not sure whether I understand your question correctly. Here is my attempt to answer your question.
The encapsulation format always mandate that at least of 2 bytes of ULE SNDU (the LENGTH field) must
be present within a MPEG2-TS frame. So, if only 1 byte of the ULE SNDU get packed into the
remaining MPEG2-TS frame, then it is invalid. Of course, there is no issue regarding 0 byte as that
would be the case of filling MPEG2-TS frame up to its boundary. New ULE SNDU will have to packed
into the next MPEG2-TS frame in that case.
Now the problem with existing code is the interpretation of remainder length when 2 or 3 bytes of ULE
SNDU are packed into the remainder of MPEG2-TS frame. In the 2 bytes case, only the LENGTH field is
available while in the case 3 bytes, only the 1st octet of the 2-octets TYPE field and the LENGTH field
are available. The ule_sndu_remain should carry the value of length of ULE SNDU following the the TYPE
field. Technically, this would mean that remainder byte of ULE SNDU that need to be received is going
to be:
Value(LENGTH) + 2 (We owe 2 bytes of TYPE field here) if only 2 bytes of ULE SNDU is packed (as in the
case of case 0: at line 550).
This is addressed by adding the priv-ule_sndu_remain = priv-ule_sndu_len + 2;
Value(LENGTH) + 1 (We owe 1 byte of TYPE field here) if 3 bytes of ULE SNDU is packed (as in the case of
case 1: at 545).
This is addressed by adding priv-ule_sndu_remain--;
If complete ULE header (= 4 bytes) is available:
priv-ule_sndu_remain = priv-ule_sndu_len; at line 582 takes care of the rest and it works just fine in
the existing code.
Due to the wrong interpretation of remaining length of ULE SNDU when 2 or 3 bytes of ULE SNDU are packed
into a MPEG2-TS frame, the subsequent checking of payload pointer (line 455) always fails leading to
unnecessary packet drops.
Looking back at the fix after a few months, I had trouble understanding how these few lines fixed the
problem at first glance.
@@ -543,6
