Hi Koen,
On 1 June 2011 20:08, Koen Kooi k...@beagleboard.org wrote:
Op 1 jun 2011, om 17:36 heeft Javier Martin het volgende geschreven:
New version and vdd_io flags have been added.
A subtle change now prevents camera from being registered
in the wrong platform.
I get a decent picture
Hi,
Thank you for your nice work. Here are my some comments.
-Original Message-
From: Kamil Debski [mailto:k.deb...@samsung.com]
Sent: Tuesday, May 31, 2011 6:08 PM
Cc: m.szyprow...@samsung.com; kyungmin.p...@samsung.com;
k.deb...@samsung.com; jaeryul...@samsung.com;
Add maintainers for the videobuf2 V4L2 driver framework.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
MAINTAINERS |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
No technical review this time. Relying fully on Laurent and others to take
care of that, just a couple of cosmetic points, which even checkpatch.pl
failed to warn about:(
On Wed, 1 Jun 2011, Javier Martin wrote:
Clock frequency of 57MHz used in previous version was wrong since
when VDD_IO is
On Wed, 1 Jun 2011 21:16:45 +0800
Kassey Lee y...@marvell.com wrote:
This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on soc-camera + videobuf2 frame
work, and only USERPTR is
Hello Hans Petter,
I haven't tested your patch yet, but looking at the source I see some
problems.
What does your patch fix and how?
If you have problem locking channels, try my locking patch:
https://patchwork.kernel.org/patch/753382/
On each step (timing, carrier, data) you reset the derot:
hi, Jonathan:
yes, you are right, this driver uses most of the low level
code from cafe-ccic.c.
I am so sorry to miss the your email and refer info from
cafe-ccic.c in my driver, really appreciate your work.
the point that I write mv_camera.c is to base the
On Thu, 2 Jun 2011, Jonathan Corbet wrote:
On Wed, 1 Jun 2011 21:16:45 +0800
Kassey Lee y...@marvell.com wrote:
This driver exports a video device node per each CCIC
(CMOS Camera Interface Controller)
device contained in Marvell Mobile PXA910 SoC
The driver is based on soc-camera +
On Thursday 02 June 2011 11:46:15 Lutz Sammer wrote:
Hello Hans Petter,
Hi,
I haven't tested your patch yet, but looking at the source I see some
problems.
What does your patch fix and how?
It switches from software derot to hardware derot, by writing zero to the
derot register.
If
OK Guennadi,
I'll fix those cosmetics issues in my next version where I will add
VFLIP and HFLIP control support (which I removed previously to make
the code less complex).
Now we talk about controls I have a question regarding controls
defined in video subdevices like mt9p031 or mt9v032:
What
Hello,
the following are a few bugfix patches for s5p-fimc driver.
Except the kernel-doc comments corrections, debug trace cleanup
and the copyright update they fix the buffer allocation issue and
possible memory leak on error path.
drivers/media/video/s5p-fimc/fimc-capture.c | 21
Correct inconsistencies in data structures' documentation.
Remove meaningless debug traces.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c |9 -
Remove V4L2_MBUS_FMT_RGB565_2X8_BE media code entry as
camera interface supports only packed YUYV formats.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-core.c |1 -
1 files changed, 0
The buf_init buffer queue operation is optional and
buffer_init() does nothing, remove it.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c |7 ---
1 files changed, 0
On Thu, 2 Jun 2011, javier Martin wrote:
OK Guennadi,
I'll fix those cosmetics issues in my next version where I will add
VFLIP and HFLIP control support (which I removed previously to make
the code less complex).
Please, don't. Let's first get the simple version of your driver in the
On 2 June 2011 12:36, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
On Thu, 2 Jun 2011, javier Martin wrote:
OK Guennadi,
I'll fix those cosmetics issues in my next version where I will add
VFLIP and HFLIP control support (which I removed previously to make
the code less complex).
2011/5/31 Dmitri Belimov d.beli...@gmail.com:
Is it possible make some patches and add support xc4000 into kernel?
With my best regards, Dmitry.
What needs to happen here is somebody needs to prepare a patch series
which contains all the relevant patches, including the SOBs. This is
entirely
Here is the email thread where Davide Ferri consented to having the
SOB added to his original patch. Whoever prepares the patch series
should ensure that it has the following chain of SOBs:
Signed-off-by: Davide Ferri davidef1...@gmail.com
Signed-off-by: Devin Heitmueller
Em 02-06-2011 02:56, Marek Szyprowski escreveu:
Hello,
On Thursday, June 02, 2011 3:35 AM Mauro Carvalho Chehab wrote:
Hi Kyungmin,
Em 01-06-2011 21:50, Kyungmin Park escreveu:
Acked-by: Kyungmin Park kyunginn.,p...@samsung.com
As this patch is really trivial and makes sense, I've just
This version fixes some cosmetic issues pointed out
by Guennadi.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
drivers/media/video/Kconfig |7 +
drivers/media/video/Makefile |1 +
drivers/media/video/mt9p031.c | 763 +
Add missing kfree on the error path.
Reported-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/media/video/s5p-fimc/fimc-capture.c |1 +
1 files changed, 1
Hi,
I'm trying to add VFLIP control to the mt9p031 driver (don't worry
Guennadi, I won't send the patch yet). For that purpose I've followed
the code in mt9v032 sensor.
When I try to query available controls using yavta I get the following:
root@beagleboard:~# ./media-ctl -e OMAP3 ISP CCDC output
Em 02-06-2011 07:52, Devin Heitmueller escreveu:
2011/5/31 Dmitri Belimov d.beli...@gmail.com:
Is it possible make some patches and add support xc4000 into kernel?
With my best regards, Dmitry.
What needs to happen here is somebody needs to prepare a patch series
which contains all the
From: Jeongtae Park [mailto:jtp.p...@samsung.com]
Sent: 02 June 2011 09:44
To: 'Kamil Debski'; linux-media@vger.kernel.org
Cc: jaeryul...@samsung.com; june@samsung.com; janghyuck@samsung.com;
kyungmin.p...@samsung.com; younglak1004@samsung.com; 'Marek Szyprowski'
Subject: RE:
Hi,
This is a third version of the patch that adds controls for the codec family of
devices. I have implemented the suggestions to v1 I got from Hans Verkuil on
the #v4l
channel. Also I have addressed comments to v2 by Jeongtae Park.
Changes from v2 to v3:
- added MVC anc SVC profiles to H264
-
According to the datasheet (page 8), the first optical clear pixel-column is
not at position 14. The correct/recommended value is 20. Without this patch
there is a dark line on the left side of the image.
Signed-off-by: Johannes Obermaier johannes.oberma...@gmail.com
---
According to the datasheet (page 8), the first optical clear pixel-column is
not at position 14. The correct/recommended value is 20. Without this patch
there is a dark line on the left side of the image.
Signed-off-by: Johannes Obermaier johannes.oberma...@gmail.com
---
There are problems when you use this camera/sensor in a very bright room or
outside. The image is completely white, because it is overexposed. The driver
uses a default value which is not suitable for all environments.
This patch makes it possible to adjust the exposure time by youself. I found
Now I understood how thing works here, and it clear to me, why the
xc4000 driver is not being included in mainline V4L2.
It will be lots of commitments and hard work to be the maintainer, and
I respect Mr. Devin's choice and decisions. There are several peoples
that are interested in this
(This patch must be used AFTER the patch V4L/DVB: mt9v011: Added exposure for
mt9v011)
The implementation of the gain calculation for this sensor is incorrect. It is
only working for the first 127 values.
The reason is, that the gain cannot be set directly by writing a value into the
gain
Em 02-06-2011 12:17, Devin Heitmueller escreveu:
On Thu, Jun 2, 2011 at 10:41 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
1. Assemble tree with current patches
It is probably easier for me to do this step, as I have my hg import
scripts. However, as I don't have the PCTV devices
Em 02-06-2011 12:53, Mohammad Bahathir Hashim escreveu:
Now I understood how thing works here, and it clear to me, why the
xc4000 driver is not being included in mainline V4L2.
It will be lots of commitments and hard work to be the maintainer, and
I respect Mr. Devin's choice and decisions.
Hi Mauro,
On Fri, May 20, 2011 at 19:28:49, Hadli, Manjunath wrote:
move vpif related code for capture and display drivers
from dm646x platform header file to vpif.h as these definitions
are related to driver code more than the platform or board.
Signed-off-by: Manjunath Hadli
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:Thu Jun 2 19:00:42 CEST 2011
git hash:f9b51477fe540fb4c65a05027fdd6f2ecce4db3b
gcc version: i686-linux-gcc (GCC)
Mauro Carvalho Chehab mche...@redhat.com wrote:
This is the list of the patches currently on my queue (13 patches from
patchwork and one patch that patchwork lost due to a database
corruption).
There's not much patches there, as I've applied most of the pending
stuff. Unfortunately, however,
First stab at iommu consolidation:
- Migrate OMAP's iommu driver to the generic iommu API. With this in hand,
users can now start using the generic iommu layer instead of calling
omap-specific iommu API.
New code that requires functionality missing from the generic iommu api,
will add
Migrate OMAP's iommu to the generic iommu api, so users can stay
generic, and non-omap-specific code can be removed and eventually
consolidated into a generic framework.
Tested on both OMAP3 and OMAP4.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/plat-omap/Kconfig |
Create a dedicated folder for iommu drivers, and move the base
iommu implementation over there.
Grouping the varius iommu drivers in a single location will help
finding similar problems shared by different platforms, so they
could be solved once, in the iommu framework, instead of solved
This should ease finding similarities with other platforms,
with the intention of solving problems once in a generic framework
which everyone can use.
Signed-off-by: Ohad Ben-Cohen o...@wizery.com
---
arch/arm/mach-msm/Kconfig | 12
Move OMAP's iommu drivers to the dedicated iommu drivers folder.
While OMAP's iovmm (virtual memory manager) driver does not strictly
belong to the iommu drivers folder, move it there as well, because
it's by no means OMAP-specific (in concept. technically it is still
coupled with the omap
First step towards migrating omap3isp to the generic iommu api.
At this point we still need a handle of the omap-specific iommu, mainly
because we highly depend on omap's iovmm.
Migration will be fully completed only once omap's iovmm will be generalized
(or replaced by a generic virtual memory
Migrate omap's iovmm (virtual memory manager) to the generic iommu api.
This brings iovmm a step forward towards being completely non
omap-specific (it's still assuming omap's iommu page sizes, and also
maintaining state inside omap's internal iommu structure, but it no
longer calls omap-specific
Hi Ohad,
On Wednesday 01 June 2011 18:39:46 Ohad Ben-Cohen wrote:
Fix a potential NULL pointer dereference by skipping registration of
external entities in case none are provided.
This is useful at least when testing mere memory-to-memory scenarios.
Signed-off-by: Ohad Ben-Cohen
Hi,
Good approach.
CC'ed the Samsung IOMMU developer. Marek.
BTW, Russell wants to use the DMA based IOMMU?
Please see the RFC patch, ARM: DMA-mapping IOMMU integration
http://www.spinics.net/lists/linux-mm/msg19856.html
Thank you,
Kyungmin Park
On Fri, Jun 3, 2011 at 7:27 AM, Ohad Ben-Cohen
Hi Javier,
On Thursday 02 June 2011 15:52:57 javier Martin wrote:
Hi,
I'm trying to add VFLIP control to the mt9p031 driver (don't worry
Guennadi, I won't send the patch yet). For that purpose I've followed
the code in mt9v032 sensor.
When I try to query available controls using yavta I get
On Thu, 02 Jun 2011 11:41:53 -0300
Mauro Carvalho Chehab mche...@redhat.com wrote:
Em 02-06-2011 07:52, Devin Heitmueller escreveu:
2011/5/31 Dmitri Belimov d.beli...@gmail.com:
Is it possible make some patches and add support xc4000 into
kernel?
With my best regards, Dmitry.
What
On Thu, Jun 2, 2011 at 00:52, Marek Szyprowski m.szyprow...@samsung.com wrote:
Add maintainers for the videobuf2 V4L2 driver framework.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
MAINTAINERS | 9 +
1 files
Thank you for the comments and pointers. I am happy, at least there
are peoples who want to see the xc4000 driver alive.
On 2011-06-02, Mauro Carvalho Chehab mche...@redhat.com wrote:
Em 02-06-2011 12:53, Mohammad Bahathir Hashim escreveu:
Now I understood how thing works here, and it clear to
I'd like to write a driver for an Anchor Chips (seems to be bought by
Cypress) USB camera Linux driver sold as an AmScope MD1800. It seems
like this implies I need to write a V4L2 driver. The camera does not
seem its currently supported (checked on Fedora 13 / 2.6.34.8) and I did
not find any
49 matches
Mail list logo
