On Tue, Jan 18, 2011 at 05:04:23PM +0200, Matti J. Aaltonen wrote:
The driver consists of an MFD core and two child drivers (the audio
codec and the V4L2 driver). And the question is mainly about the role of
the MFD driver: the original design had the IO functions in the core.
Currently the
Em 19-01-2011 05:39, Hans Verkuil escreveu:
Hi Mauro,
I saw that 2.6.38-rc1 was released. I also noticed that not all the patches
that are in the for_2.6.38-rc1 branch are in 2.6.38-rc1.
Yes. Unfortunately, when I was sending the pull request yesterday, I noticed
an issue on my linux next
Hi Laurent,
2011/1/18 Laurent Pinchart laurent.pinch...@ideasonboard.com:
Hi Enric,
On Tuesday 18 January 2011 10:20:43 Enric Balletbò i Serra wrote:
Now seems yavta is blocked dequeuing a buffer ( VIDIOC_DQBUF ), with
strace I get
$ strace ./yavta -f SGRBG10 -s 720x525 -n 1 --capture=1
Hi Enric,
On Wednesday 19 January 2011 12:05:54 Enric Balletbò i Serra wrote:
2011/1/18 Laurent Pinchart laurent.pinch...@ideasonboard.com:
On Tuesday 18 January 2011 10:20:43 Enric Balletbò i Serra wrote:
Now seems yavta is blocked dequeuing a buffer ( VIDIOC_DQBUF ), with
strace I get
Em 19-01-2011 05:39, Hans Verkuil escreveu:
Hi Mauro,
We want to rename video_device to v4l2_devnode. So let me know when I can
finalize my patches and, most importantly, against which branch.
My current tree:
Em 18-01-2011 23:41, Oliver Endriss escreveu:
On Tuesday 18 January 2011 21:03:49 Hans Verkuil wrote:
Hi Mauro,
That beautiful 'OK' from the daily build disappeared again. This should bring
it back :-)
Regards,
Hans
The following changes since commit
Hi Mauro,
On Sun, 16 Jan 2011, Mauro Carvalho Chehab wrote:
Em 14-01-2011 12:51, Patrick Boettcher escreveu:
Hi Mauro,
if it is not too late, here is a pull request for some new devices from DiBcom.
It would be nice to have it in 2.6.38-rc1.
Pull from
git://linuxtv.org/pb/media_tree.git
Em 19-01-2011 05:39, Hans Verkuil escreveu:
Hi Mauro,
I saw that 2.6.38-rc1 was released. I also noticed that not all the
patches
that are in the for_2.6.38-rc1 branch are in 2.6.38-rc1.
Yes. Unfortunately, when I was sending the pull request yesterday, I
noticed
an issue on my linux
Em 19-01-2011 05:39, Hans Verkuil escreveu:
Hi Mauro,
We want to rename video_device to v4l2_devnode. So let me know when I
can
finalize my patches and, most importantly, against which branch.
My current tree:
Em 19-01-2011 09:53, Hans Verkuil escreveu:
Em 19-01-2011 05:39, Hans Verkuil escreveu:
Hi Mauro,
I saw that 2.6.38-rc1 was released. I also noticed that not all the
patches
that are in the for_2.6.38-rc1 branch are in 2.6.38-rc1.
Yes. Unfortunately, when I was sending the pull request
Hi
Yes. I will try it out and post a message as soon as I have some
experience with it.
Regards
Rune
--
We are proud to present our new web-pages at www.aptomar.com
Do not miss our video-window to the world; aptotube
Rune Sætre rune.sae...@aptomar.com
aptomar as
Tel. (+47) 40 00 34 03
Em 19-01-2011 09:59, Hans Verkuil escreveu:
Em 19-01-2011 05:39, Hans Verkuil escreveu:
Hi Mauro,
We want to rename video_device to v4l2_devnode. So let me know when I
can
finalize my patches and, most importantly, against which branch.
My current tree:
On Wed, 2011-01-19 at 00:20 -0500, Jarod Wilson wrote:
On Jan 16, 2011, at 10:29 PM, Andy Walls wrote:
On Sun, 2011-01-16 at 14:20 -0500, Andy Walls wrote:
Mauro,
Please pull the one ir-kbd-i2c change and multiple lirc_zilog changes
for 2.6.38.
The one ir-kbd-i2c change is to
On Wed, 19 Jan 2011 07:21:58 -0500, Andy Walls wrote:
For debugging, you might want to hack in a probe of address 0x70 for
your HVR-1950, to ensure the Tx side responds in the bridge driver.
... keeping in mind that the Z8 doesn't seem to like quick writes, so
short reads should be used for
Em 19-01-2011 09:34, Patrick Boettcher escreveu:
Hi Mauro,
On Sun, 16 Jan 2011, Mauro Carvalho Chehab wrote:
Em 14-01-2011 12:51, Patrick Boettcher escreveu:
Hi Mauro,
if it is not too late, here is a pull request for some new devices from
DiBcom. It would be nice to have it in
On Wed, 19 Jan 2011, Andy Walls wrote:
On Wed, 2011-01-19 at 00:20 -0500, Jarod Wilson wrote:
Not working with
lirc_zilog yet, it fails to load, due to an -EIO ret to one of the
i2c_master_send() calls in lirc_zilog during probe of the TX side. Haven't
looked into it any more than
On Wed, 2011-01-19 at 13:40 +0100, Jean Delvare wrote:
On Wed, 19 Jan 2011 07:21:58 -0500, Andy Walls wrote:
For debugging, you might want to hack in a probe of address 0x70 for
your HVR-1950, to ensure the Tx side responds in the bridge driver.
... keeping in mind that the Z8 doesn't
On Wed, 19 Jan 2011, Andy Walls wrote:
On Wed, 2011-01-19 at 13:40 +0100, Jean Delvare wrote:
On Wed, 19 Jan 2011 07:21:58 -0500, Andy Walls wrote:
For debugging, you might want to hack in a probe of address 0x70 for
your HVR-1950, to ensure the Tx side responds in the bridge driver.
On Wed, 2011-01-19 at 07:20 -0600, Mike Isely wrote:
On Wed, 19 Jan 2011, Andy Walls wrote:
On Wed, 2011-01-19 at 00:20 -0500, Jarod Wilson wrote:
Not working with
lirc_zilog yet, it fails to load, due to an -EIO ret to one of the
i2c_master_send() calls in lirc_zilog during
On 11/26/2010 11:03 AM, Hans Verkuil wrote:
On Friday, November 26, 2010 10:51:10 Richard Röjfors wrote:
To follow is a patch to add the tuner and DSP passed in the platform data
to the I2C bus.
This patch is to be applied after Hans' patch to remove usage of the
blocking ioctl.
Is this
Hi Martin,
a couple of comments inline below.
On 01/19/2011 12:27 AM, Laurent Pinchart wrote:
Hi Martin,
Thanks for the patch. One comment below.
On Tuesday 18 January 2011 22:27:42 Martin Hostettler wrote:
Adds support for V4L2_MBUS_FMT_Y8_1X8 format and 8bit data width in
synchronous
Hi Andy,
On Wed, 19 Jan 2011 08:38:02 -0500, Andy Walls wrote:
As I understand it, the rules/guidelines for I2C probing are now
something like this:
1. I2C device driver modules (ir-kbd-i2c, lirc_zilog, etc.) should not
do hardware probes at all. They are to assume the bridge or platform
On Wed, 19 Jan 2011, Andy Walls wrote:
[...]
So the HVR-1950 only has Z8's capable of both Tx and Rx? No HVR-1950
has an Rx only Z8 unit?
As far as I know, that is indeed the case - Tx and Rx always.
It's the older 24xxx devices where there could be a difference, and
that's why the
kfree(state) if fe allocation fails.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/dvb/frontends/dib8000.c
b/drivers/media/dvb/frontends/dib8000.c
index 3e20aa8..c1c3e26 100644
--- a/drivers/media/dvb/frontends/dib8000.c
+++ b/drivers/media/dvb/frontends/dib8000.c
@@
dib9000_mbx_send_attr() returns an int. It doesn't work to save
negative error codes in an unsigned char, so I've made ret an int
type.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/dvb/frontends/dib9000.c
b/drivers/media/dvb/frontends/dib9000.c
index
Hi Andy,
On Sun, 16 Jan 2011 14:20:49 -0500, Andy Walls wrote:
3. I hear from Jean, or whomever really cares about ir-kbd-i2c, if
adding some new fields for struct IR_i2c_init_data is acceptable.
Specifically, I'd like to add a transceiver_lock mutex, a transceiver
reset callback, and a data
On Wed, 19 Jan 2011, Jean Delvare wrote:
Hi Andy,
On Sun, 16 Jan 2011 14:20:49 -0500, Andy Walls wrote:
3. I hear from Jean, or whomever really cares about ir-kbd-i2c, if
adding some new fields for struct IR_i2c_init_data is acceptable.
Specifically, I'd like to add a transceiver_lock
On Wed, 19 Jan 2011 09:09:47 -0600 (CST), Mike Isely wrote:
On Wed, 19 Jan 2011, Jean Delvare wrote:
Hi Andy,
On Sun, 16 Jan 2011 14:20:49 -0500, Andy Walls wrote:
3. I hear from Jean, or whomever really cares about ir-kbd-i2c, if
adding some new fields for struct IR_i2c_init_data
On Tue, 18 Jan 2011, Qing Xu wrote:
Hi Guennadi,
Thanks for reviewing my patch! I update it again following your
suggestion, please take your time to review it again, Thanks a lot!
-Qing
Email: qi...@marvell.com
Application Processor Systems Engineering,
Marvell Technology Group
On Tue, 18 Jan 2011, Qing Xu wrote:
Sorry, which solution you would like me to implement?
(1) is to add SOC_MBUS_PACKING_VARIABLE define and add error code in
soc_mbus_bytes_per_line(),
and (2) is to implement int (*try_fmt)(struct v4l2_subdev *sd, struct
v4l2_format *fmt); in subdev,
On Sun, Jan 9, 2011 at 6:14 PM, Mark Zimmerman markz...@frii.com wrote:
I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but
which fails to initialize with the latest 2.6.36 kernel. The firmware
fails to load due to an i2c failure. A search of the archives indicates
that
On Jan 19, 2011, at 7:21 AM, Andy Walls wrote:
On Wed, 2011-01-19 at 00:20 -0500, Jarod Wilson wrote:
On Jan 16, 2011, at 10:29 PM, Andy Walls wrote:
On Sun, 2011-01-16 at 14:20 -0500, Andy Walls wrote:
Mauro,
Please pull the one ir-kbd-i2c change and multiple lirc_zilog changes
for
On Wed, Jan 19, 2011 at 11:08 AM, Jarod Wilson ja...@wilsonet.com wrote:
BTW, does your HVR-1950 have a blaster?
Yes, it does, looks like a jack identical to the one on the hdpvr, which
is good, since I don't have the 1950's blaster cable.
Correct - it uses the same cable as the HD-PVR. The
Are the davinci vpbe patches specific only to the DM644x platform? I am
developing on the DM365 and would like to use the OSD features implemented
in the patches. Are there plans to port these patches to the DM365? Is it
only a matter of changing the board-specific files, such as
On Wed, Jan 19, 2011 at 10:59 AM, VDR User user@gmail.com wrote:
Can someone please look into this and possibly provide a fix for the
bug? I'm surprised it hasn't happened yet after all this time but
maybe it's been forgotten the bug existed.
You shouldn't be too surprised. In many cases
(a general request: could you please configure your mailer to wrap lines
at somewhere around 70 characters?)
On Tue, 18 Jan 2011, Qing Xu wrote:
Hi,
Our chip support both MIPI and parallel interface. The HW connection logic is
sensor(such as ov5642) - our MIPI controller(handle DPHY
Hi Michael,
On Wednesday 19 January 2011 14:45:46 Michael Jones wrote:
On 01/19/2011 12:27 AM, Laurent Pinchart wrote:
On Tuesday 18 January 2011 22:27:42 Martin Hostettler wrote:
Adds support for V4L2_MBUS_FMT_Y8_1X8 format and 8bit data width in
synchronous interface.
When in 8bit
On Jan 19, 2011, at 8:20 AM, Mike Isely wrote:
This probing behavior does not happen for HVR-1950 (or HVR-1900) since
there's only one possible IR configuration there.
Just to be 100% clear, the device I'm poking it is definitely an
HVR-1950, using ir_scheme PVR2_IR_SCHEME_ZILOG, so the probe
Jean,
As Mike noted, transceiver is a contraction of transmitter-receiver. But I
wouldn't blame English speakers in general for that, just English speaking
engineers. ;)
English speaking engineers (likely) also orignated use of the x as shorthand
for trans- and crys-.
Transceiver_lock was
On Wed, 19 Jan 2011, Jarod Wilson wrote:
On Jan 19, 2011, at 8:20 AM, Mike Isely wrote:
This probing behavior does not happen for HVR-1950 (or HVR-1900) since
there's only one possible IR configuration there.
Just to be 100% clear, the device I'm poking it is definitely an
HVR-1950,
On Jan 19, 2011, at 11:57 AM, Mike Isely wrote:
On Wed, 19 Jan 2011, Jarod Wilson wrote:
On Jan 19, 2011, at 8:20 AM, Mike Isely wrote:
This probing behavior does not happen for HVR-1950 (or HVR-1900) since
there's only one possible IR configuration there.
Just to be 100% clear, the
On Jan 19, 2011, at 8:50 AM, Jean Delvare wrote:
Hi Andy,
On Wed, 19 Jan 2011 08:38:02 -0500, Andy Walls wrote:
As I understand it, the rules/guidelines for I2C probing are now
something like this:
1. I2C device driver modules (ir-kbd-i2c, lirc_zilog, etc.) should not
do hardware probes
Hi Hans, others,
Hans Verkuil wrote:
Hi Laurent,
My apologies that this reply is so late, but I knew I had to sit down and
think
carefully about this and I didn't have time for that until today.
I've decided not to quote your post but instead restate the problem in my own
words.
On Wed, Jan 19, 2011 at 8:13 AM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
Can someone please look into this and possibly provide a fix for the
bug? I'm surprised it hasn't happened yet after all this time but
maybe it's been forgotten the bug existed.
You shouldn't be too
On Jan 19, 2011, at 12:12 PM, Jarod Wilson wrote:
On Jan 19, 2011, at 8:50 AM, Jean Delvare wrote:
Hi Andy,
On Wed, 19 Jan 2011 08:38:02 -0500, Andy Walls wrote:
As I understand it, the rules/guidelines for I2C probing are now
something like this:
1. I2C device driver modules
On Wed, Jan 19, 2011 at 09:22:28AM -0800, VDR User wrote:
On Wed, Jan 19, 2011 at 8:13 AM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
Can someone please look into this and possibly provide a fix for the
bug? ??I'm surprised it hasn't happened yet after all this time but
maybe
On Wed, 19 Jan 2011 12:12:49 -0500, Jarod Wilson wrote:
On Jan 19, 2011, at 8:50 AM, Jean Delvare wrote:
Hi Andy,
On Wed, 19 Jan 2011 08:38:02 -0500, Andy Walls wrote:
As I understand it, the rules/guidelines for I2C probing are now
something like this:
1. I2C device driver
Hi Hans
This is not a complete review yet, but just something that occurred to me,
while looking at the result of applying all these your patches, maybe you
could just explain, why I'm wrong, or this will be something to change in
the next version:
On Wed, 12 Jan 2011, Hans Verkuil wrote:
On Wed, Jan 19, 2011 at 12:27:19AM +0100, Laurent Pinchart wrote:
Hi Martin,
Thanks for the patch. One comment below.
On Tuesday 18 January 2011 22:27:42 Martin Hostettler wrote:
Adds support for V4L2_MBUS_FMT_Y8_1X8 format and 8bit data width in
synchronous interface.
When in 8bit
On Wed, 2011-01-19 at 16:10 +0300, Vasiliy Kulikov wrote:
Hi,
I've noticed that locking in drivers/media/dvb/frontends/dib9000.c is
not correct:
static int dib9000_fw_get_channel(...)
{
...
DibAcquireLock(state-platform.risc.mem_mbx_lock);
...
error:
On 01/19/2011 06:03 PM, Thierry LELEGARD wrote:
OK, then what? Is the S2API behavior (returning cached - but incorrect -
tuning
parameter values) satisfactory for everyone or shall we adapt S2API to mimic
the
API V3 behavior (return the actual tuning parameter values as automatically
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:Wed Jan 19 19:00:28 CET 2011
git master: 1b59be2a6cdcb5a12e18d8315c07c94a624de48f
git media-master: gcc version:
So what would a mainstream dual (or more) tuner card be? I've found
these Fusions to be flaky. Had one die and another went flaky when I
enabled the sleep mode. Can't really afford any more now, but am always
watching. A company called Ceton seems to havea quad, but it's a cable
card tuner
Hi Hans,
Thanks for the quick review.
offtopic
I just noticed i didn't really understand the new control framework that well,
could
you maybe add a comment pointing to Documentation/video4linux/v4l2-controls.txt
in
the v4l2-ctrl.h header? I think that would help a lot.
/offtopic
On Wed, Jan
Manju,
Em 18-01-2011 11:19, halli manjunatha escreveu:
have a look at the driver it’s already reviewed by Hans Verkuil.
Please let me know if you are okay to include this in mainline.
As I've already pointed you, just send me a pull request from your tree when
you think it is ready. I'll be
On Jan 19, 2011, at 12:43 PM, Jean Delvare wrote:
On Wed, 19 Jan 2011 12:12:49 -0500, Jarod Wilson wrote:
On Jan 19, 2011, at 8:50 AM, Jean Delvare wrote:
Hi Andy,
On Wed, 19 Jan 2011 08:38:02 -0500, Andy Walls wrote:
As I understand it, the rules/guidelines for I2C probing are now
Change for firmware re-loading and updated firmware versions.
Signed-off-by: Dean Anderson linux-...@sensoray.com
diff --git a/drivers/media/video/s2255drv.c b/drivers/media/video/s2255drv.c
index b63f8ca..561909b 100644
--- a/drivers/media/video/s2255drv.c
+++ b/drivers/media/video/s2255drv.c
Hello,
the following patch set is an update for the sr030pc30 sensor driver.
The second patch converts the driver to use the control framework and
adds two new controls as it required relatively little effort to have
them exported.
The third patch replaces the set_power callback with regulator
s_stream does nothing in current form so remove it.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungin.p...@samsung.com
---
drivers/media/video/sr030pc30.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git
Implement controls using the control framework.
Add horizontal/vertical flip controls, minor cleanup.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/sr030pc30.c | 311 +--
Use the regulator API instead of the set_power callback.
Handle RESET and STANDBY gpio in the driver when needed.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/sr030pc30.c | 193
Hi,
(a general request: could you please configure your mailer to wrap
Lines at somewhere around 70 characters?)
very sorry for the un-convenience!
Thanks for your description! I could verify and try your way on our
CSI-2 driver.
Also, our another chip's camera controller support both MIPI and
Hi Robert,
On Thu, Jan 20, 2011 at 12:12 AM, Robert Mellen robert.mel...@gvimd.com wrote:
Are the davinci vpbe patches specific only to the DM644x platform? I am
developing on the DM365 and would like to use the OSD features implemented
in the patches. Are there plans to port these patches to
On Jan 19, 2011, at 3:08 PM, Jarod Wilson wrote:
On Jan 19, 2011, at 12:43 PM, Jean Delvare wrote:
Preliminary technical nitpicking: you can't actually pass two addresses
in i2c_board_info, so the second address has to be passed as platform
data.
I am sorry if you expected an
On Jan 19, 2011, at 11:45 PM, Jarod Wilson wrote:
So as we were discussing on irc today, the -EIO is within lirc_zilog's
send_boot_data() function. The firmware is loaded, and then we send the
z8 a command to activate the firmware, immediately follow by an attempt
to read the firmware
add vidioc_enum_framesizes implementation, follow default_g_parm()
and g_mbus_fmt() method
Signed-off-by: Qing Xu qi...@marvell.com
---
drivers/media/video/soc_camera.c | 36
include/media/soc_camera.h |1 +
include/media/v4l2-subdev.h |2
Hi
Rework registers defines. Add TM6000 specific registers defines.
Add marks and comments for TM6010 specific registers.
diff --git a/drivers/staging/tm6000/tm6000-regs.h
b/drivers/staging/tm6000/tm6000-regs.h
index 1f0ced8..5375a83 100644
--- a/drivers/staging/tm6000/tm6000-regs.h
+++
On Thu, 20 Jan 2011, Qing Xu wrote:
add vidioc_enum_framesizes implementation, follow default_g_parm()
and g_mbus_fmt() method
Signed-off-by: Qing Xu qi...@marvell.com
---
drivers/media/video/soc_camera.c | 36
include/media/soc_camera.h |
Hi,
I am building against linux-2.6.32-26-generic from ubuntu, with just
the linux-headers package.
I know there is a big fat warning about doing this but I thought I
should report the issue
because mostly building like this does work.
The build was against a clean checkout of the media_build
Hm, sorry! My below comment:
On Wed, 19 Jan 2011, Guennadi Liakhovetski wrote:
On Tue, 18 Jan 2011, Qing Xu wrote:
[snip]
@@ -1160,6 +1169,28 @@ static int default_s_parm(struct soc_camera_device
*icd,
return v4l2_subdev_call(sd, video, s_parm, parm);
}
+static int
70 matches
Mail list logo
