i2c_gate_ctrl question
Hi media men women,
I have a question regarding the cxd2820r I'm working on with a couple of
other people.
In my naivety I implemented i2c gate control for the device (to access
the tuner behind it) as a separate i2c device that did the passthrough.
Now that I realise this, it would make sense to use the gate_ctrl
features.
However, picking apart the USB data it looks as though the way the
cxd2820r implements gate control isn't immediately compatible with the
implementation seen in other devices.
Example, and I2C send to the tuner at (addr 1) of:
{ xx, xx, ..., xx}
becomes a write to (demod_addr 1) of :
{ 09, (addr 1) | flags, xx, xx, ..., xx}
And an i2c receive is implemented to a receive from the demod address,
not from the tuner address.
So, unless there are open and close gate commands that aren't apparent
from the snoop, or there's something I've missed, all i2c transfers to
the tuner have to be mangled - sorry I mean encapsulated - prior to
sending. To my understanding this doesn't fit in with the gate_ctrl
implementation for i2c.
I haven't had time to examine all other gate control implementations in
the media modules, so if anyone knows any good examples that might work
in a similar way, I'd appreciate the tip-off. Otherwise, would there be
any objections to my implementation of a dummy i2c device that does the
encapsulation?
Regards,
--
Steve Kerrison MEng Hons.
http://www.stevekerrison.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: i2c_gate_ctrl question
On 7 March 2011 09:52, Steve Kerrison st...@stevekerrison.com wrote:
Hi media men women,
I have a question regarding the cxd2820r I'm working on with a couple of
other people.
In my naivety I implemented i2c gate control for the device (to access
the tuner behind it) as a separate i2c device that did the passthrough.
Now that I realise this, it would make sense to use the gate_ctrl
features.
However, picking apart the USB data it looks as though the way the
cxd2820r implements gate control isn't immediately compatible with the
implementation seen in other devices.
Example, and I2C send to the tuner at (addr 1) of:
{ xx, xx, ..., xx}
becomes a write to (demod_addr 1) of :
{ 09, (addr 1) | flags, xx, xx, ..., xx}
And an i2c receive is implemented to a receive from the demod address,
not from the tuner address.
So, unless there are open and close gate commands that aren't apparent
from the snoop, or there's something I've missed, all i2c transfers to
the tuner have to be mangled - sorry I mean encapsulated - prior to
sending. To my understanding this doesn't fit in with the gate_ctrl
implementation for i2c.
I haven't had time to examine all other gate control implementations in
the media modules, so if anyone knows any good examples that might work
in a similar way, I'd appreciate the tip-off. Otherwise, would there be
any objections to my implementation of a dummy i2c device that does the
encapsulation?
Yup, it sounds like the gate_ctrl code won't work in this case and
you'll need a seperate i2c bus.
An example is the cx24123 demod, which creates its own i2c tuner bus.
--
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: BUG at mm/mmap.c:2309 when cx18.ko and cx18-alsa.ko loaded
At Fri, 04 Mar 2011 12:13:04 -0500, Andy Walls wrote: On Fri, 2011-03-04 at 10:50 -0500, Devin Heitmueller wrote: On Thu, Mar 3, 2011 at 9:06 PM, Andy Walls awa...@md.metrocast.net wrote: Hi, I got a BUG when loading the cx18.ko module (which in turn requests the cx18-alsa.ko module) on a kernel built from this repository http://git.linuxtv.org/media_tree.git staging/for_v2.6.39 which I beleive is based on 2.6.38-rc2. The BUG is mmap related and I'm almost certain it has to do with userspace accessing cx18-alsa.ko ALSA device nodes, since cx18.ko doesn't provide any mmap() related file ops. So here is my transcription of a fuzzy digital photo of the screen: snip I'm not very familiar with mmap() nor ALSA and I did not author the cx18-alsa part of the cx18 driver, so any hints at where to look for the problem are appreciated. Hi Andy, I'm traveling on business for about two weeks, so I won't be able to look into this right now. Any idea whether this is some new regression? I do not know. I normally don't let cx18-alsa.ko load, due to PulseAudio's persistence at keeping the device nodes open (which makes unloading the cx18.ko module for development a hassle.) I'm just trying to understand whether this is something that has always been there since I originally added the ALSA support to cx18 or whether it's something that is new, in which case it might make sense to drag the ALSA people into the conversation since there haven't been any changes in the cx18 driver lately. I can add some information about what is going on in userspace. This was on a Fedora 10 machine. When devices nodes show up, the HAL daemon and PulseAudio start using the device nodes right away. That activity triggers cx18.ko to do a firmware load which gets udevd running to satisfy firmware requests, and then the cx18 driver issues some simple commands to the CX23418 firmware, which will have acknowledgment interrupts coming back from the CX23418. I resolved the firmware race in cx18*.ko a while ago, so I'm confident its not an issue. The BUG looks like some sort of mmap() race or memory management problem outside of the cx18*.ko modules, given that mmput(), which appears to be an mm specific reference counting function, is involved. It could also be in ALSA I guess. There is no change in ALSA core regarding mmap for really long time. If it's a regression, it must be triggered by some other changes. Takashi -- 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] omap3isp: lane shifter support
Hi Laurent,
Thanks for the review.
On 03/04/2011 05:33 PM, Laurent Pinchart wrote:
Hi Michael,
Thanks for the patch.
On Friday 04 March 2011 09:58:04 Michael Jones wrote:
Signed-off-by: Michael Jones michael.jo...@matrix-vision.de
---
drivers/media/video/omap3-isp/isp.c | 82
+- drivers/media/video/omap3-isp/isp.h |
4 +-
drivers/media/video/omap3-isp/ispccdc.c |2 +-
drivers/media/video/omap3-isp/ispvideo.c | 65 +---
drivers/media/video/omap3-isp/ispvideo.h |3 +
5 files changed, 134 insertions(+), 22 deletions(-)
diff --git a/drivers/media/video/omap3-isp/isp.c
b/drivers/media/video/omap3-isp/isp.c index 08d90fe..20e6daa 100644
--- a/drivers/media/video/omap3-isp/isp.c
+++ b/drivers/media/video/omap3-isp/isp.c
@@ -273,6 +273,44 @@ static void isp_power_settings(struct isp_device *isp,
int idle) }
/*
+ * Decide whether desired output pixel code can be obtained with
+ * the lane shifter by shifting the input pixel code.
+ * return 1 if the combination is possible
+ * return 0 otherwise
+ */
+int omap3isp_is_shiftable(enum v4l2_mbus_pixelcode in,
+enum v4l2_mbus_pixelcode out)
As you only use this function in ispvideo.c, I would move it there. You could
also make the function return a bool.
I thought returning a bool was inconsistent with kernel style (e.g.
isp_pipeline_is_last, ccdc_lsc_is_configured return int).
+{
+const struct isp_format_info *in_info, *out_info;
+int shiftable = 0;
+if ((in == 0) || (out == 0))
+return 0;
Can this happen ?
+
+if (in == out)
+return 1;
+
+in_info = omap3isp_video_format_info(in);
+out_info = omap3isp_video_format_info(out);
+if ((!in_info) || (!out_info))
+return 0;
Can this happen ?
These were all relics of previous versions when I was also calling
omap3isp_is_shiftable() from ccdc_try_format(). I will move it to
ispvideo.c and remove the two if statements.
+
+if (in_info-flavor != out_info-flavor)
+return 0;
+
+switch (in_info-bpp - out_info-bpp) {
+case 2:
+case 4:
+case 6:
+shiftable = 1;
+break;
+default:
+shiftable = 0;
+}
What about
return in_info-bpp - out_info-bpp = 6;
As long as there are never formats which are the same flavor but shifted
1, 3, or 5 bits, that's fine. I suppose this is a safe assumption?
+
+return shiftable;
+}
+
+/*
* Configure the bridge and lane shifter. Valid inputs are
*
* CCDC_INPUT_PARALLEL: Parallel interface
@@ -288,6 +326,10 @@ void omap3isp_configure_bridge(struct isp_device *isp,
const struct isp_parallel_platform_data *pdata)
{
u32 ispctrl_val;
+u32 depth_in = 0, depth_out = 0;
+u32 shift;
+const struct isp_format_info *fmt_info;
+struct media_pad *srcpad;
ispctrl_val = isp_reg_readl(isp, OMAP3_ISP_IOMEM_MAIN, ISP_CTRL);
ispctrl_val = ~ISPCTRL_SHIFT_MASK;
@@ -298,7 +340,6 @@ void omap3isp_configure_bridge(struct isp_device *isp,
switch (input) {
case CCDC_INPUT_PARALLEL:
ispctrl_val |= ISPCTRL_PAR_SER_CLK_SEL_PARALLEL;
-ispctrl_val |= pdata-data_lane_shift ISPCTRL_SHIFT_SHIFT;
ispctrl_val |= pdata-clk_pol ISPCTRL_PAR_CLK_POL_SHIFT;
ispctrl_val |= pdata-bridge ISPCTRL_PAR_BRIDGE_SHIFT;
break;
@@ -319,6 +360,45 @@ void omap3isp_configure_bridge(struct isp_device *isp,
return;
}
+/* find output format from the remote end of the link connected to
+ * CCDC sink pad
+ */
+srcpad = media_entity_remote_source(isp-isp_ccdc.pads[CCDC_PAD_SINK]);
+if (srcpad == NULL)
+dev_err(isp-dev, No active input to CCDC.\n);
There's no need to test for NULL, as this function will only be called on
streamon, so the pipeline will be valid.
OK.
+if (media_entity_type(srcpad-entity) == MEDIA_ENT_T_V4L2_SUBDEV) {
The CCDC has no memory input, so this condition will always be true.
OK.
+struct v4l2_subdev *subdev =
+ media_entity_to_v4l2_subdev(srcpad-entity);
+struct v4l2_subdev_format fmt_src;
+fmt_src.pad = srcpad-index;
+fmt_src.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+if (!v4l2_subdev_call(subdev, pad, get_fmt, NULL, fmt_src)) {
+fmt_info =
+ omap3isp_video_format_info(fmt_src.format.code);
+depth_in = fmt_info ? fmt_info-bpp : 0;
+}
+}
+
+/* find CCDC input format */
+fmt_info = omap3isp_video_format_info
+(isp-isp_ccdc.formats[CCDC_PAD_SINK].code);
+depth_out = fmt_info ? fmt_info-bpp : 0;
+
+isp-isp_ccdc.syncif.datsz = depth_out;
+
+/* determine necessary shifting */
+if (depth_in ==
Re: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Em 06-03-2011 14:21, Laurent Pinchart escreveu:
Hi Mauro,
On Sunday 06 March 2011 14:32:44 Mauro Carvalho Chehab wrote:
Em 06-03-2011 08:38, Laurent Pinchart escreveu:
On Sunday 06 March 2011 11:56:04 Mauro Carvalho Chehab wrote:
Em 05-03-2011 20:23, Sylwester Nawrocki escreveu:
A somewhat unrelated question that occurred to me today: what happens
when a format change happens while streaming?
Considering that some formats need more bits than others, this could
lead into buffer overflows, either internally at the device or
externally, on bridges that just forward whatever it receives to the
DMA buffers (there are some that just does that). I didn't see anything
inside the mc code preventing such condition to happen, and probably
implementing it won't be an easy job. So, one alternative would be to
require some special CAPS if userspace tries to set the mbus format
directly, or to recommend userspace to create media controller nodes
with 0600 permission.
That's not really a media controller issue. Whether formats can be
changed during streaming is a driver decision. The OMAP3 ISP driver
won't allow formats to be changed during streaming. If the hardware
allows for such format changes, drivers can implement support for that
and make sure that no buffer overflow will occur.
Such issues is caused by having two API's that allow format changes, one
that does it device-based, and another one doing it subdev-based.
Ok, drivers can implementing locks to prevent such troubles, but, without
the core providing a reliable mechanism, it is hard to implement a
correct lock.
For example, let's suppose that some driver is using mt9m111 subdev (I just
picked one random sensor that supports lots of MBUS formats). There's
nothing there preventing a subdev call for it to change mbus format while
streaming. Worse than that, the sensor driver has no way to block it, as
it doesn't know that the bridge driver is streaming or not.
The code at subdev_do_ioctl() is just:
case VIDIOC_SUBDEV_S_FMT: {
struct v4l2_subdev_format *format = arg;
if (format-which != V4L2_SUBDEV_FORMAT_TRY
format-which != V4L2_SUBDEV_FORMAT_ACTIVE)
return -EINVAL;
if (format-pad = sd-entity.num_pads)
return -EINVAL;
return v4l2_subdev_call(sd, pad, set_fmt, subdev_fh, format);
}
So, mc core won't be preventing it.
So, I can't see how such subdev request would be implementing a logic to
return -EBUSY on those cases.
Drivers can use the media_device graph_mutex to serialize format and stream
management calls. A finer grain locking mechanism implemented in the core
might be better, but we're not stuck without a solution at the moment.
Ok, i see. This is not the best world, as I suspect that developers will
just try to enable media controller for a few devices without taking enough
care to avoid buffer overflows.
While we don't have a better way for doing it, please add a note at the kernel
api doc saying about that, briefly describing how to properly lock it, because
this is not obvious at all.
Cheers,
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 PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Em 06-03-2011 07:17, Laurent Pinchart escreveu: Hi Sakari, On Sunday 06 March 2011 09:34:50 Sakari Ailus wrote: Hi Laurent, Many thanks for the pull req! On Thu, Feb 17, 2011 at 04:06:58PM +0100, Laurent Pinchart wrote: ... drivers/media/video/omap3-isp/ispresizer.c | 1693 ++ drivers/media/video/omap3-isp/ispresizer.h | 147 ++ drivers/media/video/omap3-isp/ispstat.c| 1092 + drivers/media/video/omap3-isp/ispstat.h| 169 ++ drivers/media/video/omap3-isp/ispvideo.c | 1264 ++ drivers/media/video/omap3-isp/ispvideo.h | 202 ++ drivers/media/video/omap3-isp/luma_enhance_table.h | 42 + drivers/media/video/omap3-isp/noise_filter_table.h | 30 + ... include/linux/Kbuild |4 + include/linux/media.h | 132 ++ include/linux/omap3isp.h | 646 + What about renaming the directory omap3isp for the sake of consistency? The header file is called omap3isp.h and omap3isp is the prefix used in the driver for exported symbols. I'm fine with both. If Mauro prefers omap3-isp, I can update the patches. Probably, omap3-isp would be better, but I'm fine if you prefere omap3isp. Cheers, 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 PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Em 05-03-2011 17:48, Laurent Pinchart escreveu: Hi Mauro, On Saturday 05 March 2011 19:22:28 Mauro Carvalho Chehab wrote: Em 05-03-2011 10:02, Laurent Pinchart escreveu: Hi Mauro, Thanks for the review. Let me address all your concerns in a single mail. - ioctl numbers I'll send you a patch that reserves a range in Documentation/ioctl/ioctl- number.txt and update include/linux/media.h accordingly. Ok, thanks. media: Pick a free ioctls range at the top of the http://git.linuxtv.org/pinchartl/media.git?a=shortlog;h=refs/heads/media-2.6.39-0005- omap3isp branch Added in the end of my quilt series. - private ioctls As already explained by David, the private ioctls are used to control advanced device features that can't be handled by V4L2 controls at the moment (such as setting a gamma correction table). Using those ioctls is not mandatory, and the device will work correctly without them (albeit with a non optimal image quality). David said he will submit a patch to document the ioctls. Ok. Working on that. Laurent/David, any news on that? - media bus formats As Hans explained, there's no 1:1 relationship between media bus formats and pixel formats. Yet, there are some relationship between them. See my comments on my previous email. Let's continue the discussion in the mail thread. - FOURCC and media bus codes documentation I forgot to document some of them. I'll send a new patch that adds the missing documentation. Ok. v4l: Add documentation for the 12 bits bayer pixel formats v4l: Fix 12 bits bayer media bus format documentation in the http://git.linuxtv.org/pinchartl/media.git?a=shortlog;h=refs/heads/media-2.6.39-0004- v4l-misc branch. Is there any other issue I need to address ? Nothing else, in the patches I've analysed so far. I'll take a look at the remaining omap3isp after receiving the documentation for the private ioctl's. My understanding is that there's no need to rebase the existing patches, is that correct ? Yes, it is correct. Just send the new patches to be applied at the end of the series. I'll eventually reorder them if needed to avoid breaking git bisect. Please squash v4l: Add documentation for the 12 bits bayer pixel formats with v4l: Add 12 bits bayer pixel formats and v4l: Fix 12 bits bayer media bus format documentation with v4l: Add missing 12 bits bayer media bus formats when applying to keep the history clean. You can discard the commit message of the two new patches. Added both patches and folded them as requested, and added the remaining patches after my review. The new tree is at: http://git.linuxtv.org/mchehab/experimental.git?a=shortlog;h=refs/heads/media_controller The pending issues for merging it to the main devel branch are: - omap3isp private control description; - a chapter describing how *MBUS* and fourcc formats are related; - a description about how to lock between MBUS/fourcc get/set format; - a renaming patch to make directory name and file names consistent. 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: Media Build broken
Seems that whilst the last round of build errors have been fixed but another has appeared. Looks like the file ti_wilink_st.h can't be found. Not the only person with this problem. See also http://www.gossamer-threads.com/lists/mythtv/users/474287?nohighlight=1#474287 Should be fixed now. Not all drivers seems to be automatically enabled when I do my daily build, I should look into that because otherwise I'd have seen this yesterday. Thanks for reporting this! Regards, Hans /Pete CC [M] /home/peter/media_build/v4l/em28xx-cards.o CC [M] /home/peter/media_build/v4l/fmdrv_common.o /home/peter/media_build/v4l/fmdrv_common.c:41: fatal error: linux/ti_wilink_st.h: No such file or directory compilation terminated. make[3]: *** [/home/peter/media_build/v4l/fmdrv_common.o] Error 1 make[2]: *** [_module_/home/peter/media_build/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.35-27-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/peter/media_build/v4l' make: *** [all] Error 2 *** ERROR. Aborting *** -- Hans Verkuil - video4linux developer - sponsored by Cisco -- 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 PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
On Mon, Mar 07, 2011 at 08:56:31AM -0300, Mauro Carvalho Chehab wrote: Em 06-03-2011 07:17, Laurent Pinchart escreveu: Hi Sakari, On Sunday 06 March 2011 09:34:50 Sakari Ailus wrote: Hi Laurent, Many thanks for the pull req! On Thu, Feb 17, 2011 at 04:06:58PM +0100, Laurent Pinchart wrote: ... drivers/media/video/omap3-isp/ispresizer.c | 1693 ++ drivers/media/video/omap3-isp/ispresizer.h | 147 ++ drivers/media/video/omap3-isp/ispstat.c| 1092 + drivers/media/video/omap3-isp/ispstat.h| 169 ++ drivers/media/video/omap3-isp/ispvideo.c | 1264 ++ drivers/media/video/omap3-isp/ispvideo.h | 202 ++ drivers/media/video/omap3-isp/luma_enhance_table.h | 42 + drivers/media/video/omap3-isp/noise_filter_table.h | 30 + ... include/linux/Kbuild |4 + include/linux/media.h | 132 ++ include/linux/omap3isp.h | 646 + What about renaming the directory omap3isp for the sake of consistency? The header file is called omap3isp.h and omap3isp is the prefix used in the driver for exported symbols. I'm fine with both. If Mauro prefers omap3-isp, I can update the patches. Probably, omap3-isp would be better, but I'm fine if you prefere omap3isp. Hi Mauro, Laurent, I'm also fine with omap3-isp. My point was that we should be consistent in naming. If the symbol prefix and the file / directory names are a little different that is certainly not an issue to me. So the change to the current state of the patchset would be that the header file was be called omap3-isp.h, right? Cheers, -- Sakari Ailus sakari dot ailus at retiisi dot org dot uk -- 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 PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Em 07-03-2011 10:00, Mauro Carvalho Chehab escreveu:
Em 07-03-2011 09:02, Hans Verkuil escreveu:
On Monday, March 07, 2011 12:50:28 Mauro Carvalho Chehab wrote:
Em 06-03-2011 14:21, Laurent Pinchart escreveu:
Hi Mauro,
On Sunday 06 March 2011 14:32:44 Mauro Carvalho Chehab wrote:
Em 06-03-2011 08:38, Laurent Pinchart escreveu:
On Sunday 06 March 2011 11:56:04 Mauro Carvalho Chehab wrote:
Em 05-03-2011 20:23, Sylwester Nawrocki escreveu:
A somewhat unrelated question that occurred to me today: what happens
when a format change happens while streaming?
Considering that some formats need more bits than others, this could
lead into buffer overflows, either internally at the device or
externally, on bridges that just forward whatever it receives to the
DMA buffers (there are some that just does that). I didn't see anything
inside the mc code preventing such condition to happen, and probably
implementing it won't be an easy job. So, one alternative would be to
require some special CAPS if userspace tries to set the mbus format
directly, or to recommend userspace to create media controller nodes
with 0600 permission.
That's not really a media controller issue. Whether formats can be
changed during streaming is a driver decision. The OMAP3 ISP driver
won't allow formats to be changed during streaming. If the hardware
allows for such format changes, drivers can implement support for that
and make sure that no buffer overflow will occur.
Such issues is caused by having two API's that allow format changes, one
that does it device-based, and another one doing it subdev-based.
Ok, drivers can implementing locks to prevent such troubles, but, without
the core providing a reliable mechanism, it is hard to implement a
correct lock.
For example, let's suppose that some driver is using mt9m111 subdev (I
just
picked one random sensor that supports lots of MBUS formats). There's
nothing there preventing a subdev call for it to change mbus format while
streaming. Worse than that, the sensor driver has no way to block it, as
it doesn't know that the bridge driver is streaming or not.
The code at subdev_do_ioctl() is just:
case VIDIOC_SUBDEV_S_FMT: {
struct v4l2_subdev_format *format = arg;
if (format-which != V4L2_SUBDEV_FORMAT_TRY
format-which != V4L2_SUBDEV_FORMAT_ACTIVE)
return -EINVAL;
if (format-pad = sd-entity.num_pads)
return -EINVAL;
return v4l2_subdev_call(sd, pad, set_fmt, subdev_fh, format);
}
So, mc core won't be preventing it.
So, I can't see how such subdev request would be implementing a logic to
return -EBUSY on those cases.
Drivers can use the media_device graph_mutex to serialize format and stream
management calls. A finer grain locking mechanism implemented in the core
might be better, but we're not stuck without a solution at the moment.
Am I missing something here? Isn't it as simple as remembering whether the
subdev is in streaming mode (s_stream(1) was called) or not? When streaming
any attempt to change the format should return an error (unless the hardware
can handle it, of course).
This is the same as for the 'regular' V4L2 API.
Not all subdevs implement s_stream, and I suspect that not all bridge drivers
calls it. The random example I've looked didn't implement (mt9m111.c), but
even
some that implements it (like mt9m001.c) currently don't store the stream
status
or use it to prevent a format change.
At the moment we open the possibility to directly access the subdev,
developers might think that all they need to use the new API is to enable
the subdev to create subdev nodes (btw, the first mc patch series were
enabling
it by default). However, opening subdev access without address such issues
will
lead into a security breach, as buffer overflows will happen if hardware
can't
handle format changes in the middle of a streaming [1].
Also, a lock there will only work if properly implemented at the bridge
driver,
as a bridge driver that implement the media controller should implement
something
like the following sequence (at VIDIOC_REQBUFS):
lock_format_changes_at_subdev();/* step 1 */
get_subdev_formats(); /* step 2 */
program_bridge_to follow_subdev_format_and_s_fmt(); /* step 3 */
reserve_memory(); /* step 4 */
start_streaming(); /* step 5 */
In the above, s_stream should be called at the step 1, and not at step 5, as,
otherwise, a race condition will happen, if a MBUS format change happens
between
step 1 and 5.
In time: assuming that s_stream would implement such lock.
Also: it this is a mandatory requirement, it should be part of API
documentation.
Otherwise, we'll have subdevs that will implement the lock using one way, and
others
using a
[PATCH] omap: iommu: disallow mapping NULL address
From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00 2001 From: Michael Jones michael.jo...@matrix-vision.de Date: Mon, 7 Mar 2011 13:36:15 +0100 Subject: [PATCH] omap: iommu: disallow mapping NULL address commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL address if da_start==0. Force da_start to exclude the first page. Signed-off-by: Michael Jones michael.jo...@matrix-vision.de --- arch/arm/plat-omap/iommu.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c index 5990ea6..dcb5513 100644 --- a/arch/arm/plat-omap/iommu.c +++ b/arch/arm/plat-omap/iommu.c @@ -850,7 +850,7 @@ int iommu_set_da_range(struct iommu *obj, u32 start, u32 end) if (end start || !PAGE_ALIGN(start | end)) return -EINVAL; - obj-da_start = start; + obj-da_start = max(start, (u32)PAGE_SIZE); obj-da_end = end; return 0; @@ -950,7 +950,9 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev) obj-name = pdata-name; obj-dev = pdev-dev; obj-ctx = (void *)obj + sizeof(*obj); - obj-da_start = pdata-da_start; + + /* reserve the first page for NULL */ + obj-da_start = max(pdata-da_start, (u32)PAGE_SIZE); obj-da_end = pdata-da_end; mutex_init(obj-iommu_lock); -- 1.7.4.1 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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 PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Hi Mauro, On Monday 07 March 2011 12:57:30 Mauro Carvalho Chehab wrote: Em 05-03-2011 17:48, Laurent Pinchart escreveu: [snip] Added both patches and folded them as requested, and added the remaining patches after my review. The new tree is at: http://git.linuxtv.org/mchehab/experimental.git?a=shortlog;h=refs/heads/med ia_controller The pending issues for merging it to the main devel branch are: - omap3isp private control description; Still working on that, I expect to send it this evening. - a chapter describing how *MBUS* and fourcc formats are related; This still needs to be discussed, there's no agreement on that yet. - a description about how to lock between MBUS/fourcc get/set format; From Documentation/media-framework.txt: If other operations need to be disallowed on streaming entities (such as changing entities configuration parameters) drivers can explictly check the media_entity stream_count field to find out if an entity is streaming. This operation must be done with the media_device graph_mutex held. So it's already there :-) And the media_entity_pipeline_start() function makes it easy to implement in bridge driver. - a renaming patch to make directory name and file names consistent. Done. I've pushed the modified patches to the media-2.6.39-0005-omap3isp branch. The media-2.6.39-0004-v4l-misc branch has also been rebased to squash the format documentation patches as you did in your tree. There's no need to pull anything from it. -- 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
Re: [GIT PULL FOR 2.6.39] Media controller and OMAP3 ISP driver
Hi Mauro,
On Monday 07 March 2011 14:00:20 Mauro Carvalho Chehab wrote:
Em 07-03-2011 09:02, Hans Verkuil escreveu:
On Monday, March 07, 2011 12:50:28 Mauro Carvalho Chehab wrote:
Em 06-03-2011 14:21, Laurent Pinchart escreveu:
On Sunday 06 March 2011 14:32:44 Mauro Carvalho Chehab wrote:
Em 06-03-2011 08:38, Laurent Pinchart escreveu:
On Sunday 06 March 2011 11:56:04 Mauro Carvalho Chehab wrote:
Em 05-03-2011 20:23, Sylwester Nawrocki escreveu:
A somewhat unrelated question that occurred to me today: what
happens when a format change happens while streaming?
Considering that some formats need more bits than others, this could
lead into buffer overflows, either internally at the device or
externally, on bridges that just forward whatever it receives to the
DMA buffers (there are some that just does that). I didn't see
anything inside the mc code preventing such condition to happen, and
probably implementing it won't be an easy job. So, one alternative
would be to require some special CAPS if userspace tries to set the
mbus format directly, or to recommend userspace to create media
controller nodes with 0600 permission.
That's not really a media controller issue. Whether formats can be
changed during streaming is a driver decision. The OMAP3 ISP driver
won't allow formats to be changed during streaming. If the hardware
allows for such format changes, drivers can implement support for
that and make sure that no buffer overflow will occur.
Such issues is caused by having two API's that allow format changes,
one that does it device-based, and another one doing it subdev-based.
Ok, drivers can implementing locks to prevent such troubles, but,
without the core providing a reliable mechanism, it is hard to
implement a correct lock.
For example, let's suppose that some driver is using mt9m111 subdev
(I just picked one random sensor that supports lots of MBUS formats).
There's nothing there preventing a subdev call for it to change mbus
format while streaming. Worse than that, the sensor driver has no way
to block it, as it doesn't know that the bridge driver is streaming or
not.
The code at subdev_do_ioctl() is just:
case VIDIOC_SUBDEV_S_FMT: {
struct v4l2_subdev_format *format = arg;
if (format-which != V4L2_SUBDEV_FORMAT_TRY
format-which != V4L2_SUBDEV_FORMAT_ACTIVE)
return -EINVAL;
if (format-pad = sd-entity.num_pads)
return -EINVAL;
return v4l2_subdev_call(sd, pad, set_fmt, subdev_fh, format);
}
So, mc core won't be preventing it.
So, I can't see how such subdev request would be implementing a logic
to return -EBUSY on those cases.
Drivers can use the media_device graph_mutex to serialize format and
stream management calls. A finer grain locking mechanism implemented in
the core might be better, but we're not stuck without a solution at the
moment.
Am I missing something here? Isn't it as simple as remembering whether
the subdev is in streaming mode (s_stream(1) was called) or not? When
streaming any attempt to change the format should return an error (unless
the hardware can handle it, of course).
This is the same as for the 'regular' V4L2 API.
Not all subdevs implement s_stream, and I suspect that not all bridge
drivers calls it. The random example I've looked didn't implement
(mt9m111.c), but even some that implements it (like mt9m001.c) currently
don't store the stream status or use it to prevent a format change.
Those drivers don't implement subdev pad-level operations, so they won't work
with the media controller anyway. They will need to be fixed, and locking can
then be implemented.
At the moment we open the possibility to directly access the subdev,
developers might think that all they need to use the new API is to enable
the subdev to create subdev nodes (btw, the first mc patch series were
enabling it by default). However, opening subdev access without address
such issues will lead into a security breach, as buffer overflows will
happen if hardware can't handle format changes in the middle of a
streaming [1].
Also, a lock there will only work if properly implemented at the bridge
driver, as a bridge driver that implement the media controller should
implement something like the following sequence (at VIDIOC_REQBUFS):
lock_format_changes_at_subdev();/* step 1 */
get_subdev_formats(); /* step 2 */
program_bridge_to follow_subdev_format_and_s_fmt(); /* step 3 */
reserve_memory(); /* step 4 */
start_streaming(); /* step 5 */
In the above, s_stream should be called at the step 1, and not at step 5,
as, otherwise, a race condition will happen, if a MBUS format change
happens between step
ngene CI problems
Hi all! I'm trying to make the DVB_DEVICE_SEC approach work, however I'm experiencing certain problems with the following setup: Software: Linux 2.6.34.8 (vanilla) drivers from http://linuxtv.org/hg/~endriss/v4l-dvb/ Hardware: Digital Devices CineS2 + CI Module Problems: - Packets get lost in SEC device: I write complete TS to SEC, but when reading from SEC there are discontinuities on the CC. - SEC device generates NULL packets (ad infinitum): When reading from SEC, NULL packets are read and interleaved with expected packets. They can be even read with dd(1) when nobody is writing to SEC and even when CAM is not ready. - SEC device blocks on CAM re-insertion: When CAM is removed from the slot and inserted again, all read() operations just hang. Rebooting resolves the problem. - SEC device does not respect O_NONBLOCK: In connection to the previous problem, SEC device blocks even if opened with O_NONBLOCK. Best regards, Martin Vidovic -- 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: Hauppauge WinTV USB 2
Hello Folks, I am having hardtime capturing video from this card. Last two weeks I spent on getting signal from my DTH box. It's a single analog signal from the DTH set up box. From windows, I scan this signal and I am able to see video through this card. So the card is working and signal is there! Also, zeroed in on Zapping for TV viewing as many of the other applications didn't work properly. But other scanners (tvtime-scanner) and zapping's own TV scanner is not able to find this signal. Is there a way? I am not sure the tuner is working correctly or not. Last few lines in the logs before the actual scan start are the following: kernel: [22630.244052] xc2028 1-0061: Loading firmware for type=BASE F8MHZ (3), id . [22705.056058] xc2028 1-0061: Loading firmware for type=(0), id 0007. kernel: [22706.316042] xc2028 1-0061: Loading SCODE for type=MONO SCODE HAS_IF_5320 (60008000), id 0007 And lots of following messages in dmesg: [24529.394089] tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) [24529.399854] tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) [24529.405641] tm6000 tm6000_irq_callback :urb resubmit failed (error=-1) Any ideas? Thanks, Vivek. On Thursday 24 February 2011 15:49:37 you wrote: On Thursday 24 February 2011 04:08:48 Mauro Carvalho Chehab wrote: Although I know that some Hauppauge devices are supported by tm6010, I'm not sure if someone added the tm6010 USB ID's for The model you have to the tm6000 driver. Some good news! I compiled the latest kernel (as available in debian repo) which had tm6000 in the staging directory. And now my card is being detected. I was expecting the module would be auto-detected but it wasn't. I had to modprobe it. No complaints though :) I have not yet connected the card to the cable, so can't comment on the quality of the video capture. I will do that and comment in couple of days time. Thanks Devin/Mauro!! If anyone is interested in testing the card, I would be more than willing to do that. Here's the output from the logs: Feb 25 02:06:31 kaddappa kernel: [ 330.788092] usb 5-7: new high speed USB device using ehci_hcd and address 8 Feb 25 02:06:31 kaddappa kernel: [ 330.926110] usb 5-7: New USB device found, idVendor=2040, idProduct=6610 Feb 25 02:06:31 kaddappa kernel: [ 330.926118] usb 5-7: New USB device strings: Mfr=16, Product=32, SerialNumber=64 Feb 25 02:06:31 kaddappa kernel: [ 330.926123] usb 5-7: Product: WTV910 Feb 25 02:06:31 kaddappa kernel: [ 330.926127] usb 5-7: SerialNumber: 12502365 Feb 25 02:07:06 kaddappa kernel: [ 365.641255] Linux video capture interface: v2.00 Feb 25 02:07:06 kaddappa kernel: [ 365.692765] IR NEC protocol handler initialized Feb 25 02:07:06 kaddappa kernel: [ 365.704001] IR RC5(x) protocol handler initialized Feb 25 02:07:06 kaddappa kernel: [ 365.719226] tm6000: module is from the staging directory, the quality is unknown, you have been warned. Feb 25 02:07:06 kaddappa kernel: [ 365.724790] tm6000 v4l2 driver version 0.0.2 loaded Feb 25 02:07:06 kaddappa kernel: [ 365.725827] tm6000: alt 0, interface 0, class 255 Feb 25 02:07:06 kaddappa kernel: [ 365.725830] tm6000: alt 0, interface 0, class 255 Feb 25 02:07:06 kaddappa kernel: [ 365.725832] tm6000: Bulk IN endpoint: 0x82 (max size=512 bytes) Feb 25 02:07:06 kaddappa kernel: [ 365.725835] tm6000: alt 0, interface 0, class 255 Feb 25 02:07:06 kaddappa kernel: [ 365.725837] tm6000: alt 1, interface 0, class 255 Feb 25 02:07:06 kaddappa kernel: [ 365.725840] tm6000: ISOC IN endpoint: 0x81 (max size=3072 bytes) Feb 25 02:07:06 kaddappa kernel: [ 365.725842] tm6000: alt 1, interface 0, class 255 Feb 25 02:07:06 kaddappa kernel: [ 365.725844] tm6000: alt 1, interface 0, class 255 Feb 25 02:07:06 kaddappa kernel: [ 365.725847] tm6000: INT IN endpoint: 0x83 (max size=4 bytes) Feb 25 02:07:06 kaddappa kernel: [ 365.725849] tm6000: alt 2, interface 0, class 255 Feb 25 02:07:06 kaddappa kernel: [ 365.725851] tm6000: alt 2, interface 0, class 255 Feb 25 02:07:06 kaddappa kernel: [ 365.725854] tm6000: alt 2, interface 0, class 255 Feb 25 02:07:06 kaddappa kernel: [ 365.725856] tm6000: alt 3, interface 0, class 255 Feb 25 02:07:06 kaddappa kernel: [ 365.725858] tm6000: alt 3, interface 0, class 255 Feb 25 02:07:06 kaddappa kernel: [ 365.725860] tm6000: alt 3, interface 0, class 255 Feb 25 02:07:06 kaddappa kernel: [ 365.725863] tm6000: New video device @ 480 Mbps (2040:6610, ifnum 0) Feb 25 02:07:06 kaddappa kernel: [ 365.725865] tm6000: Found Hauppauge WinTV HVR-900H / WinTV USB2-Stick Feb 25 02:07:06 kaddappa kernel: [ 365.734061] IR RC6 protocol handler initialized Feb 25 02:07:06 kaddappa kernel: [ 365.736042] Found tm6010 Feb 25 02:07:06 kaddappa kernel: [ 365.739714] IR JVC protocol handler initialized Feb 25 02:07:06 kaddappa kernel: [ 365.746152] IR Sony protocol handler
Re: [PATCH 4/4] omap3isp: lane shifter support
Hi Michael,
On Monday 07 March 2011 11:53:26 Michael Jones wrote:
On 03/04/2011 05:33 PM, Laurent Pinchart wrote:
[snip]
+
+ if (in_info-flavor != out_info-flavor)
+ return 0;
+
+ switch (in_info-bpp - out_info-bpp) {
+ case 2:
+ case 4:
+ case 6:
+ shiftable = 1;
+ break;
+ default:
+ shiftable = 0;
+ }
What about
return in_info-bpp - out_info-bpp = 6;
As long as there are never formats which are the same flavor but shifted
1, 3, or 5 bits, that's fine. I suppose this is a safe assumption?
I think so. If we need to add support for those formats later we can revisit
the code.
+
+ return shiftable;
+}
+
+/*
* Configure the bridge and lane shifter. Valid inputs are
*
* CCDC_INPUT_PARALLEL: Parallel interface
[snip]
+ /* find CCDC input format */
+ fmt_info = omap3isp_video_format_info
+ (isp-isp_ccdc.formats[CCDC_PAD_SINK].code);
+ depth_out = fmt_info ? fmt_info-bpp : 0;
+
+ isp-isp_ccdc.syncif.datsz = depth_out;
+
+ /* determine necessary shifting */
+ if (depth_in == depth_out + 6)
+ shift = 3;
+ else if (depth_in == depth_out + 4)
+ shift = 2;
+ else if (depth_in == depth_out + 2)
+ shift = 1;
+ else
+ shift = 0;
Maybe shift = (depth_out - depth_in) / 2; ?
First of all, the other way around: (depth_in - depth_out). I suppose I
don't need to account for e.g. (depth_in - depth_out 6) because then
the pipeline would've been invalid in the first place? If I do this, I
would at least use ISPCTRL_SHIFT_MASK when writing 'shift' into
ispctrl_val as a final catch if something went wrong with shift.
Sounds good to me.
--
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
Re: NCT 677x lirc driver for Asrock 330HT and others
On Mar 6, 2011, at 5:53 AM, Steffen Barszus wrote: Hi ! Note sure where exactly to put it. Here is an lirc driver provided by Nuovoton as it seems, which can be downloaded from the vendors site: http://www.asrock.com/Nettop/download.asp?Model=ION%20330HTo=Linux It adds an lirc driver for the receiver as used in the Asrock 330HT and newer models from Asrock. Can this go into lirc, or better, can something be done to integrate it somehow ? We've had a nuvoton-cir rc-core driver, based loosely on that driver, in the kernel tree for a few months now. It was written using an Asrock ION 330HT provided to me by Nuvoton, and it works fantastically well. -- Jarod Wilson ja...@wilsonet.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
Compiling v4l fatal error: linux/ti_wilink_st.h: No such file or directory
I had MythTV .23 up and running fine on Mythbuntu 10.10 and then hosed it. I reinstalled it, and since then I can't get the drivers for my Haupphauge 2250 to compile on kernel 2.6.35-22-generic. When I figured it out last time I put it in a text file. Heres what I have done. I have since updated to MythTV .24 and the problem persists. wget http://www.steventoth.net/linux/hvr22xx/22xxdrv_27086.zip wget http://www.steventoth.net/linux/hvr22xx/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip wget http://www.steventoth.net/linux/hvr22xx/extract.sh sh extract.sh sudo cp *fw /lib/firmware git clone git://linuxtv.org/media_build.git cd media_build ./build.sh sudo make install The first time it breaks, this is expected. I edit v4l/.config and change CONFIG_DVB_FIREDTV=m to CONFIG_DVB_FIREDTV=n I compile again, and it should work. But it breaks. Heres the message I get. make[2]: Leaving directory `/path/media_build/linux' make -C /lib/modules/2.6.35-22-generic/build SUBDIRS=/path/media_build/v4l modules make[2]: Entering directory `/usr/src/linux-headers-2.6.35-22-generic' CC [M] /path/media_build/v4l/fmdrv_common.o /path/media_build/v4l/fmdrv_common.c:41: fatal error: linux/ti_wilink_st.h: No such file or directory compilation terminated. make[3]: *** [/path/media_build/v4l/fmdrv_common.o] Error 1 make[2]: *** [_module_/path/media_build/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.35-22-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/path/media_build/v4l' make: *** [all] Error 2 Why does it break? Thanks. -- 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] omap: iommu: disallow mapping NULL address
On Mon, Mar 7, 2011 at 7:10 AM, Michael Jones michael.jo...@matrix-vision.de wrote: From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00 2001 From: Michael Jones michael.jo...@matrix-vision.de Date: Mon, 7 Mar 2011 13:36:15 +0100 Subject: [PATCH] omap: iommu: disallow mapping NULL address commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL address if da_start==0. Force da_start to exclude the first page. what about devices that uses page 0? ipu after reset always starts from 0x how could we map that address?? Regards, Fernando. Signed-off-by: Michael Jones michael.jo...@matrix-vision.de --- arch/arm/plat-omap/iommu.c | 6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c index 5990ea6..dcb5513 100644 --- a/arch/arm/plat-omap/iommu.c +++ b/arch/arm/plat-omap/iommu.c @@ -850,7 +850,7 @@ int iommu_set_da_range(struct iommu *obj, u32 start, u32 end) if (end start || !PAGE_ALIGN(start | end)) return -EINVAL; - obj-da_start = start; + obj-da_start = max(start, (u32)PAGE_SIZE); obj-da_end = end; return 0; @@ -950,7 +950,9 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev) obj-name = pdata-name; obj-dev = pdev-dev; obj-ctx = (void *)obj + sizeof(*obj); - obj-da_start = pdata-da_start; + + /* reserve the first page for NULL */ + obj-da_start = max(pdata-da_start, (u32)PAGE_SIZE); obj-da_end = pdata-da_end; mutex_init(obj-iommu_lock); -- 1.7.4.1 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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] omap: iommu: disallow mapping NULL address
On Mon, Mar 7, 2011 at 9:17 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Mon, Mar 7, 2011 at 7:10 AM, Michael Jones michael.jo...@matrix-vision.de wrote: From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00 2001 From: Michael Jones michael.jo...@matrix-vision.de Date: Mon, 7 Mar 2011 13:36:15 +0100 Subject: [PATCH] omap: iommu: disallow mapping NULL address commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL address if da_start==0. Force da_start to exclude the first page. what about devices that uses page 0? ipu after reset always starts from 0x how could we map that address?? from 0x0? The driver sees da == 0 as error. May I ask you why do you want it? Br, David Regards, Fernando. Signed-off-by: Michael Jones michael.jo...@matrix-vision.de --- arch/arm/plat-omap/iommu.c | 6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c index 5990ea6..dcb5513 100644 --- a/arch/arm/plat-omap/iommu.c +++ b/arch/arm/plat-omap/iommu.c @@ -850,7 +850,7 @@ int iommu_set_da_range(struct iommu *obj, u32 start, u32 end) if (end start || !PAGE_ALIGN(start | end)) return -EINVAL; - obj-da_start = start; + obj-da_start = max(start, (u32)PAGE_SIZE); obj-da_end = end; return 0; @@ -950,7 +950,9 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev) obj-name = pdata-name; obj-dev = pdev-dev; obj-ctx = (void *)obj + sizeof(*obj); - obj-da_start = pdata-da_start; + + /* reserve the first page for NULL */ + obj-da_start = max(pdata-da_start, (u32)PAGE_SIZE); obj-da_end = pdata-da_end; mutex_init(obj-iommu_lock); -- 1.7.4.1 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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] omap: iommu: disallow mapping NULL address
On Mon, Mar 7, 2011 at 1:19 PM, David Cohen daco...@gmail.com wrote: On Mon, Mar 7, 2011 at 9:17 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Mon, Mar 7, 2011 at 7:10 AM, Michael Jones michael.jo...@matrix-vision.de wrote: From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00 2001 From: Michael Jones michael.jo...@matrix-vision.de Date: Mon, 7 Mar 2011 13:36:15 +0100 Subject: [PATCH] omap: iommu: disallow mapping NULL address commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL address if da_start==0. Force da_start to exclude the first page. what about devices that uses page 0? ipu after reset always starts from 0x how could we map that address?? from 0x0? The driver sees da == 0 as error. May I ask you why do you want it? unlike DSP that you can load a register with the addres the DSP will boot, IPU core always starts from address 0x, so if you take IPU out of reset it will try to access address 0x0 if not map it, there will be a mmu fault. Regards, Fernando. Br, David Regards, Fernando. Signed-off-by: Michael Jones michael.jo...@matrix-vision.de --- arch/arm/plat-omap/iommu.c | 6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c index 5990ea6..dcb5513 100644 --- a/arch/arm/plat-omap/iommu.c +++ b/arch/arm/plat-omap/iommu.c @@ -850,7 +850,7 @@ int iommu_set_da_range(struct iommu *obj, u32 start, u32 end) if (end start || !PAGE_ALIGN(start | end)) return -EINVAL; - obj-da_start = start; + obj-da_start = max(start, (u32)PAGE_SIZE); obj-da_end = end; return 0; @@ -950,7 +950,9 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev) obj-name = pdata-name; obj-dev = pdev-dev; obj-ctx = (void *)obj + sizeof(*obj); - obj-da_start = pdata-da_start; + + /* reserve the first page for NULL */ + obj-da_start = max(pdata-da_start, (u32)PAGE_SIZE); obj-da_end = pdata-da_end; mutex_init(obj-iommu_lock); -- 1.7.4.1 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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:Mon Mar 7 19:00:26 CET 2011 git hash:88a763df226facb74fdb254563e30e9efb64275c gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS 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.31.12-x86_64: WARNINGS 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 spec-git: ERRORS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification failed to build, but the last compiled spec 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] omap: iommu: disallow mapping NULL address
On Mon, Mar 7, 2011 at 9:25 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Mon, Mar 7, 2011 at 1:19 PM, David Cohen daco...@gmail.com wrote: On Mon, Mar 7, 2011 at 9:17 PM, Guzman Lugo, Fernando fernando.l...@ti.com wrote: On Mon, Mar 7, 2011 at 7:10 AM, Michael Jones michael.jo...@matrix-vision.de wrote: From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00 2001 From: Michael Jones michael.jo...@matrix-vision.de Date: Mon, 7 Mar 2011 13:36:15 +0100 Subject: [PATCH] omap: iommu: disallow mapping NULL address commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL address if da_start==0. Force da_start to exclude the first page. what about devices that uses page 0? ipu after reset always starts from 0x how could we map that address?? from 0x0? The driver sees da == 0 as error. May I ask you why do you want it? unlike DSP that you can load a register with the addres the DSP will boot, IPU core always starts from address 0x, so if you take IPU out of reset it will try to access address 0x0 if not map it, there will be a mmu fault. Hm. Looks like the iommu should not restrict any da. The valid da range should rely only on pdata. Michael, what about just update ISP's da_start on omap-iommu.c file? Set it to 0x1000. Hiroshi, any opinion? Br, David Regards, Fernando. Br, David Regards, Fernando. Signed-off-by: Michael Jones michael.jo...@matrix-vision.de --- arch/arm/plat-omap/iommu.c | 6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c index 5990ea6..dcb5513 100644 --- a/arch/arm/plat-omap/iommu.c +++ b/arch/arm/plat-omap/iommu.c @@ -850,7 +850,7 @@ int iommu_set_da_range(struct iommu *obj, u32 start, u32 end) if (end start || !PAGE_ALIGN(start | end)) return -EINVAL; - obj-da_start = start; + obj-da_start = max(start, (u32)PAGE_SIZE); obj-da_end = end; return 0; @@ -950,7 +950,9 @@ static int __devinit omap_iommu_probe(struct platform_device *pdev) obj-name = pdata-name; obj-dev = pdev-dev; obj-ctx = (void *)obj + sizeof(*obj); - obj-da_start = pdata-da_start; + + /* reserve the first page for NULL */ + obj-da_start = max(pdata-da_start, (u32)PAGE_SIZE); obj-da_end = pdata-da_end; mutex_init(obj-iommu_lock); -- 1.7.4.1 MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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
[Query][soc_camera] How to handle hosts w/color conversion built in?
Hi Guennadi and all, I've been trying to make my omap4 camera host driver to allow YUYV - NV12 color conversion, and add that to the supported host-client formats, but I think I have hit the wall with the host design. I noticed that the soc_camera seems to be designed to just pass-through the client supported formats (i.e. if my sensor supports YUYV and JPEG, those will be the supported formats only) Now, in my host driver, I have a feature to do a color conversion to NV12, but I'm still not sure on how to expand the supported formats to, say: YUYV, JPEG, and NV12 (which would be available only if the client outputs YUYV, of course). I was trying adding a customized get_formats function, but as soc_camera_init_user_formats anyways depends heavly on the sensor's enum_mbus_fmt, it's hard to add supported formats that the sensor doesn't directly support. Has this been done before? Any advice? Regards, Sergio -- 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: [Query][soc_camera] How to handle hosts w/color conversion built in?
On Mon, 7 Mar 2011, Sergio Aguirre wrote: Hi Guennadi and all, I've been trying to make my omap4 camera host driver to allow YUYV - NV12 color conversion, and add that to the supported host-client formats, but I think I have hit the wall with the host design. I noticed that the soc_camera seems to be designed to just pass-through the client supported formats (i.e. if my sensor supports YUYV and JPEG, those will be the supported formats only) No, this is not the case. Now, in my host driver, I have a feature to do a color conversion to NV12, but I'm still not sure on how to expand the supported formats to, say: YUYV, JPEG, and NV12 (which would be available only if the client outputs YUYV, of course). I was trying adding a customized get_formats function, but as soc_camera_init_user_formats anyways depends heavly on the sensor's enum_mbus_fmt, it's hard to add supported formats that the sensor doesn't directly support. Has this been done before? Any advice? Of course, this is supported. See sh_mobile_ceu.c, mx3_camera, pxa_camera, omap1_camera. Just search for the format array defined with static const struct soc_mbus_pixelfmt and see how it is used. Feel free to ask again, if you have more questions. 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
Re: [Query][soc_camera] How to handle hosts w/color conversion built in?
Hi Guennadi, Thanks for replying. On 03/07/2011 03:05 PM, Guennadi Liakhovetski wrote: On Mon, 7 Mar 2011, Sergio Aguirre wrote: Hi Guennadi and all, I've been trying to make my omap4 camera host driver to allow YUYV - NV12 color conversion, and add that to the supported host-client formats, but I think I have hit the wall with the host design. I noticed that the soc_camera seems to be designed to just pass-through the client supported formats (i.e. if my sensor supports YUYV and JPEG, those will be the supported formats only) No, this is not the case. Ok. Now, in my host driver, I have a feature to do a color conversion to NV12, but I'm still not sure on how to expand the supported formats to, say: YUYV, JPEG, and NV12 (which would be available only if the client outputs YUYV, of course). I was trying adding a customized get_formats function, but as soc_camera_init_user_formats anyways depends heavly on the sensor's enum_mbus_fmt, it's hard to add supported formats that the sensor doesn't directly support. Has this been done before? Any advice? Of course, this is supported. See sh_mobile_ceu.c, mx3_camera, pxa_camera, omap1_camera. Just search for the format array defined with static const struct soc_mbus_pixelfmt and see how it is used. Feel free to ask again, if you have more questions. Ahh... OK. I understand now :) So, you basically first determine the count of sensor formats, by looping through enum_mbus_fmt in the sensor, and with every call to get_formats with the index range, you can return 2 or more formats. In my case, when the sensor supports YUYV, I'll return 2 and update the xlate array with 2 entries, instead of just one, is that right? Sorry for the noise, and thanks for the patience :) I've been focusing more on the actual HW functionality, rather than the clean design. But now it's time to clean things up and prepare for upstreaming :) Regards, Sergio 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
Re: [PATCH] omap: iommu: disallow mapping NULL address
Hi David, On Monday 07 March 2011 20:41:21 David Cohen wrote: On Mon, Mar 7, 2011 at 9:25 PM, Guzman Lugo, Fernando wrote: On Mon, Mar 7, 2011 at 1:19 PM, David Cohen wrote: On Mon, Mar 7, 2011 at 9:17 PM, Guzman Lugo, Fernando wrote: On Mon, Mar 7, 2011 at 7:10 AM, Michael Jones wrote: From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00 2001 From: Michael Jones michael.jo...@matrix-vision.de Date: Mon, 7 Mar 2011 13:36:15 +0100 Subject: [PATCH] omap: iommu: disallow mapping NULL address commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL address if da_start==0. Force da_start to exclude the first page. what about devices that uses page 0? ipu after reset always starts from 0x how could we map that address?? from 0x0? The driver sees da == 0 as error. May I ask you why do you want it? unlike DSP that you can load a register with the addres the DSP will boot, IPU core always starts from address 0x, so if you take IPU out of reset it will try to access address 0x0 if not map it, there will be a mmu fault. Hm. Looks like the iommu should not restrict any da. The valid da range should rely only on pdata. Michael, what about just update ISP's da_start on omap-iommu.c file? Set it to 0x1000. What about patching the OMAP3 ISP driver to use a non-zero value (maybe -1) as an invalid/freed pointer ? -- 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
Re: [Query][soc_camera] How to handle hosts w/color conversion built in?
On Mon, 7 Mar 2011, Sergio Aguirre wrote: Of course, this is supported. See sh_mobile_ceu.c, mx3_camera, pxa_camera, omap1_camera. Just search for the format array defined with static const struct soc_mbus_pixelfmt and see how it is used. Feel free to ask again, if you have more questions. Ahh... OK. I understand now :) So, you basically first determine the count of sensor formats, by looping through enum_mbus_fmt in the sensor, and with every call to get_formats with the index range, you can return 2 or more formats. Actually 0 or more. Usually you return 1 if you just support the sensor format in pass-through mode. If you return more, that usually means, that in addition to pass-through you can also convert that sensor format to some other format. In my case, when the sensor supports YUYV, I'll return 2 and update the xlate array with 2 entries, instead of just one, is that right? Right - because you can pass YUYV 1-to-1 and also convert it to nv12. Thanks Guennadi Sorry for the noise, and thanks for the patience :) I've been focusing more on the actual HW functionality, rather than the clean design. But now it's time to clean things up and prepare for upstreaming :) Regards, Sergio Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ --- 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
Re: [PATCH] omap: iommu: disallow mapping NULL address
On Mon, Mar 7, 2011 at 11:19 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi David, Hi Laurent, On Monday 07 March 2011 20:41:21 David Cohen wrote: On Mon, Mar 7, 2011 at 9:25 PM, Guzman Lugo, Fernando wrote: On Mon, Mar 7, 2011 at 1:19 PM, David Cohen wrote: On Mon, Mar 7, 2011 at 9:17 PM, Guzman Lugo, Fernando wrote: On Mon, Mar 7, 2011 at 7:10 AM, Michael Jones wrote: From e7dbe4c4b64eb114f9b0804d6af3a3ca0e78acc8 Mon Sep 17 00:00:00 2001 From: Michael Jones michael.jo...@matrix-vision.de Date: Mon, 7 Mar 2011 13:36:15 +0100 Subject: [PATCH] omap: iommu: disallow mapping NULL address commit c7f4ab26e3bcdaeb3e19ec658e3ad9092f1a6ceb allowed mapping the NULL address if da_start==0. Force da_start to exclude the first page. what about devices that uses page 0? ipu after reset always starts from 0x how could we map that address?? from 0x0? The driver sees da == 0 as error. May I ask you why do you want it? unlike DSP that you can load a register with the addres the DSP will boot, IPU core always starts from address 0x, so if you take IPU out of reset it will try to access address 0x0 if not map it, there will be a mmu fault. Hm. Looks like the iommu should not restrict any da. The valid da range should rely only on pdata. Michael, what about just update ISP's da_start on omap-iommu.c file? Set it to 0x1000. What about patching the OMAP3 ISP driver to use a non-zero value (maybe -1) as an invalid/freed pointer ? I wouldn't be comfortable to use 0 (or NULL) value as valid address on ISP driver. The 'da' range (da_start and da_end) is defined per VM and specified as platform data. IMO, to set da_start = 0x1000 seems to be a correct approach for ISP as it's the only client for its IOMMU instance. Regards, David -- 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
Re: Compiling v4l fatal error: linux/ti_wilink_st.h: No such file or directory
On Mar 7, 2011, at 2:01 PM, Me wrote: I had MythTV .23 up and running fine on Mythbuntu 10.10 and then hosed it. I reinstalled it, and since then I can't get the drivers for my Haupphauge 2250 to compile on kernel 2.6.35-22-generic. When I figured it out last time I put it in a text file. Heres what I have done. I have since updated to MythTV .24 and the problem persists. wget http://www.steventoth.net/linux/hvr22xx/22xxdrv_27086.zip wget http://www.steventoth.net/linux/hvr22xx/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip wget http://www.steventoth.net/linux/hvr22xx/extract.sh sh extract.sh sudo cp *fw /lib/firmware git clone git://linuxtv.org/media_build.git cd media_build ./build.sh sudo make install The first time it breaks, this is expected. I edit v4l/.config and change CONFIG_DVB_FIREDTV=m to CONFIG_DVB_FIREDTV=n I compile again, and it should work. But it breaks. Heres the message I get. make[2]: Leaving directory `/path/media_build/linux' make -C /lib/modules/2.6.35-22-generic/build SUBDIRS=/path/media_build/v4l modules make[2]: Entering directory `/usr/src/linux-headers-2.6.35-22-generic' CC [M] /path/media_build/v4l/fmdrv_common.o /path/media_build/v4l/fmdrv_common.c:41: fatal error: linux/ti_wilink_st.h: No such file or directory compilation terminated. make[3]: *** [/path/media_build/v4l/fmdrv_common.o] Error 1 make[2]: *** [_module_/path/media_build/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.35-22-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/path/media_build/v4l' make: *** [all] Error 2 Why does it break? Thanks. Hans Verkuil pushed the fix for this to the media_build tree this morning. From looking at it, you'll need to get a fresh tarfile in linux/. http://git.linuxtv.org/media_build.git?a=commitdiff;h=bb1da6b26bc9d44182ec0cfd9ed2b0e04e3cbec0 -- Jarod Wilson ja...@wilsonet.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] Fix AF9015 Dual tuner i2c write failures
2011/3/7 adq a...@lidskialf.net: 2011/3/6 adq a...@lidskialf.net: 2011/3/5 adq a...@lidskialf.net: 2011/3/5 Juan Jesús García de Soria Lucena skanda...@gmail.com: Hi, Andrew. This is what happens to me with both the KWorld dual tuner (when using only one tuner) and the Avermedia Volar Black (single tuner), both based on AF9015. I also got corrupted streams with the KWorld when capturing via both tuners (the video our the audio would show artifacts in mythtv each several seconds). As far as the loss of tuning ability goes, I think it's a problem related to tuning itself, since it wouldn't happen when you just left a channel tuned and streaming in a simple client, but would trigger after a random time when you left mythtv scanning the channels for EIT data. I don't think it's a problem with a specific HW implementation, since I got it with both AF9015-based cards. It could be either a chipset quirk our a bug in the driver. My informal and quick tests with Windows Media Center and these cards did not reproduce the problem, when trying to change channels as quickly as possible, admittedly for not so long a time. Correct. I have two af9015 cards from different manufacturers as well, and they both exhibit the same problem. However, on a hunch last night, I went back to my original (-v1) patch with the total i2c bus lock and left it running with my tuning scripts for 10 hours. Both tuners are still working fine. That isn't conclusive, but it is encouraging. I'm just swapping back to a completely unpatched state to see how long it takes to break and to check if its easily reproducible (on my live system, it usually does it within a few hours of normal usage). Hi, right, I can reproduce it when completely unpatched, but it takes a while. I left HTS tvheadend running at the same time as dvbsnoop monitoring each frontend's status (so I had lots of i2c traffic going on), and it happened sometime overnight. I turned on all the idle scanning and frontend monitoring features tvheadend has. Now trying running the same with the -v1 patch. Hi, its been running for well over 24 hours now, and its still tuning fine. I'm obviously I'm going to leave it testing for more days, but I'm daring it to suddenly break as soon as I send this mail :) As you will recall, v3 implemented a lock around the i2cgate so that only one frontend could open it and therefore only one could access a tuner at a time. Since this didn't fix the issue, it implies that if the gate is open *any* other i2c access (e.g. just reading the ucblocks) can somehow crash the tuner in such a way that it needs a hardware reset. This means you'd need a complete lock around *anything* which can cause i2c traffic as v1 implements (assuming v1 does fix it that is). Anyway, I'm keeping it running for the moment. It'd be good if someone else who experiences this problem could try out v1 too though. Oh, I see these every now and then: af9015: recv bulk message failed:-71 af9015: af9015_rc_query: failed:-1 dvb-usb: error -1 while querying for an remote control event. They don't seem to cause a problem, but seems odd they should occur at all. Disabling rc polling fixes it as docced elsewhere, but why do they occur in the first place I wonder? Ah well, so its definitely /not/ conflicting i2c writes that cause the tuner problem as it has finally just died. The festats for a crashed tuner are: Sig: 50933 SNR: 50 BER: 0 UBLK: 5370554 Stat: 0x01 [SIG ] (no other error messages) For the other tuner, it is: Sig: 55703 SNR: 120 BER: 0 UBLK: 919 Stat: 0x1f [SIG CARR VIT SYNC LOCK ] Note the /massive/ difference in ubclocks; the tuner that died always had a massively larger UCBLOCKS count even when it was working fine. Antii, I'll try out your GPIO suggestions today or tomorrow, and I'll try and snag an i2c register dump to see if that sheds any light... -- 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: Compiling v4l fatal error: linux/ti_wilink_st.h: No such file or directory
Please keep your replies on the mailing list. On Mar 7, 2011, at 6:00 PM, Me wrote: Same problem. I purged both linux-headers-2.6.35-27-generic, linux-source-2.6.35, then reinstalled them, and did an apt-get update/upgrade. I then deleted media_build and ran... git clone git://linuxtv.org/media_build.git cd media_build ./build.sh Compile breaks vi vrl/.config changed CONFIG_DVB_FIREDTV=m to =n ./build.sh ...same problem. Did I miss anything? Looks like the linux-media.tar.bz2 file that build.sh downloads needs to be updated to include the header still. Hans' change makes it so that will happen, but it hasn't yet. I suspect it'll get updated soon though. If you're impatient, just clone media_tree and within media_build/linux, do a 'make tar DIR=path/to/media_tree' and you can create your own. Mar 7, 2011 at 3:57 PM, Jarod Wilson ja...@wilsonet.com wrote: On Mar 7, 2011, at 2:01 PM, Me wrote: I had MythTV .23 up and running fine on Mythbuntu 10.10 and then hosed it. I reinstalled it, and since then I can't get the drivers for my Haupphauge 2250 to compile on kernel 2.6.35-22-generic. When I figured it out last time I put it in a text file. Heres what I have done. I have since updated to MythTV .24 and the problem persists. wget http://www.steventoth.net/linux/hvr22xx/22xxdrv_27086.zip wget http://www.steventoth.net/linux/hvr22xx/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip wget http://www.steventoth.net/linux/hvr22xx/extract.sh sh extract.sh sudo cp *fw /lib/firmware git clone git://linuxtv.org/media_build.git cd media_build ./build.sh sudo make install The first time it breaks, this is expected. I edit v4l/.config and change CONFIG_DVB_FIREDTV=m to CONFIG_DVB_FIREDTV=n I compile again, and it should work. But it breaks. Heres the message I get. make[2]: Leaving directory `/path/media_build/linux' make -C /lib/modules/2.6.35-22-generic/build SUBDIRS=/path/media_build/v4l modules make[2]: Entering directory `/usr/src/linux-headers-2.6.35-22-generic' CC [M] /path/media_build/v4l/fmdrv_common.o /path/media_build/v4l/fmdrv_common.c:41: fatal error: linux/ti_wilink_st.h: No such file or directory compilation terminated. make[3]: *** [/path/media_build/v4l/fmdrv_common.o] Error 1 make[2]: *** [_module_/path/media_build/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.35-22-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/path/media_build/v4l' make: *** [all] Error 2 Why does it break? Thanks. Hans Verkuil pushed the fix for this to the media_build tree this morning. From looking at it, you'll need to get a fresh tarfile in linux/. http://git.linuxtv.org/media_build.git?a=commitdiff;h=bb1da6b26bc9d44182ec0cfd9ed2b0e04e3cbec0 -- Jarod Wilson ja...@wilsonet.com -- Jarod Wilson ja...@wilsonet.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: Compiling v4l fatal error: linux/ti_wilink_st.h: No such file or directory
Same problem. I purged both linux-headers-2.6.35-27-generic, linux-source-2.6.35, then reinstalled them, and did an apt-get update/upgrade. I then deleted media_build and ran... git clone git://linuxtv.org/media_build.git cd media_build ./build.sh Compile breaks vi vrl/.config changed CONFIG_DVB_FIREDTV=m to =n ./build.sh ...same problem. Did I miss anything? On Mar 7, 2011, at 3:57 PM, Jarod Wilson wrote: On Mar 7, 2011, at 2:01 PM, Me wrote: I had MythTV .23 up and running fine on Mythbuntu 10.10 and then hosed it. I reinstalled it, and since then I can't get the drivers for my Haupphauge 2250 to compile on kernel 2.6.35-22-generic. When I figured it out last time I put it in a text file. Heres what I have done. I have since updated to MythTV .24 and the problem persists. wget http://www.steventoth.net/linux/hvr22xx/22xxdrv_27086.zip wget http://www.steventoth.net/linux/hvr22xx/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip wget http://www.steventoth.net/linux/hvr22xx/extract.sh sh extract.sh sudo cp *fw /lib/firmware git clone git://linuxtv.org/media_build.git cd media_build ./build.sh sudo make install The first time it breaks, this is expected. I edit v4l/.config and change CONFIG_DVB_FIREDTV=m to CONFIG_DVB_FIREDTV=n I compile again, and it should work. But it breaks. Heres the message I get. make[2]: Leaving directory `/path/media_build/linux' make -C /lib/modules/2.6.35-22-generic/build SUBDIRS=/path/media_build/v4l modules make[2]: Entering directory `/usr/src/linux-headers-2.6.35-22-generic' CC [M] /path/media_build/v4l/fmdrv_common.o /path/media_build/v4l/fmdrv_common.c:41: fatal error: linux/ti_wilink_st.h: No such file or directory compilation terminated. make[3]: *** [/path/media_build/v4l/fmdrv_common.o] Error 1 make[2]: *** [_module_/path/media_build/v4l] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.35-22-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/path/media_build/v4l' make: *** [all] Error 2 Why does it break? Thanks. Hans Verkuil pushed the fix for this to the media_build tree this morning. From looking at it, you'll need to get a fresh tarfile in linux/. http://git.linuxtv.org/media_build.git?a=commitdiff;h=bb1da6b26bc9d44182ec0cfd9ed2b0e04e3cbec0 -- Jarod Wilson ja...@wilsonet.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
[PATCH] v4l: soc-camera: Store negotiated buffer settings
This fixes the problem in which a host driver
sets a personalized sizeimage or bytesperline field,
and gets ignored when doing G_FMT.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/soc_camera.c |9 -
include/media/soc_camera.h |2 ++
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index a66811b..59dc71d 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -363,6 +363,8 @@ static int soc_camera_set_fmt(struct soc_camera_device *icd,
icd-user_width = pix-width;
icd-user_height= pix-height;
icd-colorspace = pix-colorspace;
+ icd-bytesperline = pix-bytesperline;
+ icd-sizeimage = pix-sizeimage;
icd-vb_vidq.field =
icd-field = pix-field;
@@ -608,12 +610,9 @@ static int soc_camera_g_fmt_vid_cap(struct file *file,
void *priv,
pix-height = icd-user_height;
pix-field = icd-vb_vidq.field;
pix-pixelformat= icd-current_fmt-host_fmt-fourcc;
- pix-bytesperline = soc_mbus_bytes_per_line(pix-width,
- icd-current_fmt-host_fmt);
+ pix-bytesperline = icd-bytesperline;
pix-colorspace = icd-colorspace;
- if (pix-bytesperline 0)
- return pix-bytesperline;
- pix-sizeimage = pix-height * pix-bytesperline;
+ pix-sizeimage = icd-sizeimage;
dev_dbg(icd-dev, current_fmt-fourcc: 0x%08x\n,
icd-current_fmt-host_fmt-fourcc);
return 0;
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 9386db8..de81370 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -30,6 +30,8 @@ struct soc_camera_device {
s32 user_width;
s32 user_height;
enum v4l2_colorspace colorspace;
+ __u32 bytesperline; /* for padding, zero if unused */
+ __u32 sizeimage;
unsigned char iface;/* Host number */
unsigned char devnum; /* Device number per host */
struct soc_camera_sense *sense; /* See comment in struct definition */
--
1.7.1
--
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] V4L: soc-camera: Add support for custom host mmap
This helps redirect mmap calls to custom memory managers which
already have preallocated space to use by the device.
Otherwise, device might not support the allocation attempted
generically by videobuf.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/soc_camera.c |7 ++-
include/media/soc_camera.h |2 ++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 59dc71d..d361ba0 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -512,6 +512,7 @@ static ssize_t soc_camera_read(struct file *file, char
__user *buf,
static int soc_camera_mmap(struct file *file, struct vm_area_struct *vma)
{
struct soc_camera_device *icd = file-private_data;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
int err;
dev_dbg(icd-dev, mmap called, vma=0x%08lx\n, (unsigned long)vma);
@@ -519,7 +520,11 @@ static int soc_camera_mmap(struct file *file, struct
vm_area_struct *vma)
if (icd-streamer != file)
return -EBUSY;
- err = videobuf_mmap_mapper(icd-vb_vidq, vma);
+ /* Check for an interface custom mmaper */
+ if (ici-ops-mmap)
+ err = ici-ops-mmap(icd-vb_vidq, icd, vma);
+ else
+ err = videobuf_mmap_mapper(icd-vb_vidq, vma);
dev_dbg(icd-dev, vma start=0x%08lx, size=%ld, ret=%d\n,
(unsigned long)vma-vm_start,
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index de81370..11350c2 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -87,6 +87,8 @@ struct soc_camera_host_ops {
int (*set_ctrl)(struct soc_camera_device *, struct v4l2_control *);
int (*get_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
int (*set_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
+ int (*mmap)(struct videobuf_queue *, struct soc_camera_device *,
+struct vm_area_struct *);
unsigned int (*poll)(struct file *, poll_table *);
const struct v4l2_queryctrl *controls;
int num_controls;
--
1.7.1
--
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] davinci: vpfe: mdia controller implementation for capture
On Sun, Mar 06, 2011 at 22:59:40, Laurent Pinchart wrote: Hi Manjunath, On Sunday 06 March 2011 16:36:05 Manjunath Hadli wrote: Introduction This is the proposal of the initial version of design and implementation of the Davinci family (dm644x,dm355,dm365)VPFE (Video Port Front End) drivers using Media Controloler , the initial version which supports the following: 1) dm365 vpfe 2) ccdc,previewer,resizer,h3a,af blocks 3) supports only continuous mode and not on-the-fly 4) supports user pointer exchange and memory mapped modes for buffer allocation This driver bases its design on Laurent Pinchart's Media Controller Design whose patches for Media Controller and subdev enhancements form the base. The driver also takes copious elements taken from Laurent Pinchart and others' OMAP ISP driver based on Media Controller. So thank you all the people who are responsible for the Media Controller and the OMAP ISP driver. You're welcome :-) Also, the core functionality of the driver comes from the arago vpfe capture driver of which the CCDC capture was based on V4L2, with other drivers like Previwer, Resizer and other being individual character drivers. The CCDC, preview and resizer modules look very similar to their OMAP3 counterparts. I think we should aim at sharing code between the drivers. It's hard enough to develop, review and maintain one driver, let's not duplicate the effort. Laurent, the modules in DM365 and DM355 are based on ISIF (for image capture) IPIPEIF, IPIPE and these modules are very different from that of their OMAP3 counterparts both in terms of hardware features, implementation and registers. The naming is done as CCDC, Previewer and Resizer only because to make it simple in understanding and making it comfortable for the API users of DM644X. I am aware of the discussion you and Vaibhav had, where he mentioned your point to make these drivers similar, and after Poring through the specs in detail we concluded that the approach can be the same but code-re-use is be minimal. So, we have derived the top level approach from you while the core implementation of hardware programming comes from arago. The current driver caters to dm6446,dm355 and dm365 of which the current implementation works for dm365. The three VPFE IPs have some common elements in terms of some highe level functionality but there are differences in terms of register definitions and some core blocks. The individual specifications for each of these can be found here: dm6446 vpfe: http://www.ti.com/litv/pdf/sprue38h dm355 vpfe: http://www.ti.com/litv/pdf/spruf71a dm365 vpfe: http://www.ti.com/litv/pdf/sprufg8c The initial version of the driver implementation can be found here: http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git?a=shortlog;h =refs /heads/mc_release Driver Design: Main entities The hardware modules for dm355,dm365 are mainly ipipe, ipipeif,isif. These hardware modules are generically exposed to the user level in the for of dm6446 style modules. Mainly - ccdc, previewer, resizer in addition to the other histogram and auto color/white balance correction and auto focus modules. 1)MT9P031 sensor module for RAW capture 2)TVP7002 decoder module for HD inputs 3)TVP514x decoder module for SD inputs 4)CCDC capture module 5)Previewer Module for Bayer to YUV conversion 6)Resizer Module for scaling Connection for on-the-fly capture - Mt9P031 --CCDC---Previewer(optional)---Resizer(optional)---Video TVP7002 --- TV514x --- File Organisation - main driver files drivers/media/video/davinci/vpfe_capture.c include/media/davinci/vpfe_capture.h Instantiatiation of the v4l2 device, media device and all subdevs from here. video Interface files - drivers/media/video/davinci/vpfe_video.c include/media/davinci/vpfe_video.h Implements all the v4l2 video operations with a generic implementation for continuous and one shot mode. subdev interface files -- These file implement the subdev interface functionality for each of the subdev entities - mainly the entry points and their implementations in a IP generic way. drivers/media/video/davinci/vpfe_ccdc.c drivers/media/video/davinci/vpfe_previewer.c drivers/media/video/davinci/vpfe_resizer.c drivers/media/video/davinci/vpfe_af.c drivers/media/video/davinci/vpfe_aew.c drivers/media/video/tvp514x.c drivers/media/video/tvp7002.c drivers/media/video/ths7353.c include/media/davinci/vpfe_ccdc.h include/media/davinci/vpfe_previewer.h include/media/davinci/vpfe_resizer.h include/media/davinci/vpfe_af.h include/media/davinci/vpfe_aew.h include/media/tvp514x.h
[RFC 1/1] v4l: videobuf2: Add Exynos devices based allocator, named SDVMM
SDVMM: Shared Device Virtual Memory Management
This patch adds new videobuf2 memory allocator dedicated to Exynos.
This allocator gets memory using VCM which can get memory its own allocator
and also get memory via CMA optionally.
It requires the following 4 modules.
UMP (Unified Memory Provider), suggested by ARM.
VCM (Virtual Contiguous Memory framework), submitted by Samsung
CMA (Contiguous Memory Allocator), submitted by Samsung
SYS.MMU (System MMU), submitted by Samsung.
Signed-off-by: Jonghun Han jonghun@samsung.com
---
drivers/media/video/videobuf2-sdvmm.c | 659 +
include/media/videobuf2-sdvmm.h | 58 +++
2 files changed, 717 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/videobuf2-sdvmm.c
create mode 100644 include/media/videobuf2-sdvmm.h
diff --git a/drivers/media/video/videobuf2-sdvmm.c
b/drivers/media/video/videobuf2-sdvmm.c
new file mode 100644
index 000..06e12aa
--- /dev/null
+++ b/drivers/media/video/videobuf2-sdvmm.c
@@ -0,0 +1,659 @@
+/* linux/drivers/media/video/videobuf2-sdvmm.c
+ *
+ * Copyright (c) 2010 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com/
+ *
+ * Implementation of SDVMM memory allocator for videobuf2
+ * SDVMM : Shared Device Virtual Memory Management
+ *
+ * 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.
+*/
+
+#include linux/err.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mm.h
+#include linux/sched.h
+#include linux/slab.h
+#include linux/vmalloc.h
+#include linux/cma.h
+#include linux/vcm-drv.h
+
+#include plat/s5p-vcm.h
+#include media/videobuf2-sdvmm.h
+
+#include ump_kernel_interface.h
+#include ump_kernel_interface_ref_drv.h
+#include ump_kernel_interface_vcm.h
+
+static int sdvmm_debug;
+module_param(sdvmm_debug, int, 0644);
+#define dbg(level, fmt, arg...)
\
+ do {\
+ if (sdvmm_debug = level) \
+ printk(KERN_DEBUG vb2_sdvmm: fmt, ## arg); \
+ } while (0)
+
+struct vb2_sdvmm_conf {
+ spinlock_t slock;
+
+ /* For CMA */
+ struct device *dev;
+ const char *type;
+ unsigned long alignment;
+ booluse_cma;
+
+ /* For VCMM */
+ struct vcm *vcm_ctx;
+ enum vcm_dev_id vcm_id;
+
+ /* SYS.MMU */
+ boolmmu_clk;
+ bool(*get_power)(void *);
+
+ void*priv;
+};
+
+struct vb2_sdvmm_buf {
+ struct vm_area_struct *vma;
+ struct vb2_sdvmm_conf *conf;
+ struct vb2_vmarea_handler handler;
+
+ atomic_tref;
+ unsigned long size;
+
+ struct vcm_res *vcm_res;
+ struct vcm_res *vcm_res_kern;
+ ump_dd_handle ump_dd_handle;
+ unsigned long dva_offset;
+};
+
+static void vb2_sdvmm_put(void *buf_priv);
+static int _vb2_sdvmm_mmap_pfn_range(struct vm_area_struct *vma,
+struct vcm_phys *vcm_phys,
+unsigned long size,
+const struct vm_operations_struct *vm_ops,
+void *priv);
+
+static void *_vb2_sdvmm_ump_register(struct vb2_sdvmm_buf *buf)
+{
+ struct vcm_phys_part*part = buf-vcm_res-phys-parts;
+ ump_dd_physical_block *blocks;
+ ump_dd_handle *handle;
+ struct ump_vcm ump_vcm;
+ int num_blocks = buf-vcm_res-phys-count;
+ int block_size, i;
+
+ block_size = sizeof(ump_dd_physical_block) * num_blocks;
+ blocks = (ump_dd_physical_block *)vmalloc(block_size);
+ for (i = 0; i num_blocks; i++) {
+ blocks[i].addr = part-start;
+ blocks[i].size = part-size;
+ ++part;
+
+ dbg(6, block addr(0x%08x), size(0x%08x)\n,
+ (u32)blocks[i].addr, (u32)blocks[i].size);
+ }
+
+ handle = ump_dd_handle_create_from_phys_blocks(blocks, num_blocks);
+ vfree(blocks);
+ if (handle == UMP_DD_HANDLE_INVALID) {
+ pr_err(ump_dd_handle_create_from_phys_blocks failed\n);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ ump_vcm.vcm = buf-conf-vcm_ctx;
+ ump_vcm.vcm_res = buf-vcm_res;
+ ump_vcm.dev_id = buf-conf-vcm_id;
+
+ if (ump_dd_meminfo_set(handle, (void *)ump_vcm)) {
+ ump_dd_reference_release(handle);
+ return ERR_PTR(-EINVAL);
+ }
+
+ return (void *)handle;
+}
+
[RFC 0/1] v4l: videobuf2: Add Exynos devices based allocator, named SDVMM
== Introduction == The purpose of this RFC is to discuss the vb2-allocator for multimedia devices available in upcoming Samsung SoC Exynos. Not all of them are merged or submitted by now, but I decided to post this for starting discussion about buffer management. vb2-sdvmm is an allocator using SDVMM. The SDVMM is not a implementation itself. It is the name of solution which integrates UMP, VCM, CMA and SYS.MMU. The main purposes of Shared Device Virtual Memory Management(aka SDVMM) are: 1. Inter-process buffer sharing using UMP 2. Device virtual memory management using VCM and SYS.MMU(aka IOMMU) 3. Contiguous memory allocation support using CMA == Related patchset == 1. UMP (Unified Memory Provider) - The UMP is an auxiliary component which enables memory to be shared across different applications, drivers and hardware components. - http://blogs.arm.com/multimedia/249-making-the-mali-gpu-device-driver-open-source/page__cid__133__show__newcomment/ - Suggested by ARM, Not submitted yet. 2. VCM (Virtual Contiguous Memory framework) - The VCM is a framework to deal with multiple IOMMUs in a system with intuitive and abstract objects - Submitted by Michal Nazarewicz @Samsung-SPRC - Also submitted by KyongHo Cho @Samsung-SYS.LSI - http://article.gmane.org/gmane.linux.kernel.mm/56912/match=vcm 3. CMA (Contiguous Memory Allocator) - The Contiguous Memory Allocator (CMA) is a framework, which allows setting up a machine-specific configuration for physically-contiguous memory management. Memory for devices is then allocated according to that configuration. - http://lwn.net/Articles/396702/ - http://www.spinics.net/lists/linux-media/msg26486.html - Submitted by Michal Nazarewicz @Samsung-SPRC 4. SYS.MMU - System mmu supports address transition from virtual address to physical address. - http://thread.gmane.org/gmane.linux.kernel.samsung-soc/3909 - Submitted by Sangbeom Kim - Merged by Kukjin Kim, ARM/S5P ARM ARCHITECTURES maintainer. == How to use == +---+ SecureId +---+ | Converter | -- | Renderer | +---+ +---+ ^| |^ ^ ^ || UVA || | | UVA | | UVA SecureId | || || | | +-+ | | +-+ +-+UVA by mmap | UMP | | | | UMP | | UMP | | | Lib | | | | Lib | | Lib | | +-+ | | +-+ +-+ | || || | | user space - || || | |kernel space |v v| | | | +---+ | |+--+ | | s5p-fimc | | || s3c-fb | | +---+ | |+--+ || || | ^ | +-+ +---+ +-+ +-+ | | | Ump |-|vb2|-| Ump | | Ump |--+ | | Drv | | sdvmm | | Drv | | Drv | | +-+ +---+ +-+ +-+ | | | | +---+ +---+ | VCM | |VCM| +---+ +---+ | | | | | +---+ | | |CMA| | | +---+ | DVA | | | | | +---+ | |SYS.MMU| | +---+ PA | | | v v v +---+ +---+ | FIMC| | FIMD| +---+ +---+ Basic flow - Output interface for source 1. Allocate discontiguous memory using UMP 2. Get User Virtual Address(aka UVA) 3. Send the UVA to the src(Output
Re: [PATCH] V4L: soc-camera: Add support for custom host mmap
Hi Sergio
On Mon, 7 Mar 2011, Sergio Aguirre wrote:
This helps redirect mmap calls to custom memory managers which
already have preallocated space to use by the device.
Otherwise, device might not support the allocation attempted
generically by videobuf.
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/soc_camera.c |7 ++-
include/media/soc_camera.h |2 ++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c
index 59dc71d..d361ba0 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -512,6 +512,7 @@ static ssize_t soc_camera_read(struct file *file, char
__user *buf,
static int soc_camera_mmap(struct file *file, struct vm_area_struct *vma)
{
struct soc_camera_device *icd = file-private_data;
+ struct soc_camera_host *ici = to_soc_camera_host(icd-dev.parent);
This doesn't seem to be needed
int err;
dev_dbg(icd-dev, mmap called, vma=0x%08lx\n, (unsigned long)vma);
@@ -519,7 +520,11 @@ static int soc_camera_mmap(struct file *file, struct
vm_area_struct *vma)
if (icd-streamer != file)
return -EBUSY;
- err = videobuf_mmap_mapper(icd-vb_vidq, vma);
+ /* Check for an interface custom mmaper */
mmapper - double 'p'
+ if (ici-ops-mmap)
+ err = ici-ops-mmap(icd-vb_vidq, icd, vma);
+ else
+ err = videobuf_mmap_mapper(icd-vb_vidq, vma);
You're patching an old version of soc-camera. Please use a current one
with support for videobuf2. Further, wouldn't it be possible for you to
just replace the videobuf mmap_mapper() (videobuf2 q-mem_ops-mmap())
method? I am not sure how possible this is, maybe one of videobuf2 experts
could help us? BTW, you really should be using the videobuf2 API.
dev_dbg(icd-dev, vma start=0x%08lx, size=%ld, ret=%d\n,
(unsigned long)vma-vm_start,
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index de81370..11350c2 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -87,6 +87,8 @@ struct soc_camera_host_ops {
int (*set_ctrl)(struct soc_camera_device *, struct v4l2_control *);
int (*get_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
int (*set_parm)(struct soc_camera_device *, struct v4l2_streamparm *);
+ int (*mmap)(struct videobuf_queue *, struct soc_camera_device *,
+ struct vm_area_struct *);
unsigned int (*poll)(struct file *, poll_table *);
const struct v4l2_queryctrl *controls;
int num_controls;
--
1.7.1
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
Re: [PATCH] v4l: soc-camera: Store negotiated buffer settings
On Mon, 7 Mar 2011, Sergio Aguirre wrote:
This fixes the problem in which a host driver
sets a personalized sizeimage or bytesperline field,
and gets ignored when doing G_FMT.
Can you tell what that personalised value is? Is it not covered by
soc_mbus_bytes_per_line()? Maybe something like a JPEG format?
Thanks
Guennadi
Signed-off-by: Sergio Aguirre saagui...@ti.com
---
drivers/media/video/soc_camera.c |9 -
include/media/soc_camera.h |2 ++
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/soc_camera.c
b/drivers/media/video/soc_camera.c
index a66811b..59dc71d 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -363,6 +363,8 @@ static int soc_camera_set_fmt(struct soc_camera_device
*icd,
icd-user_width = pix-width;
icd-user_height= pix-height;
icd-colorspace = pix-colorspace;
+ icd-bytesperline = pix-bytesperline;
+ icd-sizeimage = pix-sizeimage;
icd-vb_vidq.field =
icd-field = pix-field;
@@ -608,12 +610,9 @@ static int soc_camera_g_fmt_vid_cap(struct file *file,
void *priv,
pix-height = icd-user_height;
pix-field = icd-vb_vidq.field;
pix-pixelformat= icd-current_fmt-host_fmt-fourcc;
- pix-bytesperline = soc_mbus_bytes_per_line(pix-width,
- icd-current_fmt-host_fmt);
+ pix-bytesperline = icd-bytesperline;
pix-colorspace = icd-colorspace;
- if (pix-bytesperline 0)
- return pix-bytesperline;
- pix-sizeimage = pix-height * pix-bytesperline;
+ pix-sizeimage = icd-sizeimage;
dev_dbg(icd-dev, current_fmt-fourcc: 0x%08x\n,
icd-current_fmt-host_fmt-fourcc);
return 0;
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 9386db8..de81370 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -30,6 +30,8 @@ struct soc_camera_device {
s32 user_width;
s32 user_height;
enum v4l2_colorspace colorspace;
+ __u32 bytesperline; /* for padding, zero if unused */
+ __u32 sizeimage;
unsigned char iface;/* Host number */
unsigned char devnum; /* Device number per host */
struct soc_camera_sense *sense; /* See comment in struct definition */
--
1.7.1
---
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
RE: [PATCH/RFC 0/7] Samsung IOMMU videobuf2 allocator and s5p-fimc update
Hello, There are comments for your System MMU driver below. It's good that System MMU has functionality of mapping but System MMU have to use other mapping of virtual memory allocator. And would be better to change sysmmu_list to use array of defined in s5p_sysmmu_ip enumeration, so that can get enhancement of memory space usage, speed, and readability of codes. TLB replacement policy does not need to use LRU. Of course, current System MMU also needs it. I think, the round robin is enough, because to access memory has no temporal locality and to make LRU need to access to System MMU register one more. The reset value is round robin. In the setting of SHARED page table in s5p_sysmmu_control_locked, get the page table base address of ARM core from cp15 register now. But current-mm- pgd is better for more compatibility. When it make page table with PRIVATE page table methods, the size of the structure to manage the second page table is quite big. It is much better rather that to make slab with cache size of 1KB. Besides, the page mapping implementation is not safe in your System MMU driver. Because only first one confirms primary page table entry, when it assigns four second page tables consecutively at a time. The System MMU driver cannot apply runtime pm by oneself with calling pm_runtime_put_sync(). The reason is because a device with System MMU can on/off power. I think just clock gating is enough. However, I can't find clock enable/disable in your driver. By PRIVATE page table method, each system MMU comes to have a page table only for oneself. In this case, the problem is that each MFC System MMU L and R having another page table. In your System MMU driver, the page size is always 4KB crucially. This says TLB thrashing and produces a result to lose a TLB hit rate. It is a big problem with the device such as rotator which does not do sequential access especially. And the IRQ handler just outputs only a message. It should be implemented in call back function to be able to handle from each device driver. When it sets System MMU in SHARED page table, kernel virtual memory is broken by a method such as s5p_sysmmu_map_area() :( Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. Marek Szyprowski wrote: Hello, This patch series introduces new type of videbuf2 memory allocator - vb2-s5p-iommu. This allocator can be used only on Samsung SoCs that have IOMMU module. Currently only Samsung EXYNOS4 (former S5PV310) platform has SYSMMU modules. The allocator is then used by s5p-fimc driver. To make it possible some additional changes are required. Mainly platform support for s5p-fimc for EXYNOS4 machines need to be defined. The proposed solution has been tested on Universal C210 board (Samsung S5PC210/EXYNOS4 based). We decided to use driver private address space mode of the iommu driver. This way each vb2-s5p-iommu client gets it's own address space for memory buffers. This reduces kernel virtual memory fragmentation as well as solves some non-trivial page table updates issues. The drawback is the fact that the interface for s5p-sysmmu has been changed. This IOMMU allocator has no dependences on other subsystems besides Samsung platfrom core. We also ported s5p-mfc and s5p-tv drivers to this allocator, they will be posted in separate patch series. This will enable to get them working on EXYNOS4 (S5PV310) platform. Support for S5PV210/S5PC110 platform still depends on CMA allocator that needs more discussion on memory management mailing list and development. The patches with updated s5p-mfc and s5p-tv drivers will follow. To get FIMC module working on EXYNOS4/UniversalC210 board we also added support for power domains and power gating. This patch series contains a collection of patches for various platform subsystems. Here is a detailed list: [PATCH 1/7] ARM: S5PV310: Add platform definitions for FIMC - adds basic platform resources for FIMC modules (for s5p-fimc driver) [PATCH 2/7] ARM: S5PV310: power domains: fixes and code cleanup - adds support for block gating in Samsung power domain driver and performs some cleanup [PATCH 3/7] ARM: Samsung: update/rewrite Samsung SYSMMU (IOMMU) driver - a complete rewrite of sysmmu driver for Samsung platform: - the new version introduces device private page tables (address space) mode - simplified the resource management (no more horrible single platform device with 32 resources is needed) - some other API chages required by upcoming videobuf2 allocator [PATCH 4/7] v4l: videobuf2: add Samsung SYSMMU (IOMMU) based allocator - introduces new memory allocator for videobuf2, it uses s5p-sysmmu iommu driver, memory for video buffers is acuired by alloc_page() kernel function [PATCH 5/7] s5p-fimc: add pm_runtime support - adds support for pm_runtime in s5p-fimc driver [PATCH 6/7] s5p-fimc: Add
RE: [PATCH/RFC 0/5] [media] s5p-tvout: Add S5P TVOUT driver
Hans Verkuil wrote: Hi! Hi :) Sorry for not replying earlier. To be honest, there is not much I can say yet. The main new part in this driver is the HDMI/CEC support. And that is one of the topics of the upcoming Warsaw brainstorm meeting (several of your Samsung colleagues will be attending). An RFC for CEC support has been posted last week and hopefully we (Cisco Systems Norway) can get a HDMI RFC posted as well in time for the meeting. The main difference of our approach to HDMI is that we integrate it in V4L2 rather than creating new device nodes. Once the media controller is in we also have per-subdevice nodes in /dev which we want to utilize for the HDMI and CEC APIs. Functionality-wise the CEC RFC is effectively identical to your implementation. Thanks for your comment. I'll have a look at the proposed CEC-API additions. Can you please give your comments on the fact that this driver uses the framebuffer layer for the Mixer's graphic layer. This has been done keeping in mind certain customer requirements like X Driver and dual display. Yeah, I'm interested in knowing if this approach is valid/requires modification or if there are any alternate approaches. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. On Friday, February 25, 2011 08:53:28 Abhilash Kesavan wrote: This patch-set adds support for TV-OUT interface in the EXYNOS4 series of SoCs. TVOUT includes the HDMI interface, analog TV interface, mixer and video processor. This is a full-featured driver providing the following: 1) HDMI Support 2) Analog Support 3) Mixer Support 4) Video Processor Support 5) Hotplug Detect Support 6) HDCP Support 7) CEC Support 8) I2S/SPDIF Support The driver is under development and needs major modifications, as mentioned later in the TODO section, to conform to open source standards. Please have a look at the driver design and offer any suggestions/comments. I) HARDWARE Video processor is responsible for video scaling, de-interlacing, and video post processing of TVOUT data path. It reads reconstructed YCbCr video sequences from DRAM, processes the sequence, and sends it to mixer on-the-fly. Input to VP is NV12 and NV21 (Linear and tiled) format while the output to the mixer is YUV444. Mixer overlaps or blends input data such as graphic, video, background and sends the resulting data to the HDMI or analog TV interface. Along with the YUV444 in- put from VP interface, the mixer can receive two RGB inputs. It allows for layer blending, alpha blending, chroma key, scaling etc. HDMI interface supports 1.3 Tx subsystem V1.0 comprising an HDMI Tx core with I2S input interface, CEC block, and HDCP key block. It receives YUV444 or RGB888 data from the mixer and converts it into HDMI packets. Supports a variety of video formats varying from 480p to 1080p. Analog TV interface supports ITU-R BT 470 and EIA-770 compliant analog TV signals with 1 channel 10bit DAC. Supports PAL-m@60Hz, PAL-60@60Hz, NTSC@60Hz, NTSC-443@60Hz, PAL@50Hz, PAL-n@50Hz and (M)NTSC@60Hz formats for composite output. II) S/W DESIGN = == --- VFS --- KERNEL | | V V -- -- V4L2 STACK FB STACKLinux Driver Model -- -- | || =+===++= = == | || | | +-| | | | | V V V | +---+ ---+ | | | | | | | - --- | | | Video Ctrl -- Graphics Ctrl -- TVOUT I/F| | | - --- V | | | | ||__ - -- | | | | | | HPD Driver | | V V
Re: [PATCH/RFC 0/5] [media] s5p-tvout: Add S5P TVOUT driver
On Tuesday, March 08, 2011 07:32:39 Kukjin Kim wrote: Hans Verkuil wrote: Hi! Hi :) Sorry for not replying earlier. To be honest, there is not much I can say yet. The main new part in this driver is the HDMI/CEC support. And that is one of the topics of the upcoming Warsaw brainstorm meeting (several of your Samsung colleagues will be attending). An RFC for CEC support has been posted last week and hopefully we (Cisco Systems Norway) can get a HDMI RFC posted as well in time for the meeting. The main difference of our approach to HDMI is that we integrate it in V4L2 rather than creating new device nodes. Once the media controller is in we also have per-subdevice nodes in /dev which we want to utilize for the HDMI and CEC APIs. Functionality-wise the CEC RFC is effectively identical to your implementation. Thanks for your comment. I'll have a look at the proposed CEC-API additions. Can you please give your comments on the fact that this driver uses the framebuffer layer for the Mixer's graphic layer. This has been done keeping in mind certain customer requirements like X Driver and dual display. Yeah, I'm interested in knowing if this approach is valid/requires modification or if there are any alternate approaches. This approach is perfectly valid. In general graphics planes are implemented as a framebuffer since the framebuffer API makes much more sense for that than the V4L2 API. Regards, Hans Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. On Friday, February 25, 2011 08:53:28 Abhilash Kesavan wrote: This patch-set adds support for TV-OUT interface in the EXYNOS4 series of SoCs. TVOUT includes the HDMI interface, analog TV interface, mixer and video processor. This is a full-featured driver providing the following: 1) HDMI Support 2) Analog Support 3) Mixer Support 4) Video Processor Support 5) Hotplug Detect Support 6) HDCP Support 7) CEC Support 8) I2S/SPDIF Support The driver is under development and needs major modifications, as mentioned later in the TODO section, to conform to open source standards. Please have a look at the driver design and offer any suggestions/comments. I) HARDWARE Video processor is responsible for video scaling, de-interlacing, and video post processing of TVOUT data path. It reads reconstructed YCbCr video sequences from DRAM, processes the sequence, and sends it to mixer on-the-fly. Input to VP is NV12 and NV21 (Linear and tiled) format while the output to the mixer is YUV444. Mixer overlaps or blends input data such as graphic, video, background and sends the resulting data to the HDMI or analog TV interface. Along with the YUV444 in- put from VP interface, the mixer can receive two RGB inputs. It allows for layer blending, alpha blending, chroma key, scaling etc. HDMI interface supports 1.3 Tx subsystem V1.0 comprising an HDMI Tx core with I2S input interface, CEC block, and HDCP key block. It receives YUV444 or RGB888 data from the mixer and converts it into HDMI packets. Supports a variety of video formats varying from 480p to 1080p. Analog TV interface supports ITU-R BT 470 and EIA-770 compliant analog TV signals with 1 channel 10bit DAC. Supports PAL-m@60Hz, PAL-60@60Hz, NTSC@60Hz, NTSC-443@60Hz, PAL@50Hz, PAL-n@50Hz and (M)NTSC@60Hz formats for composite output. II) S/W DESIGN = == --- VFS --- KERNEL | | V V -- -- V4L2 STACK FB STACKLinux Driver Model -- -- | || =+===++= = == | || | | +-| | | | | V V V | +---+ ---+ | | | | | | |
Re: Compiling v4l fatal error: linux/ti_wilink_st.h: No such file or directory
On Mon, 7 Mar 2011 17:22:39 -0600 Scott igetmyemailh...@gmail.com wrote: Same problem. I purged both linux-headers-2.6.35-27-generic, linux-source-2.6.35, then reinstalled them, and did an apt-get update/upgrade. I then deleted media_build and ran... linux-headers should be enough, no need for linux-source, and you need never both IMHO. git clone git://linuxtv.org/media_build.git cd media_build ./build.sh Compile breaks vi vrl/.config changed CONFIG_DVB_FIREDTV=m to =n should not be necessary anymore, at least its not needed here. ./build.sh You might want to try my dkms package - not sure if it works on maverick (its build on/for lucid) - but in theory it should (except if the number of modules differs for different kernel). If not you get atleast the latest source which compiles fine here. https://launchpad.net/~yavdr/+archive/testing-vdr/+packages?field.name_filter=v4l-dvb-dkmsfield.status_filter=publishedfield.series_filter= Just uploaded new version with media_build and media_tree as of now. Let me know if it works. Steffen -- 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
