Re: [PATCH 1/4] Modifications to the driver mb86a20s
Em 13-05-2011 04:02, Manoel PN escreveu:
Hi to all,
I added some modifications to the driver mb86a20s and would appreciate your
comments.
File: drivers/media/dvb/frontends/mb86a20s.c
-static int debug = 1;
+static int debug = 0;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, Activates frontend debugging (default:0));
How is in the description by default debug is off.
Breaking it into smaller patches it the proper way to get it upstreamed.
However,
each logical change should be sent into its your own patch.
For example, in this case, you should be sending a one-line patch just fixing
the
debug parameter, with a description like:
[PATCH 1/xx] Disable debug by default
The mb86a20s is producing debug information by default. This is not
the expected behavior. Also, the parameter description tells that the
default should be 0. So, fix it.
Signed-off-by: ...
-#define rc(args...) do {
+#define printk_rc(args...) do {
For clarity, only rc is somewhat vague.
The same as above applies here.
The first two changes are OK for me, and I would have applied them if you
were sending one logic change by patch.
+static int mb86a20s_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
Adds the i2c_gate_ctrl to mb86a20s driver.
The mb86a20s has an i2c bus which controls the flow of data to the tuner.
When enabled, the data stream flowing normally through the i2c bus, when
disabled the data stream to the tuner is cut and the i2c bus between mb86a20s
and the tuner goes to tri-state. The data flow between the mb86a20s and its
controller (CPU, USB), is not affected.
In hybrid systems with analog and digital TV, the i2c bus control can be done
in the analog demodulator.
-if (fe-ops.i2c_gate_ctrl)
-fe-ops.i2c_gate_ctrl(fe, 0);
val = mb86a20s_readreg(state, 0x0a) 0xf;
-if (fe-ops.i2c_gate_ctrl)
-fe-ops.i2c_gate_ctrl(fe, 1);
The i2c_gate_ctrl controls the i2c bus of the tuner so does not need to
enable it or disable it here.
Those two changes are moving the responsibility of handling the i2c gate
control to happen outside the demod. If applied as-is, it will break the
boards already supported, causing a regression. One of the rules for a patch
to be applied is that no regressions are accepted. So, if you need to change
it, for whatever reason, you should take a look at the existing cases and
fix the logic (or try to) at the existing drivers.
+for (i = 0; i 20; i++) {
+if (mb86a20s_readreg(state, 0x0a) = 8) break;
+msleep(100);
+}
Waits for the stabilization of the demodulator.
Ok, makes sense to me.
Again, this change should be separate. One of the reasons why we need
separate logical changes is that a patch from the series may cause some
regressions. By having one logical change per patch, fixing the regression
is as simple as reverting one git patch. However, if you mix two different
things at the same patch, reverting it will be very painful.
+static int mb86a20s_get_algo(struct dvb_frontend *fe)
+{
+return DVBFE_ALGO_HW;
+}
Because the mb86a20s_tune function was implemented.
Ok. Same as above: please break mb86a20s_tune() implementation into
a separate patch.
Thanks, best regards,
Manoel.
Signed-off-by: Manoel Pinheiro pinus...@hotmail.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/4] Modifications to the driver mb86a20s
Em 13-05-2011 04:05, Manoel PN escreveu: This patch implements mb86a20s_read_snr and adds mb86a20s_read_ber and mb86a20s_read_ucblocks both without practical utility but that programs as dvbsnoop need. Please try to align comments into up to 75 columns. It looks nicer when people look it into git. Also, please avoid using This patch, as it provides no information. I suggest you to take a look at those kernel guides (there are more good stuff for developers at the kernel trees, but those are the minimal stuff that a developer should know when submitting a patch): http://git.linuxtv.org/media_tree.git?a=blob;f=Documentation/SubmittingPatches;h=689e2371095cc5dfea9927120009341f369159aa;hb=HEAD http://git.linuxtv.org/media_tree.git?a=blob_plain;f=Documentation/CodingStyle;hb=HEAD Signed-off-by: Manoel Pinheiro pinus...@hotmail.com You forgot to attach the patch. -- 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/4] Modifications to the driver mb86a20s
Em 13-05-2011 04:08, Manoel PN escreveu:
This patch implements mb86a20s_read_snr and adds mb86a20s_read_ber and
mb86a20s_read_ucblocks both without practical utility but that programs as
dvbsnoop need.
Same as the prev. patch: break into 75 columns max, and you don't need
to use This patch.
Signed-off-by: Manoel Pinheiro pinus...@hotmail.com
diff --git a/drivers/media/dvb/frontends/mb86a20s.c
b/drivers/media/dvb/frontends/mb86a20s.c
index 0f867a5..0de4abf 100644
--- a/drivers/media/dvb/frontends/mb86a20s.c
+++ b/drivers/media/dvb/frontends/mb86a20s.c
@@ -411,6 +411,56 @@ err:
return rc;
}
+static int mb86a20s_read_snr(struct dvb_frontend *fe, u16 *snr)
+{
+ struct mb86a20s_state *state = fe-demodulator_priv;
+ int i, cnr, val, val2;
+
+ for (i = 0; i 30; i++) {
+ if (mb86a20s_readreg(state, 0x0a) = 2)
+ val = mb86a20s_readreg(state, 0x45); /* read cnr_flag */
+ else
+ val = -1;
+ if (val 0 ((val 6) 1) != 0) {
+ val2 = mb86a20s_readreg(state, 0x46);
+ val = mb86a20s_readreg(state, 0x47);
+ if (val2 =0 val = 0) {
+ cnr = (val2 0x08) | val;
+ if (cnr 0x4cc0) cnr = 0x4cc0;
+ val = ((0x4cc0 - cnr) * 1) / 0x4cc0;
+ val2 = (65535 * val) / 1;
+ *snr = (u16)val2;
+ dprintk(snr=%i, cnr=%i, val=%i\n, val2, cnr,
val);
+ /* reset cnr_counter */
+ val = mb86a20s_readreg(state, 0x45);
+ if (val = 0)
+ {
+ mb86a20s_writereg(state, 0x45, val |
0x10);
+ msleep(5);
+ mb86a20s_writereg(state, 0x45, val
0x6f); /* FIXME: or 0xef ? */
+ }
+ return 0;
+ }
+ }
+ msleep(30);
+ }
+ *snr = 0;
+ dprintk(no signal!\n);
+ return 0;
+}
+static int mb86a20s_read_ber(struct dvb_frontend *fe, u32 *ber)
+{
+ *ber = 0;
+ return 0;
+}
+
+static int mb86a20s_read_ucblocks(struct dvb_frontend *fe, u32 *ucblocks)
+{
+ *ucblocks = 0;
+ return 0;
+}
As you're providing just a stub function there, without an actual
implementation,
the better is to add a FIXME note about that, explaining why you had to add such
function, like:
/*
* FIXME: read_ucblocks callback is needed, as dvbsnoop uses it.
* However, we currently don't know how to actually implement it.
* So add a function that just returns 0 instead.
*/
This way, somebody else with enough information may later implement.
I don't like very much the idea of adding those two stub functions just to
play with dvbsnoop. If dvbsnoop should be working fine without this function,
a patch to dvbsnoop should be sending instead, to proper handle the error
messages generated when a function is not enabled. If otherwise it doesn't
work properly, then you have no choice but to add a real code for it into the
Kernel driver.
+
static int mb86a20s_read_signal_strength(struct dvb_frontend *fe, u16
*strength)
{
struct mb86a20s_state *state = fe-demodulator_priv;
@@ -627,6 +677,9 @@ static struct dvb_frontend_ops mb86a20s_ops = {
.release = mb86a20s_release,
.init = mb86a20s_initfe,
+ .read_snr = mb86a20s_read_snr,
+ .read_ber = mb86a20s_read_ber,
+ .read_ucblocks = mb86a20s_read_ucblocks,
.set_frontend = mb86a20s_set_frontend,
.get_frontend = mb86a20s_get_frontend,
.read_status = mb86a20s_read_status,
--
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 3/4] Modifications to the driver mb86a20s
Em 13-05-2011 04:11, Manoel PN escreveu:
This patch implements some modifications in the function
This patch implements some modifications in the initialization function of
the mb86a20s.
Explanation:
Several registers of mb86a20s can be programmed and to simplify this task and
due to lack of technical literature to elaborate the necessary calculations
was opted by the sending of values already ready for the registers,
eliminating the process of calculations.
Please, don't assume that because you don't have the specs that the driver needs
to be changed. Other people might have the specs.
Also, on several cases, the datasheets describe a common init sequence that
should be done in order to initialize the device, that is on several cases
fixed.
So, on most cases, the better approach is to just put the init sequence into a
table. This also helps to easily fix the init sequence, if the vendor (or new
rev. engineering dumps) find that such default init sequence changed for
whatever
reason (sometimes, vendors add some new init sequences on some errata, to fix
some
hardware bug).
The technique is quite simple: to each register that can be modified an
identification (REG_IDCFG) was attributed and those that do not need
modification was attributed REG_IDCFG_NONE.
The device that uses the demodulator mb86a20s simply informs the registers to
be modified through the configuration parameter of the function
frontend_attach.
Like in the example:
static struct mb86a20s_config_regs_val mb86a20s_config_regs[] = {
{ REG2820_IDCFG, 0x33ddcd },
{ REG50D5_IDCFG, 0x00 },/* use output TS parallel */
{ REG50D6_IDCFG, 0x17 }
};
static struct mb86a20s_config mb86a20s_cfg = {
.demod_address = DEMOD_I2C_ADDR,
.config_regs_size = ARRAY_SIZE(mb86a20s_config_regs),
.config_regs = mb86a20s_config_regs,
};
If there are no registers to be modified to do just this:
static struct mb86a20s_config mb86a20s_cfg = {
.demod_address = DEMOD_I2C_ADDR,
};
static int tbs_dtb08_frontend_attach(struct dvb_usb_adapter *adap)
{
adap-fe = dvb_attach(mb86a20s_attach, mb86a20s_cfg,
adap-dev-i2c_adap);
if (adap-fe) {
frontend_tuner_attach(adap);
}
}
Signed-off-by: Manoel Pinheiro pinus...@hotmail.com
In this specific case, I think you're adding a more complex logic without a good
reason for it. Keep the code simple.
NACK.
regs_init.patch
Commenting attached patches is harder, as emails don't like to reply for it.
The better is to always send patches inlined.
Mauro,
--
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 4/4] Modifications to the driver mb86a20s
Em 13-05-2011 04:13, Manoel PN escreveu: This patch implement changes to the function mb86a20s_read_signal_strength. The original function, binary search, does not work with device dtb08. Hmm... that's interesting. Maybe due to a different mb86a20s chip stepping? I would like to know if this function works. I'll test it when I return back to Brazil. Please send this patch in separate, as a RFC, and keep both methods enabled, printing debug messages. This way, I can test it with the two devices I have, comparing the SNR relations provided by both ways. Thanks, Mauro. -- 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 PATCHES FOR 2.6.39] Fix subdev control enumeration
Em 12-05-2011 22:00, Hans Verkuil escreveu: Hi Mauro, I haven't seen this fix appearing upstream, did it slip through the cracks? I need to check it on my main machine. I'll probably be capable of doing it only after my return back. Regards, Hans On Monday, May 02, 2011 13:19:03 Hans Verkuil wrote: Hi Mauro, This fix is for 2.6.39. Control enumeration for subdev device nodes is broken. The fix is simple and has been tested by Sakari. Regards, Hans The following changes since commit 28df73703e738d8ae7a958350f74b08b2e9fe9ed: Mauro Carvalho Chehab (1): [media] xc5000: Improve it to work better with 6MHz-spaced channels are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git ctrl-fix Hans Verkuil (1): v4l2-subdev: fix broken subdev control enumeration drivers/media/video/v4l2-subdev.c | 14 +++--- 1 files changed, 7 insertions(+), 7 deletions(-) -- 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 -- 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: IR remote control autorepeat / evdev
Em 12-05-2011 08:05, Peter Hutterer escreveu:
On Thu, May 12, 2011 at 03:36:47AM +0200, Mauro Carvalho Chehab wrote:
Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu:
Em 12-05-2011 02:37, Anssi Hannula escreveu:
I don't see any other places:
$ git grep 'REP_PERIOD' .
dvb/dvb-usb/dvb-usb-remote.c: input_dev-rep[REP_PERIOD] =
d-props.rc.legacy.rc_interval;
Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we
should change it to something like 125ms, for example, as 33ms is too
short, as it takes up to 114ms for a repeat event to arrive.
IMO, the enclosed patch should do a better job with repeat events, without
needing to change rc-core/input/event logic.
-
Subject: Use a more consistent value for RC repeat period
From: Mauro Carvalho Chehab mche...@redhat.com
The default REP_PERIOD is 33 ms. This doesn't make sense for IR's,
as, in general, an IR repeat scancode is provided at every 110/115ms,
depending on the RC protocol. So, increase its default, to do a
better job avoiding ghost repeat events.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index f53f9c6..ee67169 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1044,6 +1044,13 @@ int rc_register_device(struct rc_dev *dev)
*/
dev-input_dev-rep[REP_DELAY] = 500;
+/*
+ * As a repeat event on protocols like RC-5 and NEC take as long as
+ * 110/114ms, using 33ms as a repeat period is not the right thing
+ * to do.
+ */
+dev-input_dev-rep[REP_PERIOD] = 125;
+
path = kobject_get_path(dev-dev.kobj, GFP_KERNEL);
printk(KERN_INFO %s: %s as %s\n,
dev_name(dev-dev),
so if I get this right, a XkbSetControls(.. XkbRepeatKeysMask ...) by a
client to set the repeat rate would provide the same solution - for those
clients/devices affected.
Yes, if we preserve the same logic. The above will probably still generate
ghost repeats if the user keeps the IR pressed for a long time, as we're using
a separate timer at the rc-core logic than the one used inside evdev.
The interesting question is how clients would identify the devices that are
affected by this (other than trial and error).
That is easy. I've added a logic that detects it on Xorg evdev on some RFC
patches
I've prepared in the past to allow using a keycode with more than 247 for IR's.
I'll work on a new version for it and submit again when I have some time.
Anyway, I'm enclosing a patch with the old version.
Basically, GetRCInputs.c file adds a logic that returns a list of input devices
that are Remote Controllers, using rc-core.
This logic inside evdev gets the RC devices and adds a flag identifying them
as such:
+/* Check if the device is a remote controller */
+pRCDevList = GetRCInputDevices(NumDevices);
+for (i = 0; i NumDevices; i++) {
+if (!strcmp(device, pRCDevList[i].InputName)) {
+ pEvdev-flags |= EVDEV_RC_EVENTS;
+ break;
+}
+}
Thanks,
Mauro
-
diff --git a/src/GetRCInputs.c b/src/GetRCInputs.c
new file mode 100644
index 000..0e03e3a
--- /dev/null
+++ b/src/GetRCInputs.c
@@ -0,0 +1,358 @@
+/*
+ * Copyright © 2011 Red Hat, Inc.
+ *
+ * Permission to use, copy, modify, distribute, and sell this software
+ * and its documentation for any purpose is hereby granted without
+ * fee, provided that the above copyright notice appear in all copies
+ * and that both that copyright notice and this permission notice
+ * appear in supporting documentation, and that the name of Red Hat
+ * not be used in advertising or publicity pertaining to distribution
+ * of the software without specific, written prior permission. Red
+ * Hat makes no representations about the suitability of this software
+ * for any purpose. It is provided as is without express or implied
+ * warranty.
+ *
+ * THE AUTHORS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
+ * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN
+ * NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
+ * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS
+ * OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT,
+ * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ * Author:
+ * Mauro Carvalho Chehab mche...@redhat.com
+ */
+
+#ifdef HAVE_CONFIG_H
+#include config.h
+#endif
+
+#include evdev.h
+
+#include X11/keysym.h
+#include X11/extensions/XI.h
+
+#include ctype.h
+#include errno.h
+#include fcntl.h
+#include stdio.h
+#include unistd.h
+#include stdlib.h
+#include string.h
+#include linux/input.h
+#include sys/ioctl.h
+#include dirent.h
+
+#include xf86.h
+#include xf86Xinput.h
+#include exevents.h
+#include xorgVersion.h
+#include xkbsrv.h
+
+struct UEvents {
+char *key;
+char *value;
+
Re: dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API
Em 12-05-2011 09:12, HoP escreveu: 2011/5/12 Bjørn Mork bj...@mork.no: Andreas Oberritter o...@linuxtv.org writes: Please try the patches submitted for testing: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31194.html Ah, great! Thanks. Nothing better than a problem already solved. Not solved. Andreas did an attempt to solve it (at least as far as I know patches not get accepted yet), so please report your result of testing. The better is reply to the patches with a Tested-by: This helps me to better handle the patches when analyzing them. PS.: I shouldn't be touching on it until next week, as it is harder for me to work remotely, and I can't test it from here. Mauro. -- 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: Problems of Pinnacle PCTV Hybrid pro stick in linux
Em 12-05-2011 11:12, a baffian escreveu: Hello all Is there anyone could find the source of problems described below? http://daftar.minidns.net/pctv/problem.html Most of the comments and logs there provide not much help. As I told you before, you're mixing clearly userspace issues or limitations with kernel-related ones. For example, there's nothing we can do at driver level to make kaffeine to perform better when decoding an MPEG-2 stream at full screen mode. This is probably either a performance issue with your GPU card or it is just that you're using a software decoder for it, on a slow CPU. Some applications allow, with a few GPU types, to run the MPEG-2 decoder inside the GPU. Yet, there's one relevant information there: 3- And even with kaffeine, the only way that i could watch some TV, was in this manner: Before this DVB-stick i inserted another DVB-USB stick in another linux computer and scan the channels with kaffeine and after finding the channels, quit the kaffeine and copy its database files ( $HOME/.kde/share/apps/kaffeine/* ) into the testing computer for pinnacle DVB-USB hybrid stick. After that copying, i could run kaffeine on the pinnacle DVB and without scanning, thus i had a table of channels and in its main window and when i clicked on a channel, that channel was shown. You mentioned that you did another dvb stick worked, but on another computer. Why such dvb stick didn't work at the computer you tested your Pinnacle device? Also, does the working stick is capable of getting the dvb channels using the scan tool provided at http://linuxtv.org/hg/dvb-apps? If so, please provide us the dmesg produced with the working card and the scan results (with -v, in order to put dvb scan into verbose mode), and the same info with the broken card. Thanks, Mauro On Mon, May 9, 2011 at 3:08 PM, a baffian mjnh...@gmail.com wrote: Hello all, Can anyone help to solve the problems of linux driver of Pinnacle PCTV Hybrid pro stick ? It is an em28xx based hybride (digital and analog TV) USB adapter. i wrote the complete story of my experiences with it, and its problems in http://daftar.minidns.net/pctv/problem.html Good Luck -- 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
[PATCHv2] v4l: Add M420 format definition
From: Hans de Goede hdego...@redhat.com
M420 is an hybrid YUV 4:2:2 packet/planar format. Two Y lines are
followed by an interleaved U/V line.
Signed-off-by: Hans de Goede hdego...@redhat.com
[laurent.pinch...@ideasonboard.com: split into v4l/uvcvideo patches]
[laurent.pinch...@ideasonboard.com: add documentation]
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Documentation/DocBook/media-entities.tmpl |1 +
Documentation/DocBook/v4l/pixfmt-m420.xml | 147 +
Documentation/DocBook/v4l/pixfmt.xml |1 +
Documentation/DocBook/v4l/videodev2.h.xml |1 +
include/linux/videodev2.h |1 +
5 files changed, 151 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/v4l/pixfmt-m420.xml
diff --git a/Documentation/DocBook/media-entities.tmpl
b/Documentation/DocBook/media-entities.tmpl
index 7a95708..c8abb23 100644
--- a/Documentation/DocBook/media-entities.tmpl
+++ b/Documentation/DocBook/media-entities.tmpl
@@ -270,6 +270,7 @@
!ENTITY sub-write SYSTEM v4l/func-write.xml
!ENTITY sub-io SYSTEM v4l/io.xml
!ENTITY sub-grey SYSTEM v4l/pixfmt-grey.xml
+!ENTITY sub-m420 SYSTEM v4l/pixfmt-m420.xml
!ENTITY sub-nv12 SYSTEM v4l/pixfmt-nv12.xml
!ENTITY sub-nv12m SYSTEM v4l/pixfmt-nv12m.xml
!ENTITY sub-nv12mt SYSTEM v4l/pixfmt-nv12mt.xml
diff --git a/Documentation/DocBook/v4l/pixfmt-m420.xml
b/Documentation/DocBook/v4l/pixfmt-m420.xml
new file mode 100644
index 000..ce4bc01
--- /dev/null
+++ b/Documentation/DocBook/v4l/pixfmt-m420.xml
@@ -0,0 +1,147 @@
+refentry id=V4L2-PIX-FMT-M420
+ refmeta
+ refentrytitleV4L2_PIX_FMT_M420 ('M420')/refentrytitle
+ manvol;
+ /refmeta
+ refnamediv
+ refnameconstantV4L2_PIX_FMT_M420/constant/refname
+ refpurposeFormat with frac12; horizontal and vertical chroma
+ resolution, also known as YUV 4:2:0. Hybrid plane line-interleaved
+ layout./refpurpose
+ /refnamediv
+ refsect1
+ titleDescription/title
+
+ paraM420 is a YUV format with frac12; horizontal and vertical chroma
+ subsampling (YUV 4:2:0). Pixels are organized as interleaved luma and
+ chroma planes. Two lines of luma data are followed by one line of chroma
+ data./para
+ paraThe luma plane has one byte per pixel. The chroma plane contains
+ interleaved CbCr pixels subsampled by frac12; in the horizontal and
+ vertical directions. Each CbCr pair belongs to four pixels. For example,
+Cbsubscript0/subscript/Crsubscript0/subscript belongs to
+Y'subscript00/subscript, Y'subscript01/subscript,
+Y'subscript10/subscript, Y'subscript11/subscript./para
+
+ paraAll line lengths are identical: if the Y lines include pad bytes
+ so do the CbCr lines./para
+
+ example
+ titleconstantV4L2_PIX_FMT_M420/constant 4 times; 4
+pixel image/title
+
+ formalpara
+ titleByte Order./title
+ paraEach cell is one byte.
+ informaltable frame=none
+ tgroup cols=5 align=center
+ colspec align=left colwidth=2* /
+ tbody valign=top
+ row
+ entrystartnbsp;+nbsp;0:/entry
+ entryY'subscript00/subscript/entry
+ entryY'subscript01/subscript/entry
+ entryY'subscript02/subscript/entry
+ entryY'subscript03/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;4:/entry
+ entryY'subscript10/subscript/entry
+ entryY'subscript11/subscript/entry
+ entryY'subscript12/subscript/entry
+ entryY'subscript13/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;8:/entry
+ entryCbsubscript00/subscript/entry
+ entryCrsubscript00/subscript/entry
+ entryCbsubscript01/subscript/entry
+ entryCrsubscript01/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;16:/entry
+ entryY'subscript20/subscript/entry
+ entryY'subscript21/subscript/entry
+ entryY'subscript22/subscript/entry
+ entryY'subscript23/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;20:/entry
+ entryY'subscript30/subscript/entry
+ entryY'subscript31/subscript/entry
+ entryY'subscript32/subscript/entry
+ entryY'subscript33/subscript/entry
+ /row
+ row
+ entrystartnbsp;+nbsp;24:/entry
+ entryCbsubscript10/subscript/entry
+
Re: DVB nGene CI : TS Discontinuities issues
Issa Gorissen writes:
On 11/05/11 15:12, Issa Gorissen wrote:
From: Ralph Metzler r...@metzlerbros.de
Issa Gorissen writes:
Could you please take a look at the cxd2099 issues ?
I have attached a version with my changes. I have tested a lot of
different settings with the help of the chip datasheet.
Scrambled programs are not handled correctly. I don't know if it is the
TICLK/MCLKI which is too high or something, or the sync detector ?
Also,
as we have to set the TOCLK to max of 72MHz, there are way too much
null
packets added. Is there a way to solve this ?
I do not have any cxd2099 issues.
I have a simple test program which includes a 32bit counter as payload
and can pump data through the CI with full speed and have no packet
loss. I only tested decoding with an ORF stream and an Alphacrypt CAM
but also had no problems with this.
Please take care not to write data faster than it is read. Starting two
dds will not guarantee this. To be certain you could write a small
program which never writes more packets than input buffer size minus
the number of read packets (and minus the stuffing null packets on ngene).
Before blaming packet loss on the CI data path also please make
certain that you have no buffer overflows in the input part of
the sec device.
In the ngene driver you can e.g. add a printk in tsin_exchange():
if (dvb_ringbuffer_free(dev-tsin_rbuf) len) {
...
} else
printk (buffer overflow \n);
Regards,
Ralph
Ralph,
OB Done some more tests, from by test tool, I found out that I have to skip
(rather often) bytes to find the sync one when reading from sec0. I
thought I only needed to do that at the start of the stream, not in the
middle; because I always read/write 188 bytes from it.
This should not happen.
Is there any difference regarding this alignment problem if the CI is inserted
or not?
Could you share your test code ? I'm finding it difficult to interact
with this sec0 implementation.
Below my test code. You just need to adjust the device name.
I had it running for an hour and had no discontinuities (except at
restarts, might have to look into buffer flushing).
I tested it with nGene and Octopus boards on an Asus ION2 board and on a
Marvell Kirkwood based ARM board.
Btw., what hardware exactly are you using?
Which DVB card version, CI type, motherboard chipset?
Regards,
Ralph
#include stdio.h
#include ctype.h
#include string.h
#include unistd.h
#include sys/types.h
#include sys/stat.h
#include stdint.h
#include stdlib.h
#include fcntl.h
#include sys/ioctl.h
#include pthread.h
uint8_t fill[188]={0x47, 0x1f, 0xff, 0x10,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff };
uint8_t ts[188]={0x47, 0x0a, 0xaa, 0x00 };
void proc_buf(uint8_t *buf, uint32_t *d)
{
uint32_t c;
if (buf[1]==0x1f buf[2]==0xff) {
//printf(fill\n);
return;
}
if (buf[1]==0x9f buf[2]==0xff) {
//printf(fill\n);
return;
}
if (buf[1]!=0x0a || buf[2]!=0xaa)
return;
c=(buf[4]24)|(buf[5]16)|(buf[6]8)|buf[7];
if (c!=*d) {
printf(CONT ERROR %08x %08x\n, c, *d);
*d=c;
} else {
if (memcmp(ts+8, buf+8, 180))
printf(error\n);
if (!(c0x))
printf(R %d\n, c);
}
(*d)++;
}
void *get_ts(void *a)
{
uint8_t buf[188*1024];
int len, off;
int fdi=open(/dev/dvb/adapter4/sec0, O_RDONLY);
uint32_t d=0;
while (1) {
len=read(fdi, buf, 188*1024);
if (len0)
continue;
if (buf[0]!=0x47) { //should not happen
read(fdi, buf, 1);
continue;
}
for (off=0; offlen; off+=188) {
Re: [PATCH 0/2] V4L: Extended crop/compose API
Hi Tomasz and Hans,
First of all, apologies for the late reply.
On Saturday 07 May 2011 13:52:25 Hans Verkuil wrote:
On Thursday, May 05, 2011 11:39:54 Tomasz Stanislawski wrote:
Hello everyone,
This patch-set introduces new ioctls to V4L2 API. The new method for
configuration of cropping and composition is presented.
This is the third version of extended crop/compose RFC. List of applied
changes:
- reduced number of hints and its semantics to be more practical and less
restrictive
- combined EXTCROP and COMPOSE ioctls into VIDIOC_{S/G}_SELECTION
- introduced crop and compose targets
- introduced try flag that prevents passing configuration to a hardware
- added usage examples
RFC
1. Introduction
There is some confusion in understanding of cropping in current version
of V4L2. In a case of Capture Devices, cropping refers to choosing only
a part of input data stream, and processing it, and storing it in a
memory buffer. The buffer is fully filled by data. There is now generic
API to choose only a part of an image buffer for being updated by
hardware.
In case of OUTPUT devices, the whole content of a buffer is passed to
hardware and to output display. Cropping means selecting only a part of
an output display/signal. It is not possible to choose only a part of
the image buffer to be processed.
The overmentioned flaws in cropping API were discussed in post:
http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/2
8945
A solution was proposed during brainstorming session in Warsaw.
At first, the distinction between cropping and composing was stated. The
cropping operation means choosing only part of input data by bounding it
by a cropping rectangle. All data outside cropping area must be
discarded. On the other hand, composing means pasting processed data
into rectangular part of data sink. The sink may be output device, user
buffer, etc.
Two concepts were introduced:
Cropping rectangle: a) for input devices, a part of input data selected
by hardware from input stream and pasted to an image buffer b) for
output devices, a part of image buffer to be passed by hardware to
output stream
Composing rectangle: a) for input devices, a part of a image buffer that
is filled by hardware b) for output devices, an area on output device
where image is inserted
The configuration of composing/cropping areas is the subject of this
document.
2. Data structures.
The structure v4l2_crop used by current API lacks any place for further
extensions. Therefore new and more generic structure is proposed.
struct v4l2_selection {
u32 type;
u32 target;
u32 flags;
struct v4l2_rect r;
u32 reserved[9];
};
Where,
type - type of buffer queue: V4L2_BUF_TYPE_VIDEO_CAPTURE,
V4L2_BUF_TYPE_VIDEO_OUTPUT, etc.
target - choose one of cropping/composing rectangles
flags- control over coordinates adjustments
r- selection rectangle
reserved - place for further extensions, adjust struct size to 64 bytes
3. Crop/Compose ioctl.
New ioctls are added to V4L2.
Name
VIDIOC_G_SELECTION - get crop/compose rectangles from a driver
Synopsis
int ioctl(fd, VIDIOC_G_SELECTION, struct v4l2_selection *s)
Description:
The ioctl is used to query selection rectangles. Currently, it involves
only cropping and composing ones. To query cropping rectangle application
must fill selection::type with respective stream type from
V4L2_BUF_TYPE_VIDEO_* family. Next, v4l2_selection::target must be
field with desired target type. Please refer to section Target for
details. On success the rectangle is returned in v4l2_selection::r
field. Field v4l2_selection::flags and v4l2_selection::reserved are
ignored and they must be filled with zeros.
Return value
On success 0 is returned, on error -1 and the errno variable is set
appropriately:
EINVAL - incorrect buffer type, incorrect/not supported target
Looks fine.
-
Name
VIDIOC_S_SELECTION - set cropping rectangle on an input of a device
Synopsis
int ioctl(fd, VIDIOC_S_SELECTION, struct v4l2_selection *s)
Description:
The ioctl is used to configure a selection rectangle. An application
fills v4l2_selection::type field to specify an adequate stream type.
Next, the v4l2_selection::field target is filled. Basically, an
application choose between cropping or composing rectangle. Please refer
to section Targets for more details. Finally, structure
v4l2-selection::r is filled with suggested coordinates. The coordinates
are expressed in driver-dependant units.
What kind of driver-dependant units do you think will be used in
[PATCH 1/1] v4l: Document EACCES in VIDIOC_G_CTRL and VIDIOC_G_EXT_CTRLS
VIDIOC_G_CTRL and VIDIOC_G_EXT_CTRLS return EACCES when setting a read-only control or getting a write-only control. Document this. Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com --- Documentation/DocBook/v4l/vidioc-g-ctrl.xml |7 +++ Documentation/DocBook/v4l/vidioc-g-ext-ctrls.xml |7 +++ 2 files changed, 14 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/v4l/vidioc-g-ctrl.xml b/Documentation/DocBook/v4l/vidioc-g-ctrl.xml index 8b5e6ff..5146d00 100644 --- a/Documentation/DocBook/v4l/vidioc-g-ctrl.xml +++ b/Documentation/DocBook/v4l/vidioc-g-ctrl.xml @@ -117,6 +117,13 @@ because another applications took over control of the device function this control belongs to./para /listitem /varlistentry + varlistentry + termerrorcodeEACCES/errorcode/term + listitem + paraAttempt to set a read-only control or to get a + write-only control./para + /listitem + /varlistentry /variablelist /refsect1 /refentry diff --git a/Documentation/DocBook/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/v4l/vidioc-g-ext-ctrls.xml index 3aa7f8f..5e73517 100644 --- a/Documentation/DocBook/v4l/vidioc-g-ext-ctrls.xml +++ b/Documentation/DocBook/v4l/vidioc-g-ext-ctrls.xml @@ -294,6 +294,13 @@ The field structfieldsize/structfield is set to a value that is enough to store the payload and this error code is returned./para /listitem /varlistentry + varlistentry + termerrorcodeEACCES/errorcode/term + listitem + paraAttempt to try or set a read-only control or to get a + write-only control./para + /listitem + /varlistentry /variablelist /refsect1 /refentry -- 1.7.2.5 -- 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] [media] at91: add Atmel Image Sensor Interface (ISI) support
On Thu, 12 May 2011, Josh Wu wrote: This patch is to enable Atmel Image Sensor Interface (ISI) driver support. - Using soc-camera framework with videobuf2 dma-contig allocator - Supporting video streaming of YUV packed format - Tested on AT91SAM9M10G45-EK with OV2640 Signed-off-by: Josh Wu josh...@atmel.com --- base on branch staging/for_v2.6.40 arch/arm/mach-at91/include/mach/at91_isi.h | 454 drivers/media/video/Kconfig| 10 + drivers/media/video/Makefile |1 + drivers/media/video/atmel-isi.c| 1089 4 files changed, 1554 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-at91/include/mach/at91_isi.h create mode 100644 drivers/media/video/atmel-isi.c diff --git a/arch/arm/mach-at91/include/mach/at91_isi.h b/arch/arm/mach-at91/include/mach/at91_isi.h new file mode 100644 index 000..3219358 --- /dev/null +++ b/arch/arm/mach-at91/include/mach/at91_isi.h @@ -0,0 +1,454 @@ +/* + * Register definitions for the Atmel Image Sensor Interface. Why do you put ISI register definitions in a header under arch/arm/...? It seems only your driver needs them. Then at most put it directly under drivers/media/video or even consider inlining all these definitions in the driver itself, although, I admit, in such quantities it probably looks cleaner in a separate header. But please put it under drivers/... Any common stuff, that you will need in your board code to configure the driver should go in a header under include/media/. + * + * Copyright (C) 2011 Atmel Corporation Consider adding an author with an email address? + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#ifndef __AT91_ISI_H__ +#define __AT91_ISI_H__ + +#include linux/videodev2.h +#include linux/i2c.h +#include media/v4l2-device.h +#include media/v4l2-common.h +#include media/v4l2-ioctl.h +#include media/v4l2-chip-ident.h None of these headers seems to be needed in the header itself. OTOH, you do use __raw_readl()/writel(), which need something like linux/io.h. But you'll, probably, remove those __raw_* from the header. + +/* ISI register offsets */ +#define ISI_CR1 0x +#define ISI_CR2 0x0004 +#define ISI_SR 0x0008 +#define ISI_IER 0x000c +#define ISI_IDR 0x0010 +#define ISI_IMR 0x0014 +#define ISI_PSIZE0x0020 +#define ISI_PDECF0x0024 +#define ISI_PPFBD0x0028 +#define ISI_CDBA 0x002c +#define ISI_Y2R_SET0 0x0030 +#define ISI_Y2R_SET1 0x0034 +#define ISI_R2Y_SET0 0x0038 +#define ISI_R2Y_SET1 0x003c +#define ISI_R2Y_SET2 0x0040 + +/* ISI_V2 register offsets */ +#define ISI_V2_CFG1 0x +#define ISI_V2_CFG2 0x0004 +#define ISI_V2_PSIZE 0x0008 +#define ISI_V2_PDECF 0x000c +#define ISI_V2_Y2R_SET0 0x0010 +#define ISI_V2_Y2R_SET1 0x0014 +#define ISI_V2_R2Y_SET0 0x0018 +#define ISI_V2_R2Y_SET1 0x001C +#define ISI_V2_R2Y_SET2 0x0020 +#define ISI_V2_CTRL 0x0024 +#define ISI_V2_STATUS0x0028 +#define ISI_V2_INTEN 0x002C +#define ISI_V2_INTDIS0x0030 +#define ISI_V2_INTMASK 0x0034 +#define ISI_V2_DMA_CHER 0x0038 +#define ISI_V2_DMA_CHDR 0x003C +#define ISI_V2_DMA_CHSR 0x0040 +#define ISI_V2_DMA_P_ADDR0x0044 +#define ISI_V2_DMA_P_CTRL0x0048 +#define ISI_V2_DMA_P_DSCR0x004C +#define ISI_V2_DMA_C_ADDR0x0050 +#define ISI_V2_DMA_C_CTRL0x0054 +#define ISI_V2_DMA_C_DSCR0x0058 + +/* Bitfields in CR1 */ +#define ISI_RST_OFFSET 0 +#define ISI_RST_SIZE 1 +#define ISI_DIS_OFFSET 1 +#define ISI_DIS_SIZE 1 +#define ISI_HSYNC_POL_OFFSET 2 +#define ISI_HSYNC_POL_SIZE 1 +#define ISI_VSYNC_POL_OFFSET 3 +#define ISI_VSYNC_POL_SIZE
AW: Remote control not working for Terratec Cinergy C (2.6.37 Mantis driver)
Hello, This patch is a rework of a old patch I've posted some time ago. It adds support for Remote-Control in the mantis driver and implements the new rc-API. The patch enables rc for the cards - vp1041 - vp2033 - vp2040 It's only tested with a Terratec Cinergy S2 HD. Would be nice to get some Feedback. Regards Chris mantis_ir.patch Description: Binary data
Re: [PATCHv2] v4l: Add M420 format definition
Hi Guennadi, On Friday 13 May 2011 14:01:32 Guennadi Liakhovetski wrote: Couldn't spot any problems with the patch except: On Fri, 13 May 2011, Laurent Pinchart wrote: From: Hans de Goede hdego...@redhat.com M420 is an hybrid YUV 4:2:2 packet/planar format. Two Y lines are Didn't you mean 4:2:0? Yep. I'll fix that. Thanks for the review. And if I wanted to nit-pick, I think, it should be a hybrid, I'm not a native-speaker though;) I'll fix that too :-) -- Regards, Laurent Pinchart -- 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 FOR 2.6.40] v4l2 subdev driver for Samsung S5P MIPI CSI receiver
Hi Mauro, The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung s5p-csis Sylwester Nawrocki (3): v4l: Add V4L2_MBUS_FMT_JPEG_1X8 media bus format v4l: Move s5p-fimc driver into Video capture devices v4l: Add v4l2 subdev driver for S5P/EXYNOS4 MIPI-CSI receivers It's a new driver for MIPI CSI receiver available in S5PVxxx/EXYNOS4 SoCs. The first patch adds definition of a media bus code for JPEG format. I've done three further driver amendments comparing to the last (v5) version posted on the mailing lists, i.e.: - slightly improved description of struct csis_state - moved the pad number check from __s5pcsis_get_format directly to set_fmt/get_fmt pad level operation handlers - replaced __init attribute of s5pcsis_probe() with __devinit and added __devexit for s5pcsis_remove() Gitweb: http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/s5p-csis Documentation/DocBook/v4l/subdev-formats.xml | 46 ++ drivers/media/video/Kconfig | 28 +- drivers/media/video/s5p-fimc/Makefile|6 +- drivers/media/video/s5p-fimc/mipi-csis.c | 725 ++ drivers/media/video/s5p-fimc/mipi-csis.h | 22 + include/linux/v4l2-mediabus.h|3 + 6 files changed, 820 insertions(+), 10 deletions(-) create mode 100644 drivers/media/video/s5p-fimc/mipi-csis.c create mode 100644 drivers/media/video/s5p-fimc/mipi-csis.h -- Regards, Sylwester Nawrocki Samsung Poland RD Center -- 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: [RFC] drm: add overlays as first class KMS objects
Hi Jesse, Discussion here in Budapest with v4l and embedded graphics folks was extremely fruitful. A few quick things to take away - I'll try to dig through all the stuff I've learned more in-depth later (probably in a blog post or two): - embedded graphics is insane. The output routing/blending/whatever currently shipping hw can do is crazy and kms as-is is nowhere near up to snuff to support this. We've discussed omap4 and a ti chip targeted at video surveillance as use cases. I'll post block diagrams and explanations some when later. - we should immediately stop to call anything an overlay. It's a confusing concept that has a different meaning in every subsystem and for every hw manufacturer. More sensible names are dma fifo engines for things that slurp in planes and make them available to the display subsystem. Blend engines for blocks that take multiple input pipes and overlay/underlay/blend them together. Display subsytem/controller for the aggregate thing including encoders/resizers/outputs and especially the crazy routing network that connects everything. Most of the discussion centered around clearing up the confusion and reaching a mutual understanding between desktop graphics, embedded graphics and v4l people. Two rough ideas emerged though: 1) Splitting the crtc object into two objects: crtc with associated output mode (pixel clock, encoders/connectors) and dma engines (possibly multiple) that feed it. omap 4 has essentially just 4 dma engines that can be freely assigned to the available outputs, so a distinction between normal crtcs and overlay engines just does not make sense. There's the major open question of where to put the various attributes to set up the output pipeline. Also some of these attributes might need to be changed atomicly together with pageflips on a bunch of dma engines all associated with the same crtc on the next vsync, e.g. output position of an overlaid video buffer. 2) The above should be good enough to support halfway sane chips like omap4. But hw with more insane routing capabilities that can also use v4l devices as sources (even video input connectors) media controller might be a good fit. Media controller is designed to expose multimedia pipe routing across different subsystem. But the first version, still marked experimental, only got merged in .39. We discussed a few ideas as how to splice media controller into kms but nothing clear emerged. So a possible kms integration with media controller is rather far away. Yours, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch -- 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] fm801: clean-up radio-related Kconfig
Change the weird SND_FM801_TEA575X_BOOL define in Kconfig to SND_FM801_RADIO
and remove TEA575X_RADIO define from fm801.c.
Also update help text to include all supported cards.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-2.6.39-rc2-/sound/pci/Kconfig 2011-05-13 19:36:27.0 +0200
+++ linux-2.6.39-rc2/sound/pci/Kconfig 2011-05-13 19:23:00.0 +0200
@@ -554,18 +554,18 @@ config SND_FM801
To compile this driver as a module, choose M here: the module
will be called snd-fm801.
-config SND_FM801_TEA575X_BOOL
+config SND_FM801_RADIO
bool ForteMedia FM801 + TEA5757 tuner
depends on SND_FM801
depends on VIDEO_V4L2=y || VIDEO_V4L2=SND_FM801
help
Say Y here to include support for soundcards based on the ForteMedia
- FM801 chip with a TEA5757 tuner connected to GPIO1-3 pins (Media
- Forte SF256-PCS-02) into the snd-fm801 driver.
+ FM801 chip with a TEA5757 tuner (MediaForte SF256-PCS, SF256-PCP and
+ SF64-PCR) into the snd-fm801 driver.
config SND_TEA575X
tristate
- depends on SND_FM801_TEA575X_BOOL || SND_ES1968_RADIO
+ depends on SND_FM801_RADIO || SND_ES1968_RADIO
default SND_FM801 || SND_ES1968
source sound/pci/hda/Kconfig
--- linux-2.6.39-rc2-/sound/pci/fm801.c 2011-05-13 19:39:23.0 +0200
+++ linux-2.6.39-rc2/sound/pci/fm801.c 2011-05-13 19:22:20.0 +0200
@@ -36,9 +36,8 @@
#include asm/io.h
-#ifdef CONFIG_SND_FM801_TEA575X_BOOL
+#ifdef CONFIG_SND_FM801_RADIO
#include sound/tea575x-tuner.h
-#define TEA575X_RADIO 1
#endif
MODULE_AUTHOR(Jaroslav Kysela pe...@perex.cz);
@@ -196,7 +195,7 @@ struct fm801 {
spinlock_t reg_lock;
struct snd_info_entry *proc_entry;
-#ifdef TEA575X_RADIO
+#ifdef CONFIG_SND_FM801_RADIO
struct snd_tea575x tea;
#endif
@@ -715,7 +714,7 @@ static int __devinit snd_fm801_pcm(struc
* TEA5757 radio
*/
-#ifdef TEA575X_RADIO
+#ifdef CONFIG_SND_FM801_RADIO
/* GPIO to TEA575x maps */
struct snd_fm801_tea575x_gpio {
@@ -1150,7 +1149,7 @@ static int snd_fm801_free(struct fm801 *
outw(cmdw, FM801_REG(chip, IRQ_MASK));
__end_hw:
-#ifdef TEA575X_RADIO
+#ifdef CONFIG_SND_FM801_RADIO
snd_tea575x_exit(chip-tea);
#endif
if (chip-irq = 0)
@@ -1229,7 +1228,7 @@ static int __devinit snd_fm801_create(st
snd_card_set_dev(card, pci-dev);
-#ifdef TEA575X_RADIO
+#ifdef CONFIG_SND_FM801_RADIO
chip-tea.private_data = chip;
chip-tea.ops = snd_fm801_tea_ops;
sprintf(chip-tea.bus_info, PCI:%s, pci_name(pci));
--
Ondrej Zary
--
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: [ANNOUNCE] New OMAP4 V4L2 Camera Project started
On Thu, 12 May 2011, Aguirre, Sergio wrote: Hi all, Just to let you know that I've just officially registered for a new project in the Pandaboard.org portal for OMAP4 v4l2 camera support. You can find it here: http://omiio.org/content/omap4-v4l2-camera And also, you can find the actual Gitorious project with the code here: https://www.gitorious.org/omap4-v4l2-camera If anyone is interested in contributing for this project, please let me know, so I can add you as a contributor to the project. I hope you're not going to keep an out-of-tree development for too long and are going to submit your code upstream as soon as possible, and will try to post your updates to the mainline as often as possible to minimize the fork. 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
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri May 13 19:00:32 CEST 2011 git hash:f9b51477fe540fb4c65a05027fdd6f2ecce4db3b gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification 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: [PATCH] [media] at91: add Atmel Image Sensor Interface (ISI) support
On 05/13/2011 03:50 PM, Guennadi Liakhovetski wrote: On Thu, 12 May 2011, Josh Wu wrote: This patch is to enable Atmel Image Sensor Interface (ISI) driver support. - Using soc-camera framework with videobuf2 dma-contig allocator - Supporting video streaming of YUV packed format - Tested on AT91SAM9M10G45-EK with OV2640 Signed-off-by: Josh Wujosh...@atmel.com --- ... diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index a10e4c3..f734a65 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -166,6 +166,7 @@ obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o obj-$(CONFIG_VIDEO_OMAP1) += omap1_camera.o obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc/ [OT] hm, wow, who has decided to put a generic V4L driver (set) in the Makefile together with other soc-camera drivers? It has to be converted now;) In fact I've already converted that driver, but soc-camera wasn't unfortunately my choice, just the media controller ;-) I'll probably move the entry when preparing upstream patches, it just doesn't feel safe here;) +obj-$(CONFIG_VIDEO_ATMEL_ISI) += atmel-isi.o obj-$(CONFIG_ARCH_DAVINCI) += davinci/ -- Regards, Sylwester Nawrocki -- 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] [media] at91: add Atmel Image Sensor Interface (ISI) support
On Fri, 13 May 2011, Sylwester Nawrocki wrote: On 05/13/2011 03:50 PM, Guennadi Liakhovetski wrote: On Thu, 12 May 2011, Josh Wu wrote: This patch is to enable Atmel Image Sensor Interface (ISI) driver support. - Using soc-camera framework with videobuf2 dma-contig allocator - Supporting video streaming of YUV packed format - Tested on AT91SAM9M10G45-EK with OV2640 Signed-off-by: Josh Wujosh...@atmel.com --- ... diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index a10e4c3..f734a65 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -166,6 +166,7 @@ obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)+= sh_mobile_ceu_camera.o obj-$(CONFIG_VIDEO_OMAP1)+= omap1_camera.o obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc/ [OT] hm, wow, who has decided to put a generic V4L driver (set) in the Makefile together with other soc-camera drivers? It has to be converted now;) In fact I've already converted that driver, but soc-camera wasn't unfortunately my choice, just the media controller ;-) I'll probably move the entry when preparing upstream patches, it just doesn't feel safe here;) Yeah, you're right - it's a boilerplate here, nothing like safe;) 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
[PATCH RFC] radio-sf16fmr2: convert to generic TEA575x interface
Hello,
the SF16-FMR2 radio card is basically a TEA5757 tuner connected to ISA bus but
the driver currently uses its own implementation. I converted the driver to
use generic tea575x-tuner implementation (see patch below) and it works fine.
But the tea575x-tuner module is located in /sound/i2c/other and the
corresponding Kconfig in /sound/pci. Should it be moved
to /drivers/media/radio or better leave it as is?
The card can optionally be equipped with PT2254A volume control (equivalent of
TC9154AP) so I need to extend tea575x-tuner to allow adding additional V4L2
controls (and add one if the chip is present). Is this OK or should be
something like v4l2_subdev used somehow?
(My card does not have the PT2254A chip so that code is untested.)
--- linux-2.6.39-rc2-/include/sound/tea575x-tuner.h 2011-05-13
19:39:23.0 +0200
+++ linux-2.6.39-rc2/include/sound/tea575x-tuner.h 2011-05-14
00:14:23.0 +0200
@@ -54,6 +54,11 @@ struct snd_tea575x {
void *private_data;
u8 card[32];
u8 bus_info[32];
+ /* card driver can provide additional controls (e.g. volume) */
+ struct v4l2_queryctrl *extra_ctrls; /* array of controls */
+ int num_extra_ctrls;/* number of additional controls */
+ int (*g_extra_ctrl)(struct file *file, void *fh, struct v4l2_control
*a);
+ int (*s_extra_ctrl)(struct file *file, void *fh, struct v4l2_control
*a);
};
int snd_tea575x_init(struct snd_tea575x *tea);
--- linux-2.6.39-rc2-/sound/i2c/other/tea575x-tuner.c 2011-05-13
19:39:23.0 +0200
+++ linux-2.6.39-rc2/sound/i2c/other/tea575x-tuner.c2011-05-13
21:35:57.0 +0200
@@ -269,6 +269,7 @@ static int vidioc_s_audio(struct file *f
static int vidioc_queryctrl(struct file *file, void *priv,
struct v4l2_queryctrl *qc)
{
+ struct snd_tea575x *tea = video_drvdata(file);
int i;
for (i = 0; i ARRAY_SIZE(radio_qctrl); i++) {
@@ -278,6 +279,13 @@ static int vidioc_queryctrl(struct file
return 0;
}
}
+ for (i = 0; i tea-num_extra_ctrls; i++) {
+ if (qc-id qc-id == tea-extra_ctrls[i].id) {
+ memcpy(qc, (tea-extra_ctrls[i]),
+ sizeof(*qc));
+ return 0;
+ }
+ }
return -EINVAL;
}
@@ -291,6 +299,10 @@ static int vidioc_g_ctrl(struct file *fi
ctrl-value = tea-mute;
return 0;
}
+
+ if (tea-g_extra_ctrl)
+ return tea-g_extra_ctrl(file, priv, ctrl);
+
return -EINVAL;
}
@@ -307,6 +319,10 @@ static int vidioc_s_ctrl(struct file *fi
}
return 0;
}
+
+ if (tea-s_extra_ctrl)
+ return tea-s_extra_ctrl(file, priv, ctrl);
+
return -EINVAL;
}
--- linux-2.6.39-rc2-/drivers/media/radio/radio-sf16fmr2.c 2011-04-06
03:30:43.0 +0200
+++ linux-2.6.39-rc2/drivers/media/radio/radio-sf16fmr2.c 2011-05-14
00:15:05.0 +0200
@@ -1,441 +1,206 @@
-/* SF16FMR2 radio driver for Linux radio support
- * heavily based on fmi driver...
- * (c) 2000-2002 Ziglio Frediano, fredd...@angelfire.com
+/* SF16-FMR2 radio driver for Linux
+ * Copyright (c) 2011 Ondrej Zary
*
- * Notes on the hardware
- *
- * Frequency control is done digitally -- ie out(port,encodefreq(95.8));
- * No volume control - only mute/unmute - you have to use line volume
- *
- * For read stereo/mono you must wait 0.1 sec after set frequency and
- * card unmuted so I set frequency on unmute
- * Signal handling seem to work only on autoscanning (not implemented)
- *
- * Converted to V4L2 API by Mauro Carvalho Chehab mche...@infradead.org
+ * Original driver was (c) 2000-2002 Ziglio Frediano, fredd...@angelfire.com
+ * but almost nothing remained here after conversion to generic TEA575x
+ * interface
*/
+#include linux/delay.h
#include linux/module.h /* Modules */
#include linux/init.h/* Initdata */
#include linux/ioport.h /* request_region */
-#include linux/delay.h /* udelay */
-#include linux/videodev2.h /* kernel radio structs */
-#include linux/mutex.h
-#include linux/version.h /* for KERNEL_VERSION MACRO */
#include linux/io.h /* outb, outb_p */
-#include media/v4l2-device.h
-#include media/v4l2-ioctl.h
+#include sound/tea575x-tuner.h
-MODULE_AUTHOR(Ziglio Frediano, fredd...@angelfire.com);
-MODULE_DESCRIPTION(A driver for the SF16FMR2 radio.);
+MODULE_AUTHOR(Ondrej Zary);
+MODULE_DESCRIPTION(MediaForte SF16-FMR2 FM radio card driver);
MODULE_LICENSE(GPL);
-static int io = 0x384;
-static int radio_nr = -1;
-
-module_param(io, int, 0);
-MODULE_PARM_DESC(io, I/O address of the SF16FMR2 card (should be 0x384, if do
Re: IR remote control autorepeat / evdev
Em 13-05-2011 01:48, Anssi Hannula escreveu: On 12.05.2011 04:36, Mauro Carvalho Chehab wrote: Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu: Em 12-05-2011 02:37, Anssi Hannula escreveu: I don't see any other places: $ git grep 'REP_PERIOD' . dvb/dvb-usb/dvb-usb-remote.c: input_dev-rep[REP_PERIOD] = d-props.rc.legacy.rc_interval; Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we should change it to something like 125ms, for example, as 33ms is too short, as it takes up to 114ms for a repeat event to arrive. IMO, the enclosed patch should do a better job with repeat events, without needing to change rc-core/input/event logic. It will indeed reduce the amount of ghost events so it brings us in the right direction. I'd still like to get rid of the ghost repeats entirely, or at least some way for users to do it if we don't do it by default. Maybe we could replace the kernel softrepeat with native repeats (for those protocols/drivers that have them), while making sure that repeat events before REP_DELAY are ignored and repeat events less than REP_PERIOD since the previous event are ignored, so the users can still configure them as they like? This doesn't seem to be the right thing to do. If the kernel will accept 33 ms as the value or REP_PERIOD, but it will internally set the maximum repeat rate is 115 ms (no matter what logic it would use for that), Kernel (or X) shouldn't allow the user to set a smaller value. The thing is that writing a logic to block a small value is not easy, since the max value is protocol-dependent (worse than that, on some cases, it is device-specific). It seems better to add a warning at the userspace tools that delays lower than 115 ms can produce ghost events on IR's. Or maybe just a module option that causes rc-core to use native repeat events, for those of us that want accurate repeat events without ghosting? If the user already knows about the possibility to generate ghost effects, with low delays, he can simply not pass a bad value to the kernel, instead of forcing a modprobe parameter that will limit the minimal value. Mauro. -- 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] redrat3: new rc-core IR transceiver device driver
This is a new rc-core device driver for the IR transceivers made by RedRat Ltd. (http://redrat.co.uk/). It started out life as an out-of-lirc-tree lirc driver, maintained in its own repo on sourceforge, by Stephen Cox. He started porting it to what was then ir-core, and I finally picked it up about two week ago and did a fairly large overhaul on it, and its now into a state where I'm fairly comfortable submitting it here for review and inclusion in the kernel. I'm claiming authorship of this driver, since while it started out as Stephen's work, its definitely a derivative work now, at 876 lines added and 1698 lines removed since grabbing it from sourceforge. Stephen's name is retained as secondary author though, and credited in the headers. Those interested in seeing how the changes evolved can (at least for now) look at this branch in my git tree: http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=shortlog;h=refs/heads/redrat3 That won't be around forever though, and I'm doing this as a single commit to go into mainline. Anyway... I've successfully tested in-kernel decode of rc5, rc6 and nec remotes, as well as lirc userspace decode of rc5 and rc6. There are still some quirks here to sort out with rc5 lirc userspace decode, but I'm working with the RedRat folks themselves to figure out what's going on there (rc5 lirc decode works, but you only get an event on key release -- in-kernel rc5 decode behaves perfectly fine). Note that lirc decode of rc6 is working perfectly. Transmit is also working, tested by pointing the redrat3 at an mceusb transceiver, which happily picked up the transmitted signals and properly decoded them. There's no default remote for this hardware, so its somewhat arbitrarily set to use the Hauppauge RC5 keymap by default. Easily changed out by way of ir-keytable and irrelevant if you're using lircd for decode. CC: Chris Dodge ch...@redrat.co.uk CC: Andrew Vincer andrew.vin...@redrat.co.uk CC: Stephen Cox scox...@yahoo.com Signed-off-by: Jarod Wilson ja...@redhat.com --- drivers/media/rc/Kconfig | 11 + drivers/media/rc/Makefile |1 + drivers/media/rc/redrat3.c | 1344 3 files changed, 1356 insertions(+), 0 deletions(-) create mode 100644 drivers/media/rc/redrat3.c diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index 7f03142..154c337 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -161,6 +161,17 @@ config IR_NUVOTON To compile this driver as a module, choose M here: the module will be called nuvoton-cir. +config IR_REDRAT3 + tristate RedRat3 IR Transceiver + depends on USB_ARCH_HAS_HCD + depends on RC_CORE + select USB + ---help--- + Say Y here if you want to use a RedRat3 Infrared Transceiver. + + To compile this driver as a module, choose M here: the + module will be called redrat3. + config IR_STREAMZAP tristate Streamzap PC Remote IR Receiver depends on USB_ARCH_HAS_HCD diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile index c6cfe70..1f90a21 100644 --- a/drivers/media/rc/Makefile +++ b/drivers/media/rc/Makefile @@ -18,6 +18,7 @@ obj-$(CONFIG_IR_ITE_CIR) += ite-cir.o obj-$(CONFIG_IR_MCEUSB) += mceusb.o obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o obj-$(CONFIG_IR_ENE) += ene_ir.o +obj-$(CONFIG_IR_REDRAT3) += redrat3.o obj-$(CONFIG_IR_STREAMZAP) += streamzap.o obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o diff --git a/drivers/media/rc/redrat3.c b/drivers/media/rc/redrat3.c new file mode 100644 index 000..5147767 --- /dev/null +++ b/drivers/media/rc/redrat3.c @@ -0,0 +1,1344 @@ +/* + * USB RedRat3 IR Transceiver rc-core driver + * + * Copyright (c) 2011 by Jarod Wilson ja...@redhat.com + * based heavily on the work of Stephen Cox, with additional + * help from RedRat Ltd. + * + * This driver began life based an an old version of the first-generation + * lirc_mceusb driver from the lirc 0.7.2 distribution. It was then + * significantly rewritten by Stephen Cox with the aid of RedRat Ltd's + * Chris Dodge. + * + * The driver was then ported to rc-core and significantly rewritten again, + * by Jarod, using the in-kernel mceusb driver as a guide, after an initial + * port effort was started by Stephen. + * + * TODO LIST: + * - fix lirc not showing repeats properly + * -- + * + * The RedRat3 is a USB transceiver with both send receive, + * with 2 separate sensors available for receive to enable + * both good long range reception for general use, and good + * short range reception when required for learning a signal. + * + * http://www.redrat.co.uk/ + * + * It uses its own little protocol to communicate, the required + * parts of which are embedded within this driver. + * -- + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License
Re: [ANNOUNCE] New OMAP4 V4L2 Camera Project started
Aguirre, Sergio wrote: Hi all, Hi, Sergio! Just to let you know that I've just officially registered for a new project in the Pandaboard.org portal for OMAP4 v4l2 camera support. You can find it here: http://omiio.org/content/omap4-v4l2-camera And also, you can find the actual Gitorious project with the code here: https://www.gitorious.org/omap4-v4l2-camera If anyone is interested in contributing for this project, please let me know, so I can add you as a contributor to the project. I'm very, very happy to see a project to start implementing V4L2 support for the OMAP 4 ISS!! Thanks, Sergio! A few comments: - The driver is using videobuf. I wonder if the driver would benefit more from videobuf2. - As far as I understand, the OMAP 4 ISS is partially similar to the OMAP 3 one in design --- it has a hardware pipeline, that is. Fitting the bus receivers and the ISP under an Media controller graph looks relatively straightforward. The same might apply to SIMCOP, but then the question is: what kind of interface should the SIMCOP have? Being familiar with the history of the OMAP 3 ISP driver, I know this is not a small project. Still, starting to use the Media controller in an early phase would benefit the project in long run since the conversion can be avoided later. Which parts of the ISS require regular attention from the M3s? Is it the whole ISS or just the SIMCOP, for example? Kind regards, Sakari Ailus Ps. I have nothing against SoC camera, but when I look at the ISS overview diagram (section 8.1 in my TRM) I can't avoid thinking that this is exactly what the Media controller was created for. :-) -- Sakari Ailus sakari.ai...@iki.fi -- 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: IR remote control autorepeat / evdev
On 14.05.2011 01:39, Mauro Carvalho Chehab wrote: Em 13-05-2011 01:48, Anssi Hannula escreveu: On 12.05.2011 04:36, Mauro Carvalho Chehab wrote: Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu: Em 12-05-2011 02:37, Anssi Hannula escreveu: I don't see any other places: $ git grep 'REP_PERIOD' . dvb/dvb-usb/dvb-usb-remote.c: input_dev-rep[REP_PERIOD] = d-props.rc.legacy.rc_interval; Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we should change it to something like 125ms, for example, as 33ms is too short, as it takes up to 114ms for a repeat event to arrive. IMO, the enclosed patch should do a better job with repeat events, without needing to change rc-core/input/event logic. It will indeed reduce the amount of ghost events so it brings us in the right direction. I'd still like to get rid of the ghost repeats entirely, or at least some way for users to do it if we don't do it by default. Maybe we could replace the kernel softrepeat with native repeats (for those protocols/drivers that have them), while making sure that repeat events before REP_DELAY are ignored and repeat events less than REP_PERIOD since the previous event are ignored, so the users can still configure them as they like? This doesn't seem to be the right thing to do. If the kernel will accept 33 ms as the value or REP_PERIOD, but it will internally set the maximum repeat rate is 115 ms (no matter what logic it would use for that), Kernel (or X) shouldn't allow the user to set a smaller value. The thing is that writing a logic to block a small value is not easy, since the max value is protocol-dependent (worse than that, on some cases, it is device-specific). It seems better to add a warning at the userspace tools that delays lower than 115 ms can produce ghost events on IR's. From what I see, even periods longer than 115 ms can produce ghost events. For example with your patch softrepeat period is 125ms, release timeout 250ms, and a native rate of 110ms: There are 4 native events transmitted at 000 ms 110 ms 220 ms 330 ms (user stops between 330ms and 440ms) This causes these events in the evdev interface: 000: 1 125: 2 250: 2 375: 2 500: 2 550: 0 So we got 1-2 ghost repeat events. Or maybe just a module option that causes rc-core to use native repeat events, for those of us that want accurate repeat events without ghosting? If the user already knows about the possibility to generate ghost effects, with low delays, he can simply not pass a bad value to the kernel, instead of forcing a modprobe parameter that will limit the minimal value. There is no good value for REP_PERIOD (as in ghost repeats guaranteed gone like with native repeats). Sufficiently large values will make ghost repeats increasingly rare, but the period becomes so long the autorepeat becomes frustratingly slow to use. -- Anssi Hannula -- 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: [ANNOUNCE] New OMAP4 V4L2 Camera Project started
On Fri, May 13, 2011 at 6:01 PM, Sakari Ailus sakari.ai...@iki.fi wrote: Aguirre, Sergio wrote: Hi all, Hi, Sergio! Hi Sakari, Just to let you know that I've just officially registered for a new project in the Pandaboard.org portal for OMAP4 v4l2 camera support. You can find it here: http://omiio.org/content/omap4-v4l2-camera And also, you can find the actual Gitorious project with the code here: https://www.gitorious.org/omap4-v4l2-camera If anyone is interested in contributing for this project, please let me know, so I can add you as a contributor to the project. I'm very, very happy to see a project to start implementing V4L2 support for the OMAP 4 ISS!! Thanks, Sergio! I'm pretty excited about it too :) Thanks. A few comments: - The driver is using videobuf. I wonder if the driver would benefit more from videobuf2. Sure, that's definitely one of the first targets. I'll migrate to it. - As far as I understand, the OMAP 4 ISS is partially similar to the OMAP 3 one in design --- it has a hardware pipeline, that is. Fitting the bus receivers and the ISP under an Media controller graph looks relatively straightforward. The same might apply to SIMCOP, but then the question is: what kind of interface should the SIMCOP have? That's a big question :) And I'm yet not sure on that. I'll certainly need to think about it, and probably start planning for RFCs. BTW, this driver is just implementing a super simple CSI2-A Rx - MEM pipeline so far. I started with this because i wanted to avoid wasting my time on developing somethign huge, and having to do heavy rework after reviews take place. Being familiar with the history of the OMAP 3 ISP driver, I know this is not a small project. Still, starting to use the Media controller in an early phase would benefit the project in long run since the conversion can be avoided later. Agreed. Which parts of the ISS require regular attention from the M3s? Is it the whole ISS or just the SIMCOP, for example? In theory, the whole ISS, which includes SIMCOP, cna be driven from either A9 or M3 cores. Architecturally, it's better to keep the dedicated M3 cores for driving ISS, and to save some considerable cycles from A9. Problem is, we have to deal with IPC communication channels, and that might make the driver much more complex and requiring much more software layers to be in place for that. The long term vision about this is that, it might be good ot see how easy is to keep a Media Controller device, which sends the pipeline and subdevice configuration to M3 software, and just keep the Board specific and Usecases in A9 side. Immediate problems are how to approach this with purely open source tools. (As far as I know, it's so far only possible with TI proprietary compilers) So, it might definitely take this discussion to a much more complex level and more complete analysis. Hopefully we can have a good discussion about the long term future of this. So far, I'm just starting with the simple stuff, ISS CSI2 Rx interface :) Kiitos! Thanks for the interest. Regards, Sergio Kind regards, Sakari Ailus Ps. I have nothing against SoC camera, but when I look at the ISS overview diagram (section 8.1 in my TRM) I can't avoid thinking that this is exactly what the Media controller was created for. :-) The main reason why it started as a soc_camera is because I started this driver in a 2.6.35 android kernel, and refused to backport all the Media Controller patches to it :) But now being based in mainline, that's a different story. ;) -- Sakari Ailus sakari.ai...@iki.fi -- 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: [RFC] drm: add overlays as first class KMS objects
On Fri, 13 May 2011 18:16:30 +0200 Daniel Vetter daniel.vet...@ffwll.ch wrote: Hi Jesse, Discussion here in Budapest with v4l and embedded graphics folks was extremely fruitful. A few quick things to take away - I'll try to dig through all the stuff I've learned more in-depth later (probably in a blog post or two): - embedded graphics is insane. The output routing/blending/whatever currently shipping hw can do is crazy and kms as-is is nowhere near up to snuff to support this. We've discussed omap4 and a ti chip targeted at video surveillance as use cases. I'll post block diagrams and explanations some when later. Yeah I expected that; even just TVs can have really funky restrictions about z order and blend capability. - we should immediately stop to call anything an overlay. It's a confusing concept that has a different meaning in every subsystem and for every hw manufacturer. More sensible names are dma fifo engines for things that slurp in planes and make them available to the display subsystem. Blend engines for blocks that take multiple input pipes and overlay/underlay/blend them together. Display subsytem/controller for the aggregate thing including encoders/resizers/outputs and especially the crazy routing network that connects everything. How about just display plane then? Specifically in the context of display output hardware... 1) Splitting the crtc object into two objects: crtc with associated output mode (pixel clock, encoders/connectors) and dma engines (possibly multiple) that feed it. omap 4 has essentially just 4 dma engines that can be freely assigned to the available outputs, so a distinction between normal crtcs and overlay engines just does not make sense. There's the major open question of where to put the various attributes to set up the output pipeline. Also some of these attributes might need to be changed atomicly together with pageflips on a bunch of dma engines all associated with the same crtc on the next vsync, e.g. output position of an overlaid video buffer. Yeah, that's a good goal, and pretty much what I had in mind here. However, breaking the existing interface is a non-starter, so either we need a new CRTC object altogether, or we preserve the idea of a primary plane (whatever that means for a given platform) that's tied to each CRTC, which each additional plane described in a separate structure. Z order and blend restrictions will have to be communicated separately I think... Thanks, -- Jesse Barnes, Intel Open Source Technology Center -- 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]Add i2c_gate_ctrl do mb86a20s
This function enables and disables the i2c bus of the mb86a20s to tuner. -- 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
