Hi Sylwester,
On 07/04/2011 11:24 PM, Sylwester Nawrocki wrote:
The fimc media device driver is hooked onto s5p-fimc-md platform device.
Such a platform device need to be added in a board initialization code
and then camera sensors need to be specified as it's platform data.
The s5p-fimc-md
Ok, Mauro, so may I take your silence as an evidence
that this reiterating myth about the mplayer breakage
is just a myth?
Look, I spent time on investigating the problem, on
trying the different approaches to fix it, on explaining
the problem to you, etc. So maybe I deserve something
more than
Hi Subash,
On 07/22/2011 08:26 AM, Subash Patel wrote:
Hi Sylwester,
On 07/04/2011 11:24 PM, Sylwester Nawrocki wrote:
The fimc media device driver is hooked onto s5p-fimc-md platform device.
Such a platform device need to be added in a board initialization code
and then camera sensors
Hi Sylwester,
On 07/22/2011 02:29 PM, Sylwester Nawrocki wrote:
Hi Subash,
On 07/22/2011 08:26 AM, Subash Patel wrote:
Hi Sylwester,
On 07/04/2011 11:24 PM, Sylwester Nawrocki wrote:
The fimc media device driver is hooked onto s5p-fimc-md platform device.
Such a platform device need to be
On 07/22/2011 11:26 AM, Subash Patel wrote:
...
+
+static int fimc_md_register_sensor_entities(struct fimc_md *fmd)
+{
+ struct s5p_platform_fimc *pdata = fmd-pdev-dev.platform_data;
+ struct fimc_dev *fd = NULL;
+ int num_clients, ret, i;
+
+ /*
+ * Runtime resume one of the FIMC
Sylwester Nawrocki wrote:
Hi Sakari,
Hi Sylwester,
Thanks for the comments.
On 07/19/2011 03:37 PM, Sakari Ailus wrote:
Hi all,
The OMAP 3 ISP driver implements an HS_VS event which is triggered when
the reception of a frame begins. This functionality is very, very likely
not specific to
Have you had to time test these?
And about I2C adapter, I don't see why changes are needed. As far as I
understand it is already working with TDA10023 and you have done changes
for TDA10048 support. I compared TDA10048 and TDA10023 I2C functions and
those are ~similar. Both uses most typical
Hi Guennadi,
On Sun, Jul 17, 2011 at 07:09:42PM +0200, Guennadi Liakhovetski wrote:
On Tue, 12 Jul 2011, Michael Grzeschik wrote:
added new bit offset defines,
more supported BE colour formats
and also support BGR565 swapped pixel formats
removed pixfmt helper functions and option
Em 22-07-2011 04:51, Stas Sergeev escreveu:
Ok, Mauro, so may I take your silence as an evidence
that this reiterating myth about the mplayer breakage
is just a myth?
It is due to my lack of time of explaining the obvious for you.
Changing the behavior of the kernel drivers has consequences
on
22.07.2011 16:28, Mauro Carvalho Chehab wrote:
In this specific case, applications like mplayer,
using the alsa parameters for streaming will stop work, as mplayer
won't touch at the mixer or at the V4L mute control. So,
it will have the same practical effect of a kernel bug at the
audio part
Em 22-07-2011 09:39, Stas Sergeev escreveu:
22.07.2011 16:28, Mauro Carvalho Chehab wrote:
In this specific case, applications like mplayer,
using the alsa parameters for streaming will stop work, as mplayer
won't touch at the mixer or at the V4L mute control. So,
it will have the same
22.07.2011 16:49, Mauro Carvalho Chehab wrote:
Let me rephase it:
Some applications like mplayer don't use V4L2_CID_AUDIO_MUTE to unmute a
video device. They assume the current behavior that starting audio on a
video board also unmutes audio.
Could you please give me a command line I can use
Em 22-07-2011 09:56, Stas Sergeev escreveu:
22.07.2011 16:49, Mauro Carvalho Chehab wrote:
Let me rephase it:
Some applications like mplayer don't use V4L2_CID_AUDIO_MUTE to unmute a
video device. They assume the current behavior that starting audio on a
video board also unmutes audio.
Could
Jarod Wilson wrote:
The interface 0 urb callback was being wired up before the rc_dev device
was allocated, meaning the callback could be called with a null rc_dev,
leading to an oops. This likely only ever happens on the older 0xffdc
SoundGraph devices, which continually trigger interrupts even
Hi,
On 07/22/2011 12:39 PM, Sakari Ailus wrote:
...
On 07/19/2011 03:37 PM, Sakari Ailus wrote:
Hi all,
The OMAP 3 ISP driver implements an HS_VS event which is triggered when
the reception of a frame begins. This functionality is very, very likely
not specific to OMAP 3 ISP so it should be
[ Cc'ing Andrew Morton -- Andrew, could you please pick this patch, in
case there is no response from maintainers again? Thanks beforehand. ]
Hello up there,
My first posting was 1 month ago, and a reminder ~ 2 weeks ago. All
without a reply. v3.0 is out and they say the merge window will
Hi Hans,
Hans de Goede wrote:
Hi,
Sorry it took so long, but I've just merged the plugin
support into v4l-utils git. I did make some minor mods /
bugfixes before merging, see the commit message in git.
Regards,
Hans
p.s.
I think we should expand the plugin support with support
for a output
On Viernes, 22 de Julio de 2011 13:32:53 Antti Palosaari escribió:
Have you had to time test these?
And about I2C adapter, I don't see why changes are needed. As far as I
understand it is already working with TDA10023 and you have done changes
for TDA10048 support. I compared TDA10048 and
Since many, many kernel releases my Hauppauge WinTV HVR-1400 doesn't work
anymore, and nobody feels responsible to fix it.
The code to get it work is still in there, it's only commented out.
My patch to enable it was rejected, because somebody had fear that it could
break other cards.
So here is a
On 07/22/2011 07:02 PM, Jose Alberto Reguero wrote:
On Viernes, 22 de Julio de 2011 13:32:53 Antti Palosaari escribió:
Have you had to time test these?
And about I2C adapter, I don't see why changes are needed. As far as I
understand it is already working with TDA10023 and you have done
On Viernes, 22 de Julio de 2011 18:08:39 Antti Palosaari escribió:
On 07/22/2011 07:02 PM, Jose Alberto Reguero wrote:
On Viernes, 22 de Julio de 2011 13:32:53 Antti Palosaari escribió:
Have you had to time test these?
And about I2C adapter, I don't see why changes are needed. As far as
Since many, many kernel releases my Hauppauge WinTV HVR-1400 doesn't work
anymore, and nobody feels responsible to fix it.
The code to get it work is still in there, it's only commented out.
My patch to enable it was rejected, because somebody had fear that it could
break other cards.
So here is a
On 07/22/2011 07:25 PM, Jose Alberto Reguero wrote:
On Viernes, 22 de Julio de 2011 18:08:39 Antti Palosaari escribió:
On 07/22/2011 07:02 PM, Jose Alberto Reguero wrote:
On Viernes, 22 de Julio de 2011 13:32:53 Antti Palosaari escribió:
Have you had to time test these?
And about I2C
This is an automatic generated email to let you know that the following patch
were queued at the
http://git.linuxtv.org/media_tree.git tree:
Subject: [media] media: fix radio-sf16fmr2 build when SND is not enabled
Author: Randy Dunlap randy.dun...@oracle.com
Date:Thu Jun 30 14:31:04 2011
Hello,
I tried to install s2-liplianin on changing kernel-versions. All in
common is, that my Hauppauge Nova-T USB-Stick causes a kernel oops when
plugged in. The devices are generated, but it does not tune. lsusb freezes.
Here is my kernel.log: http://pastebin.com/03hxKvme
The drivers from
The driver reads PCI subsystem IDs from the PCI configuration registers while
they are already stored by the PCI subsystem in the 'subsystem_{vendor|device}'
fields of 'struct pci_dev'...
Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com
---
The patch is against the recent Linus' tree.
Since many, many kernel releases my Hauppauge WinTV HVR-1400 doesn't work
anymore, and nobody feels responsible to fix it.
The code to get it work is still in there, it's only commented out.
My patch to enable it was rejected, because somebody had fear that it could
break other cards.
So here is a
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 Jul 22 19:00:41 CEST 2011
git hash:f0a21151140da01c71de636f482f2eddec2840cc
gcc version: i686-linux-gcc (GCC)
The problem is that there's no convenient callback into the allocators
where the mapping and unmapping can be done now. So I'd have had to add a
couple of memops to do that.
I think that some additional callbacks for allocators for synchronization
buffer state will be required sooner or
Scaling causes bad artifacts (horizontal lines) with compression at least
with Nogatech MicroCam so disable it (for this HW).
This also fixes messed up image with some programs (Cheese with 160x120,
Adobe Flash). HW seems to support only image widths that are multiple of 64
but the driver does
On Fri, Jul 22, 2011 at 4:00 PM, Ondrej Zary li...@rainbow-software.org wrote:
Scaling causes bad artifacts (horizontal lines) with compression at least
with Nogatech MicroCam so disable it (for this HW).
This also fixes messed up image with some programs (Cheese with 160x120,
Adobe Flash).
22.07.2011 17:03, Mauro Carvalho Chehab wrote:
Here, I add the following line at my .mplayer/config:
tv =
driver=v4l2:device=/dev/video0:norm=PAL-M:chanlist=us-bcast:alsa=1:adevice=hw.1:audiorate=32000:immediatemode=0:amode=1
Thanks for starting to answer what I was asking for
On Friday 22 July 2011 22:06:59 Devin Heitmueller wrote:
On Fri, Jul 22, 2011 at 4:00 PM, Ondrej Zary li...@rainbow-software.org
wrote:
Scaling causes bad artifacts (horizontal lines) with compression at least
with Nogatech MicroCam so disable it (for this HW).
This also fixes messed up
On Fri, Jul 22, 2011 at 5:22 PM, Ondrej Zary li...@rainbow-software.org wrote:
Seems that this bug is widespread - the same problem appears also in guvcview
and adobe flash. I think that the driver is broken too - it should return
corrected resolution in TRY_FMT.
Well, if the driver does not
On Friday 22 July 2011 23:31:46 Devin Heitmueller wrote:
On Fri, Jul 22, 2011 at 5:22 PM, Ondrej Zary li...@rainbow-software.org
wrote:
Seems that this bug is widespread - the same problem appears also in
guvcview
and adobe flash. I think that the driver is broken too - it should return
On Viernes, 22 de Julio de 2011 20:12:20 Jose Alberto Reguero escribió:
On Viernes, 22 de Julio de 2011 18:46:24 Antti Palosaari escribió:
On 07/22/2011 07:25 PM, Jose Alberto Reguero wrote:
On Viernes, 22 de Julio de 2011 18:08:39 Antti Palosaari escribió:
On 07/22/2011 07:02 PM, Jose
Hi Kirill,
On Friday 22 July 2011 16:47:22 Kirill Smelkov wrote:
[ Cc'ing Andrew Morton -- Andrew, could you please pick this patch, in
case there is no response from maintainers again? Thanks beforehand. ]
Hello up there,
My first posting was 1 month ago, and a reminder ~ 2 weeks
In case of i2c write operation there is only one element in msg[] array.
Don't access msg[1] in that case.
Signed-off-by: Honza Petrous jpetr...@smartimp.cz
--
diff -uBbp cxd2820r_core.c.orig cxd2820r_core.c
--- cxd2820r_core.c.orig2011-07-22 23:31:56.319168405 +0200
+++ cxd2820r_core.c
On 07/23/2011 12:49 AM, Jose Alberto Reguero wrote:
On Viernes, 22 de Julio de 2011 20:12:20 Jose Alberto Reguero escribió:
On Viernes, 22 de Julio de 2011 18:46:24 Antti Palosaari escribió:
On 07/22/2011 07:25 PM, Jose Alberto Reguero wrote:
On Viernes, 22 de Julio de 2011 18:08:39 Antti
Hi Laurent, All,
On Sat, Jul 23, 2011 at 12:03:57AM +0200, Laurent Pinchart wrote:
Hi Kirill,
On Friday 22 July 2011 16:47:22 Kirill Smelkov wrote:
[ Cc'ing Andrew Morton -- Andrew, could you please pick this patch, in
case there is no response from maintainers again? Thanks
2011/7/23 Antti Palosaari cr...@iki.fi:
On 07/23/2011 01:18 AM, HoP wrote:
In case of i2c write operation there is only one element in msg[] array.
Don't access msg[1] in that case.
NACK.
I suspect you confuse now local msg2 and msg that is passed as function
parameter. Could you double
On 07/23/2011 01:47 AM, HoP wrote:
2011/7/23 Antti Palosaaricr...@iki.fi:
On 07/23/2011 01:18 AM, HoP wrote:
In case of i2c write operation there is only one element in msg[] array.
Don't access msg[1] in that case.
NACK.
I suspect you confuse now local msg2 and msg that is passed as
2011/7/23 Antti Palosaari cr...@iki.fi:
On 07/23/2011 01:47 AM, HoP wrote:
2011/7/23 Antti Palosaaricr...@iki.fi:
On 07/23/2011 01:18 AM, HoP wrote:
In case of i2c write operation there is only one element in msg[] array.
Don't access msg[1] in that case.
NACK.
I suspect you confuse now
Hi Kirill,
On Saturday 23 July 2011 00:25:20 Kirill Smelkov wrote:
On Sat, Jul 23, 2011 at 12:03:57AM +0200, Laurent Pinchart wrote:
On Friday 22 July 2011 16:47:22 Kirill Smelkov wrote:
[ Cc'ing Andrew Morton -- Andrew, could you please pick this patch, in
case there is no
On 07/23/2011 02:01 AM, HoP wrote:
2011/7/23 Antti Palosaaricr...@iki.fi:
On 07/23/2011 01:47 AM, HoP wrote:
2011/7/23 Antti Palosaaricr...@iki.fi:
On 07/23/2011 01:18 AM, HoP wrote:
In case of i2c write operation there is only one element in msg[] array.
Don't access msg[1] in that case.
On 07/23/2011 02:31 AM, Antti Palosaari wrote:
On 07/23/2011 02:01 AM, HoP wrote:
2011/7/23 Antti Palosaaricr...@iki.fi:
But now I see what you mean. msg2[1] is set as garbage fields in case of
incoming msg len is 1. True, but it does not harm since it is not
used in
that case.
In case of
Hi Mauro,
The following changes since commit f0a21151140da01c71de636f482f2eddec2840cc:
Merge tag 'v3.0' into staging/for_v3.1 (2011-07-22 13:33:14 -0300)
are available in the git repository at:
git://linuxtv.org/pinchartl/media.git omap3isp-next-sensors
Laurent Pinchart (1):
v4l:
2011/7/23 Antti Palosaari cr...@iki.fi:
On 07/23/2011 02:31 AM, Antti Palosaari wrote:
On 07/23/2011 02:01 AM, HoP wrote:
2011/7/23 Antti Palosaaricr...@iki.fi:
But now I see what you mean. msg2[1] is set as garbage fields in case of
incoming msg len is 1. True, but it does not harm since
Em 22-07-2011 17:40, Stas Sergeev escreveu:
22.07.2011 17:03, Mauro Carvalho Chehab wrote:
Here, I add the following line at my .mplayer/config:
tv=
driver=v4l2:device=/dev/video0:norm=PAL-M:chanlist=us-bcast:alsa=1:adevice=hw.1:audiorate=32000:immediatemode=0:amode=1
Thanks for
Hi Jonathan,
On Fri, Jul 22, 2011 at 01:55:47PM -0600, Jonathan Corbet wrote:
You *can't* do the mapping at allocation time...
Could you elaborate why you can't create the mapping at allocation time?
DMA-mapping api requires the following call sequence:
dma_map_single()
...
50 matches
Mail list logo
