iommu_domain_free() was called in isp_remove() before omap3isp_put().
omap3isp_put() must not save the context if the IOMMU no longer is there.
Fix this.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
The issue only seems to affect the staging/for_v3.4 branch in
media-tree.git.
Hi Sakari,
Thanks for the patch.
On Friday 27 January 2012 10:05:55 Sakari Ailus wrote:
iommu_domain_free() was called in isp_remove() before omap3isp_put().
omap3isp_put() must not save the context if the IOMMU no longer is there.
Fix this.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Please ignore! I will send out a new version in a minute.
Thanks and best regards,
~Sumit.
On Fri, Jan 27, 2012 at 3:04 PM, Sumit Semwal sumit.sem...@ti.com wrote:
Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
enum dma_data_direction while unmapping.
Thus, the
Hi Laurent,
On Fri, Jan 27, 2012 at 10:36:02AM +0100, Laurent Pinchart wrote:
On Friday 27 January 2012 10:05:55 Sakari Ailus wrote:
iommu_domain_free() was called in isp_remove() before omap3isp_put().
omap3isp_put() must not save the context if the IOMMU no longer is there.
Fix this.
Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
enum dma_data_direction for both map and unmap operations.
Thus, the unmap dma_buf_op also needs to have enum dma_data_direction as
a parameter.
Reported-by: Tomasz Stanislawski t.stanisl...@samsung.com
Signed-off-by: Sumit
Hi Marek,
With v19, I can't seem to allocate big regions anymore (e.g. 101MiB).
In particular, this seems to fail:
On Thu, Jan 26, 2012 at 11:00 AM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
+static int cma_activate_area(unsigned long base_pfn, unsigned long count)
+{
+ unsigned
Hi Mauro,
Can you please pull the following patch for v3.3-rc1 which removes some
unnecessary inclusion
of machine specific header files from the main driver files?
This patch has undergone sufficient review already. It is just a cleanup patch
and I don't
expect any functionality to break
On 01/27/2012 01:02 AM, Jose Alberto Reguero wrote:
This patch add another Terratec H7 usb id to az6007 driver.
Jose Alberto
Signed-off-by: Jose Alberto Reguerojaregu...@telefonica.net
http://linux.terratec.de/tv_en.html
Confirms this, but it might be a good idea to let the defines reflect
iommu_domain_free() was called in isp_remove() before omap3isp_put().
omap3isp_put() must not save the context if the IOMMU no longer is there.
Fix this.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
Compared to v1, neither the ISP context is saved.
drivers/media/video/omap3isp/isp.c |
When using DMABUF streaming in non-planar mode, the v4l2_buffer::length
field holds the length of the buffer as required by userspace. Copy it
to the length of the first plane at QBUF time, as the plane length is
later checked against the dma-buf size.
Signed-off-by: Laurent Pinchart
Hi Ohad,
On Friday, January 27, 2012 10:44 AM Ohad Ben-Cohen wrote:
With v19, I can't seem to allocate big regions anymore (e.g. 101MiB).
In particular, this seems to fail:
On Thu, Jan 26, 2012 at 11:00 AM, Marek Szyprowski
m.szyprow...@samsung.com wrote:
+static int
The devnode already is a pointer in struct v4l2_subdev, we don't need a
pointer to that.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
This issue is present in for_v3.3 branch and in for_v3.4. This patch is for
the former.
drivers/media/video/omap3isp/ispccdc.c |3 +--
1 files
On Fri, Jan 27, 2012 at 2:21 AM, Hans Verkuil hverk...@xs4all.nl wrote:
Hi all,
I'm working on cleaning up some old radio drivers and while doing that I
started wondering about the usefulness of the radio_nr module option (and
the corresponding video_nr/vbi_nr module options for video
Hello Tomasz,
Sorry for a late reply. Please find my answers inline.
On 01/24/2012 05:36 PM, Tomasz Stanislawski wrote:
Hi,
On 01/24/2012 12:07 PM, Subash Patel wrote:
Hello Thomasz,
Instead of adding another IOCTL to query the file-descriptor in
user-space, why dont we extend the existing
Correct spelling reseting to resetting in
drivers/media/dvb/dvb-usb/lmedm04.c
Signed-off-by: Masanari Iida standby2...@gmail.com
---
drivers/media/dvb/dvb-usb/lmedm04.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c
Em 27-01-2012 11:36, Devin Heitmueller escreveu:
On Fri, Jan 27, 2012 at 2:21 AM, Hans Verkuil hverk...@xs4all.nl wrote:
Hi all,
I'm working on cleaning up some old radio drivers and while doing that I
started wondering about the usefulness of the radio_nr module option (and
the
2012/1/27 Marek Szyprowski m.szyprow...@samsung.com:
Hi Ohad,
On Friday, January 27, 2012 10:44 AM Ohad Ben-Cohen wrote:
With v19, I can't seem to allocate big regions anymore (e.g. 101MiB).
In particular, this seems to fail:
On Thu, Jan 26, 2012 at 11:00 AM, Marek Szyprowski
Hello,
On Friday, January 27, 2012 3:28 PM Clark, Rob wrote:
2012/1/27 Marek Szyprowski m.szyprow...@samsung.com:
Hi Ohad,
On Friday, January 27, 2012 10:44 AM Ohad Ben-Cohen wrote:
With v19, I can't seem to allocate big regions anymore (e.g. 101MiB).
In particular, this seems to
2012/1/27 Marek Szyprowski m.szyprow...@samsung.com:
I've tested it with 256MiB on Exynos4 platform. Could you check if the
problem also appears on 3.2-cma-v19 branch (I've uploaded it a few hours
ago)
Exactly what I needed, thanks :)
Both v18 and v19 seem to work fine with 3.2.
The above
2012/1/27 Marek Szyprowski m.szyprow...@samsung.com:
Ohad, could you tell a bit more about your issue?
Sure, feel free to ask.
Does this 'large region'
is a device private region (declared with dma_declare_contiguous())
Yes, it is.
See omap_rproc_reserve_cma() in:
Correct spelling unspported to unsupported in
drivers/media/video/ov6650.c
Signed-off-by: Masanari Iida standby2...@gmail.com
---
drivers/media/video/ov6650.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/ov6650.c b/drivers/media/video/ov6650.c
Hello,
On Friday, January 27, 2012 3:59 PM Ohad Ben-Cohen wrote:
2012/1/27 Marek Szyprowski m.szyprow...@samsung.com:
Ohad, could you tell a bit more about your issue?
Sure, feel free to ask.
Does this 'large region'
is a device private region (declared with dma_declare_contiguous())
A general question for mx2-camera: does it now after removal of legacy
i.MX27 support only support i.MX25 (state: unknown) and i.MX27 in eMMA
mode?
On Thu, 26 Jan 2012, Javier Martin wrote:
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- mx27 code
On Fri, Jan 27, 2012 at 03:13:28PM +0530, Sumit Semwal wrote:
Some exporters may use DMA map/unmap APIs in dma-buf ops, which require
enum dma_data_direction for both map and unmap operations.
Thus, the unmap dma_buf_op also needs to have enum dma_data_direction as
a parameter.
On Thu, 26 Jan 2012, Javier Martin wrote:
Add start_stream and stop_stream callback in order to enable
and disable the eMMa-PrP properly and save CPU usage avoiding
IRQs when the device is not streaming. This also makes the driver
return 0 as the sequence number of the first frame.
The output from VIDIOC_LOG_STATUS should be bracketed by a 'START STATUS' and
'END STATUS' line to clearly group the status report in the kernel log and to
make it possible for a tool like v4l2-ctl to easily find and show the status
output.
Often this was forgotten, so this is now done
From: Hans Verkuil hans.verk...@cisco.com
Add the start and end messages for log_status when called from a
subdev device node.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-subdev.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff
From: Hans Verkuil hans.verk...@cisco.com
For drivers that properly use the v4l2 framework (i.e. set v4l2_dev in the
video_device struct), the start and end messages of VIDIOC_LOG_STATUS are
now generated automatically. People tended to forget these, but the v4l2-ctl
tool scans for these
(removing bar...@tkos.co.il - it bounces)
On Thu, 26 Jan 2012, javier Martin wrote:
Hi Guennadi,
On 25 January 2012 13:12, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
On Fri, 20 Jan 2012, Javier Martin wrote:
The way discard buffer was previously handled lead
to possible races
On Thu, 26 Jan 2012, Javier Martin wrote:
The way discard buffer was previously handled lead
to possible races that made a buffer that was not
yet ready to be overwritten by new video data. This
is easily detected at 25fps just adding #define DEBUG
to enable the memset check and seeing how
(removed bar...@tkos.co.il - it bounces)
On Thu, 26 Jan 2012, Javier Martin wrote:
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- Make ifs in irq callback mutually exclusive.
- Add new argument to mx27_camera_frame_done_emma() to handle errors.
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date:Fri Jan 27 19:00:18 CET 2012
git hash:59b30294e14fa6a370fdd2bc2921cca1f977ef16
gcc version: i686-linux-gcc
From: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/vivi.c | 13 +
1 files changed, 1 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index cef8c91..28d7112 100644
Many drivers just support control events, and most radio drivers just need
to poll for control events. Add some functions to simplify those jobs.
These two patches sit on top of these two:
http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/44032
--
To unsubscribe from this
From: Hans Verkuil hans.verk...@cisco.com
Many drivers just support control events, and most radio drivers just need
to poll for control events. Add some functions to simplify those jobs.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/v4l2-ctrls.c | 20
---
drivers/media/dvb/frontends/m88rs2000.c | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/drivers/media/dvb/frontends/m88rs2000.c
b/drivers/media/dvb/frontends/m88rs2000.c
index a614ffe..9d29b40 100644
--- a/drivers/media/dvb/frontends/m88rs2000.c
+++
This was added when a small error appeared in the upper end
frequencies in an old calculation.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/frontends/m88rs2000.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git
Sometimes, a otherwise good lock is lost after offset force.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/frontends/m88rs2000.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/dvb/frontends/m88rs2000.c
Hello Hans,
On 01/27/2012 06:59 PM, Hans Verkuil wrote:
diff --git a/drivers/media/video/v4l2-ioctl.c
b/drivers/media/video/v4l2-ioctl.c
index d0d7281..2348669 100644
--- a/drivers/media/video/v4l2-ioctl.c
+++ b/drivers/media/video/v4l2-ioctl.c
@@ -1911,7 +1911,15 @@ static long
On Thu, 2012-01-26 at 14:56 -0200, Mauro Carvalho Chehab wrote:
Em 22-01-2012 08:38, Malcolm Priestley escreveu:
Support for m88brs2000 chip used in lmedm04 driver.
Note there are still lock problems.
Slow channel change due to the large block of registers sent in
set_frontend.
DVB-T also use step_size=0.
Jose Alberto
diff -ur linux/drivers/media/dvb/frontends/drxk_hard.c linux.new/drivers/media/dvb/frontends/drxk_hard.c
--- linux/drivers/media/dvb/frontends/drxk_hard.c 2012-01-22 02:53:17.0 +0100
+++ linux.new/drivers/media/dvb/frontends/drxk_hard.c 2012-01-23
Increase mt2063 frequency_max to tune to channel 69(858Mhz).
Jose Alberto
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
diff -ur linux/drivers/media/common/tuners/mt2063.c linux.new/drivers/media/common/tuners/mt2063.c
--- linux/drivers/media/common/tuners/mt2063.c 2012-01-22
On Viernes, 27 de Enero de 2012 23:34:49 Jose Alberto Reguero escribió:
DVB-T also use step_size=0.
Jose Alberto
Signed-off-by: Jose Alberto Reguero jaregu...@telefonica.net
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
On Thu, 26 Jan 2012 15:31:40 +
Arnd Bergmann a...@arndb.de wrote:
On Thursday 26 January 2012, Marek Szyprowski wrote:
Welcome everyone!
Yes, that's true. This is yet another release of the Contiguous Memory
Allocator patches. This version mainly includes code cleanups requested
44 matches
Mail list logo
