[PATCH] V4L2: add documentation for V4L2 clock helpers and asynchronous probing
Add documentation for the V4L2 clock and V4L2 asynchronous probing APIs to v4l2-framework.txt. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Hopefully we can commit the actual patches now, while we refine the documentation. Documentation/video4linux/v4l2-framework.txt | 62 +- 1 files changed, 60 insertions(+), 2 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index a300b28..159a83a 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -326,8 +326,27 @@ that width, height and the media bus pixel code are equal on both source and sink of the link. Subdev drivers are also free to use this function to perform the checks mentioned above in addition to their own checks. -A device (bridge) driver needs to register the v4l2_subdev with the -v4l2_device: +There are currently two ways to register subdevices with the V4L2 core. The +first (traditional) possibility is to have subdevices registered by bridge +drivers. This can be done, when the bridge driver has the complete information +about subdevices, connected to it and knows exactly when to register them. This +is typically the case for internal subdevices, like video data processing units +within SoCs or complex pluggable boards, camera sensors in USB cameras or +connected to SoCs, which pass information about them to bridge drivers, usually +in their platform data. + +There are however also situations, where subdevices have to be registered +asynchronously to bridge devices. An example of such a configuration is Device +Tree based systems, on which information about subdevices is made available to +the system indpendently from the bridge devices, e.g. when subdevices are +defined in DT as I2C device nodes. The API, used in this second case is +described further below. + +Using one or the other registration method only affects the probing process, the +run-time bridge-subdevice interaction is in both cases the same. + +In the synchronous case a device (bridge) driver needs to register the +v4l2_subdev with the v4l2_device: int err = v4l2_device_register_subdev(v4l2_dev, sd); @@ -394,6 +413,25 @@ controlled through GPIO pins. This distinction is only relevant when setting up the device, but once the subdev is registered it is completely transparent. +In the asynchronous case subdevices register themselves using the +v4l2_async_register_subdev() function. Unregistration is performed, using the +v4l2_async_unregister_subdev() call. Subdevices registered this way are stored +on a global list of subdevices, ready to be picked up by bridge drivers. + +Bridge drivers in turn have to register a notifier object with an array of +subdevice descriptors, that the bridge device needs for its operation. This is +performed using the v4l2_async_notifier_register() call. To unregister the +notifier the driver has to call v4l2_async_notifier_unregister(). The former of +the two functions takes two arguments: a pointer to struct v4l2_device and a +pointer to struct v4l2_async_notifier. The latter contains a pointer to an array +of pointers to subdevice descriptors of type struct v4l2_async_subdev type. The +V4L2 core will then use these descriptors to match asynchronously registered +subdevices to them. If a match is detected the .bound() notifier callback is +called. After all subdevices have been located the .complete() callback is +called. When a subdevice is removed from the system the .unbind() method is +called. All three callbacks are optional. + + V4L2 sub-device userspace API - @@ -1061,3 +1099,23 @@ available event type is 'class base + 1'. An example on how the V4L2 events may be used can be found in the OMAP 3 ISP driver (drivers/media/platform/omap3isp). + + +V4L2 clocks +--- + +Many subdevices, like camera sensors, TV decoders and encoders, need a clock +signal to be supplied by the system. Often this clock is supplied by the +respective bridge device. The Linux kernel provides a Common Clock Framework for +this purpose, however, it is not (yet) available on all architectures. Besides, +the nature of the multi-functional (clock, data + synchronisation, I2C control) +connection of subdevices to the system might impose special requirements on the +clock API usage. For these reasons a V4L2 clock helper API has been developed +and is provided to bridge and subdevice drivers. + +The API consists of two parts: two functions to register and unregister a V4L2 +clock source: v4l2_clk_register() and v4l2_clk_unregister() and calls to control +a clock object, similar to respective generic clock API calls: v4l2_clk_get(), +v4l2_clk_put(), v4l2_clk_enable(), v4l2_clk_disable(), v4l2_clk_get_rate(), and +v4l2_clk_set_rate(). Clock suppliers have to provide clock operations, that will +be called when clock users invoke respective API
Re: [PATCH 14/15] ARM: shmobile: Remove AP4EVB board support
On Mon, 17 Jun 2013, Magnus Damm wrote: [snip] So Guennadi, if you want to keep this board then you have to step up and fix things. If not then there is no point in keeping it. Ok, after a private discussion we agreed to remove the board, which will also make the drivers for the Renesas sh-/r-mobile CSI2 interface and for the Sony IMX074 sensor untestable and susceptible to removal. Also multi-subdevice support in soc-camera now will lose its only use and can become broken. I will also drop CSI2 and AP4EVB patches from my V4L2 clock / async probing series. 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 5/6] [media] V4L: Add VP8 encoder controls
Hi Sylwester,
Also for number of ref frames, the standard allows only the options 1,
2 and 3 which
cannot be extended more. So is it correct to use INTEGER_MENU control here
and
let the driver define the values?
If this is standard then the core should define available menu items. But
it seems more appropriate for me to use INTEGER_MENU. I'd like to hear other
opinions though.
Here even though 1,2 and 3 are standard, the interpretation is
1 - 1 reference frame (previous frame)
2 - previous frame + golden frame
3 - previous frame + golden frame + altref frame.
OK, then perhaps for this parameter a standard menu control would be better.
However, why there are only 2 options in vpx_num_ref_frames[] arrays ?
You probably want to change the menu strings to reflect this more precisely,
but there might be not enough room for any creative names anyway. Maybe
something like:
static const char * const vpx_num_ref_frames[] = {
Previous Frame,
Previous + Golden Frame,
Prev + Golden + Altref Frame,
NULL,
};
On a more detailed inspection, the standard says maximum of 3 reference
frames. So in case of 2, it can be any of the permutation combination
possible. So rather I will stick to integer menu items saying 1, 2 and 3 where
on setting value 2, the encoder can decide on which frames to refer based
on its implementation but keeping the searching limit to 2 frames only.
Regards
Arun
--
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 14/15] ARM: shmobile: Remove AP4EVB board support
On Mon, Jun 17, 2013 at 3:12 PM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Mon, 17 Jun 2013, Magnus Damm wrote: [snip] So Guennadi, if you want to keep this board then you have to step up and fix things. If not then there is no point in keeping it. Ok, after a private discussion we agreed to remove the board, which will also make the drivers for the Renesas sh-/r-mobile CSI2 interface and for the Sony IMX074 sensor untestable and susceptible to removal. Also multi-subdevice support in soc-camera now will lose its only use and can become broken. I will also drop CSI2 and AP4EVB patches from my V4L2 clock / async probing series. Thanks for writing this summary. It matches my understanding. It is unfortunate, but it seems to me that the camera sensor has to be tested on another platform. Regarding the CSI2 interface, as we discussed, this IP still exists in newer SoCs so because of that I recommend you to try to request newer hardware for future testing. About multi-subdevice and your ongoing work with V4L2 clock / async probing, please select a more recent hardware platform. Thanks, / magnus -- 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: Doing a v4l-utils-1.0.0 release
Hi, On 06/15/2013 12:33 PM, Guy Martin wrote: On Fri, 14 Jun 2013 10:34:04 -0300 Mauro Carvalho Chehab mche...@redhat.com wrote: Em Fri, 14 Jun 2013 09:15:02 +0200 Hans de Goede hdego...@redhat.com escreveu: Hi All, IIRC the 0.9.x series were meant as development releases leading up to a new stable 1.0.0 release. Lately there have been no maintenance 0.8.x releases and a lot of interesting development going on in the 0.9.x, while at the same time there have been no issues reported against 0.9.x (iow it seems stable). So how about taking current master and releasing that as a 1.0.0 release ? Fine for me. There are 5 patches floating at patchwork to improve the DVB-S support with different types of DiSEqC, but applying them would break library support for tvd. So, they won't be applied as-is, and Guy needs to take some other approach. As he is also planning to add support there for rotors, it looks ok to postpone such changes to a latter version. Can we wait a little bit more like a week max ? Sure, I was just trying to see what people think about doing a 1.0.0 release. I see no reason to rush it. Regards, Hans -- 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 PATCH 2/2] davinci_vpfe: Clean up media entity after unregistering subdev
Hi Sylwester, On Mon, Jun 17, 2013 at 2:46 AM, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote: Hi, On 06/12/2013 06:44 AM, Prabhakar Lad wrote: On Tue, Jun 11, 2013 at 4:20 PM, Sakari Ailussakari.ai...@iki.fi wrote: media_entity_cleanup() frees the links array which will be accessed by media_entity_remove_links() called by v4l2_device_unregister_subdev(). Signed-off-by: Sakari Ailussakari.ai...@iki.fi Acked-by: Lad, Prabhakarprabhakar.cse...@gmail.com I have added these two patches to my tree for 3.11 (in branch for-v3.11-2). Please let me know if you would like it to be handled differently. I am fine with it. Regards, --Prabhakar Lad -- 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 5/6] [media] V4L: Add VP8 encoder controls
Hi Arun,
On 06/17/2013 06:25 AM, Arun Kumar K wrote:
On Sat, Jun 15, 2013 at 1:01 AM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
On 06/14/2013 03:21 PM, Arun Kumar K wrote:
On Fri, Jun 14, 2013 at 3:23 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
On 06/14/2013 11:26 AM, Arun Kumar K wrote:
+ static const char * const vpx_num_partitions[] = {
+ 1 partition,
+ 2 partitions,
+ 4 partitions,
+ 8 partitions,
+ NULL,
+ };
+ static const char * const vpx_num_ref_frames[] = {
+ 1 reference frame,
+ 2 reference frame,
+ NULL,
+ };
Have you considered using V4L2_CTRL_TYPE_INTEGER_MENU control type for
this ?
One example is V4L2_CID_ISO_SENSITIVITY control.
If I understand correctly, V4L2_CTRL_TYPE_INTEGER_MENU is used for
controls where
the driver / IP can support different values depending on its
capabilities.
No, not really, it just happens there is no INTEGER_MENU control with
standard
values yet. I think there are some (minor) changes needed in the v4l2-ctrls
code to support INTEGER_MENU control with standard menu items.
But here VP8 standard supports only 4 options for no. of partitions
that is 1, 2, 4 and 8.
I think such a standard menu list should be defined in v4l2-ctrls.c then.
One more concern here is these integer values 1, 2, 4 and 8 may not hold
much significance while setting to the registers. Some IPs may need these
values to be set as 0, 1, 2 and 3. So unlike other settings like ISO, the
values that are given by the user may not be directly applicable to the
register setting.
The INTEGER_MENU control is not much different than MENU control from
driver POV. s_ctrl() op is called with similarly with the an index to
the menu option. In addition to standard menu applications can query
real value corresponding to a menu option, rather than a character
string only.
With each new control a nw strings are added, that cumulate in the
videodev module and make it bigger. Actually __s64 is not much smaller
than 1 partition in your case. But it's a bit smaller. :)
Yes that makes sense. But there will be a few extra functions that
would be needed in the v4l2-ctrls.c like may be
v4l2_ctrl_new_int_menu_fixed() which doesnt take qmenu arg from driver.
Will try to make this change.
I wouldn't be adding another helper like this, IMHO v4l2_ctrl_new_menu()
could well handle such entirely standard control type. I looked into that
over the weekend, let me send you my work-in-progress patch. Maybe you find
it useful.
That said I'm not either a codec expert or the v4l2 controls maintainer.
I think last words belongs to Hans. I just express my suggestions of
what I though we be more optimal (but not necessarily less work!). :)
Also for number of ref frames, the standard allows only the options 1,
2 and 3 which
cannot be extended more. So is it correct to use INTEGER_MENU control
here and
let the driver define the values?
If this is standard then the core should define available menu items. But
it seems more appropriate for me to use INTEGER_MENU. I'd like to hear
other
opinions though.
Here even though 1,2 and 3 are standard, the interpretation is
1 - 1 reference frame (previous frame)
2 - previous frame + golden frame
3 - previous frame + golden frame + altref frame.
OK, then perhaps for this parameter a standard menu control would be better.
However, why there are only 2 options in vpx_num_ref_frames[] arrays ?
Thats because MFCv7 doesnt support the 3rd option yet. But still I would
add this in the control to make it generic.
I see. Yes, I think it makes more sense to specify the control fully,
according to the standard.
You probably want to change the menu strings to reflect this more precisely,
but there might be not enough room for any creative names anyway. Maybe
something like:
static const char * const vpx_num_ref_frames[] = {
Previous Frame,
Previous + Golden Frame,
Prev + Golden + Altref Frame,
NULL,
};
Anyway raw numbers might be better for the control and details could be
described in the documentation.
Ok will do like this.
Just one more note, I think I might have confused you with my comment
on the enum v4l2_vp8_num_partitions. Presumably we just need to define
contiguous enumeration for all options of V4L2_CID_VPX_NUM_PARTITIONS
control. And the actual values would be defined only on the integer
menu values array, e.g.
copnst s64 qmenu_int_vpx_num_partitions[] [
1, 2, 4, 8
};
and
#define V4L2_CID_VPX_NUM_PARTITIONS (V4L2_CID_MPEG_BASE + ?)
enum v4l2_vp8_num_partitions {
V4L2_VPX_1_PARTITION= 0,
V4L2_VPX_2_PARTITIONS = 1,
V4L2_VPX_4_PARTITIONS = 2,
V4L2_VPX_8_PARTITIONS = 3,
};
or
#define V4L2_CID_VPX_NUM_PARTITIONS (V4L2_CID_MPEG_BASE + ?)
#define V4L2_VPX_1_PARTITION0
#define
[PATCH] V4L: Add support for integer menu controls with standard menu items
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
---
Hi Arun,
Perhaps you find this patch useful for your VP8 controls works.
It's not complete and I didn't test it, except ensuring it compiles.
Thanks,
Sylwester
---
Documentation/video4linux/v4l2-controls.txt | 21 ++--
drivers/media/v4l2-core/v4l2-ctrls.c| 28 ---
2 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/Documentation/video4linux/v4l2-controls.txt
b/Documentation/video4linux/v4l2-controls.txt
index 676f873..fd11d0b 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -124,26 +124,27 @@ You add non-menu controls by calling v4l2_ctrl_new_std:
const struct v4l2_ctrl_ops *ops,
u32 id, s32 min, s32 max, u32 step, s32 def);
-Menu controls are added by calling v4l2_ctrl_new_std_menu:
+Menu and integer menu controls are added by calling v4l2_ctrl_new_std_menu:
struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, s32 max, s32 skip_mask, s32 def);
-Or alternatively for integer menu controls, by calling v4l2_ctrl_new_int_menu:
+Menu controls with a driver specific menu are added by calling
+v4l2_ctrl_new_std_menu_items:
+
+ struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items(
+ struct v4l2_ctrl_handler *hdl,
+ const struct v4l2_ctrl_ops *ops, u32 id, s32 max,
+ s32 skip_mask, s32 def, const char * const *qmenu);
+
+Integer menu controls with driver specific menu can be added by calling
+v4l2_ctrl_new_int_menu:
struct v4l2_ctrl *v4l2_ctrl_new_int_menu(struct v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, s32 max, s32 def, const s64 *qmenu_int);
-Standard menu controls with a driver specific menu are added by calling
-v4l2_ctrl_new_std_menu_items:
-
- struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items(
- struct v4l2_ctrl_handler *hdl,
- const struct v4l2_ctrl_ops *ops, u32 id, s32 max,
- s32 skip_mask, s32 def, const char * const *qmenu);
-
These functions are typically called right after the v4l2_ctrl_handler_init:
static const s64 exp_bias_qmenu[] = {
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index ebb8e48..c230b96 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -552,6 +552,20 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
}
EXPORT_SYMBOL(v4l2_ctrl_get_menu);
+/*
+ * Returns NULL or an s64 type array containing the menu for given
+ * control ID. The total number of the menu items is returned in @len.
+ */
+const s64 const *v4l2_ctrl_get_int_menu(u32 id, u32 *len)
+{
+
+ switch (id) {
+ default:
+ return NULL;
+ }
+}
+EXPORT_SYMBOL(v4l2_ctrl_get_int_menu);
+
/* Return the control name. */
const char *v4l2_ctrl_get_name(u32 id)
{
@@ -1712,20 +1726,28 @@ struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct
v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, s32 max, s32 mask, s32 def)
{
- const char * const *qmenu = v4l2_ctrl_get_menu(id);
+ const char * const *qmenu = NULL;
+ const s64 *qmenu_int = NULL;
const char *name;
enum v4l2_ctrl_type type;
+ unsigned int qmenu_int_len;
s32 min;
s32 step;
u32 flags;
v4l2_ctrl_fill(id, name, type, min, max, step, def, flags);
- if (type != V4L2_CTRL_TYPE_MENU) {
+
+ if (type == V4L2_CTRL_TYPE_MENU)
+ qmenu = v4l2_ctrl_get_menu(id);
+ else if (type == V4L2_CTRL_TYPE_INTEGER_MENU)
+ qmenu_int = v4l2_ctrl_get_int_menu(id, qmenu_int_len);
+
+ if ((!qmenu !qmenu_int) || (qmenu_int max qmenu_int_len)) {
handler_set_err(hdl, -EINVAL);
return NULL;
}
return v4l2_ctrl_new(hdl, ops, id, name, type,
-0, max, mask, def, flags, qmenu, NULL, NULL);
+0, max, mask, def, flags, qmenu, qmenu_int, NULL);
}
EXPORT_SYMBOL(v4l2_ctrl_new_std_menu);
--
1.7.9.5
--
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: DVB Scan file for Cherbourg (FR)
On 16-06-13 10:15, Duval Mickael wrote: It is true that only scans once! It can therefore be quite limited at this fr_All file and remove fr_Cherbourg and fr_Bordeaux. Allright, per your request I will merge Cherbourg and Bordeaux into fr-All (if there are missing frequencies) and I'll use your fr-All 2013/6/15 Oliver Schinagl oliver+l...@schinagl.nl: On 15-06-13 12:08, Duval Mickael wrote: Indeed frequencies fr_Cherbourg and fr_Bordeaux are contained in fr_All. But I was thinking of doing a fr_All file and a specific file for all city as uk. With a file with only the useful frequency, detection will be much faster right? Yes, if you only have to scan 5 frequencies instead of 20 of course it will be faster. But how often do you tune and how many frequencies are there to consider? If you have look at fr-All, that looks pretty small to me. Having 20 files covering those same frequencies will just add clutter to the db if you ask me. So I would keep with one fr-All if it works 'for everybody'. 2013/6/15 Oliver Schinagl oliver+l...@schinagl.nl: On 06/15/13 11:30, Duval Mickael wrote: Ok I have cloned your repo with Git, and I've make two patch files. Can you explain to me why there are fr-All and fr-Cherbourg? (and fr-Bordeaux)? Does fr-All not work for those two places? If fr-All does everything, it's ok to merge the other two in. nl-All is all transponders for the country as a lot of frequencies are shared. We could have 10 or so nl-area but they'd be all really small. So is fr-All everything for the entire country, but has Cherbourg and Bordeaux extra, very different freq's? Merged in c8050e8105b1b4b5364f57d8b3e658c80fb04a53 for now Thanks, oliver 2013/6/15 Duval Mickael duvalmick...@gmail.com: In zip there is a little modification for city of cherbourg (add two new muxes) and a fr_ALL for France all channels DVB-T initial scan. What's the problem exactly with my files? Thanks Duval Mickael 2013/6/14 Oliver Schinagl oliver+l...@schinagl.nl: On 06/13/13 19:10, Duval Mickael wrote: Hello, Hi, I send this email to you for a DVB-T scan file for the city of Cherbourg FRANCE, modified with the last channels. I also enclose a package file that includes all channels available for DVB-T in France. I've applied your patch (after manually working it over) last time. What is in this zip? Please send a patch file what still needs to be adjusted. Cherbourg is in the repo now, isn't it? Sorry for my poor English ;-) Thank you. -- 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 5/6] [media] V4L: Add VP8 encoder controls
Hi Sylwester,
On Mon, Jun 17, 2013 at 2:34 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
On 06/17/2013 06:25 AM, Arun Kumar K wrote:
On Sat, Jun 15, 2013 at 1:01 AM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
On 06/14/2013 03:21 PM, Arun Kumar K wrote:
On Fri, Jun 14, 2013 at 3:23 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
On 06/14/2013 11:26 AM, Arun Kumar K wrote:
+ static const char * const vpx_num_partitions[] = {
+ 1 partition,
+ 2 partitions,
+ 4 partitions,
+ 8 partitions,
+ NULL,
+ };
+ static const char * const vpx_num_ref_frames[] = {
+ 1 reference frame,
+ 2 reference frame,
+ NULL,
+ };
Have you considered using V4L2_CTRL_TYPE_INTEGER_MENU control type for
this ?
One example is V4L2_CID_ISO_SENSITIVITY control.
If I understand correctly, V4L2_CTRL_TYPE_INTEGER_MENU is used for
controls where
the driver / IP can support different values depending on its
capabilities.
No, not really, it just happens there is no INTEGER_MENU control with
standard
values yet. I think there are some (minor) changes needed in the
v4l2-ctrls
code to support INTEGER_MENU control with standard menu items.
But here VP8 standard supports only 4 options for no. of partitions
that is 1, 2, 4 and 8.
I think such a standard menu list should be defined in v4l2-ctrls.c then.
One more concern here is these integer values 1, 2, 4 and 8 may not hold
much significance while setting to the registers. Some IPs may need these
values to be set as 0, 1, 2 and 3. So unlike other settings like ISO, the
values that are given by the user may not be directly applicable to the
register setting.
The INTEGER_MENU control is not much different than MENU control from
driver POV. s_ctrl() op is called with similarly with the an index to
the menu option. In addition to standard menu applications can query
real value corresponding to a menu option, rather than a character
string only.
With each new control a nw strings are added, that cumulate in the
videodev module and make it bigger. Actually __s64 is not much smaller
than 1 partition in your case. But it's a bit smaller. :)
Yes that makes sense. But there will be a few extra functions that
would be needed in the v4l2-ctrls.c like may be
v4l2_ctrl_new_int_menu_fixed() which doesnt take qmenu arg from driver.
Will try to make this change.
I wouldn't be adding another helper like this, IMHO v4l2_ctrl_new_menu()
could well handle such entirely standard control type. I looked into that
over the weekend, let me send you my work-in-progress patch. Maybe you find
it useful.
Ok that would be really helpful. Will check that patch.
That said I'm not either a codec expert or the v4l2 controls maintainer.
I think last words belongs to Hans. I just express my suggestions of
what I though we be more optimal (but not necessarily less work!). :)
Also for number of ref frames, the standard allows only the options 1,
2 and 3 which
cannot be extended more. So is it correct to use INTEGER_MENU control
here and
let the driver define the values?
If this is standard then the core should define available menu items. But
it seems more appropriate for me to use INTEGER_MENU. I'd like to hear
other
opinions though.
Here even though 1,2 and 3 are standard, the interpretation is
1 - 1 reference frame (previous frame)
2 - previous frame + golden frame
3 - previous frame + golden frame + altref frame.
OK, then perhaps for this parameter a standard menu control would be better.
However, why there are only 2 options in vpx_num_ref_frames[] arrays ?
Thats because MFCv7 doesnt support the 3rd option yet. But still I would
add this in the control to make it generic.
I see. Yes, I think it makes more sense to specify the control fully,
according to the standard.
You probably want to change the menu strings to reflect this more precisely,
but there might be not enough room for any creative names anyway. Maybe
something like:
static const char * const vpx_num_ref_frames[] = {
Previous Frame,
Previous + Golden Frame,
Prev + Golden + Altref Frame,
NULL,
};
Anyway raw numbers might be better for the control and details could be
described in the documentation.
Ok will do like this.
Just one more note, I think I might have confused you with my comment
on the enum v4l2_vp8_num_partitions. Presumably we just need to define
contiguous enumeration for all options of V4L2_CID_VPX_NUM_PARTITIONS
control. And the actual values would be defined only on the integer
menu values array, e.g.
copnst s64 qmenu_int_vpx_num_partitions[] [
1, 2, 4, 8
};
and
#define V4L2_CID_VPX_NUM_PARTITIONS (V4L2_CID_MPEG_BASE + ?)
enum v4l2_vp8_num_partitions {
V4L2_VPX_1_PARTITION= 0,
V4L2_VPX_2_PARTITIONS = 1,
[PATCH v3] [media] usbtv: Add driver for Fushicai USBTV007 video frame grabber
Reverse-engineered driver for cheapo video digitizer, made from observations of Windows XP driver. The protocol is not yet completely understood, so far we don't provide any controls, only support a single format out of three and don't support the audio device. Signed-off-by: Lubomir Rintel lkund...@v3.sk Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: linux-ker...@vger.kernel.org Cc: linux-media@vger.kernel.org --- Changes for v2: - Fix a typo in comment - Make prototype register settings static const - Solve parity calculation weirdness - Attempt to fix interlacing - Add timestamp to frames - [v4l2-compliance] Set pix format priv to 0 - Drop usbtv_*_fmt_vid_cap code duplication - [v4l2-compliance] Add vidioc_create_bufs - [v4l2-compliance] Use file handle priorities - Drop Driver from initial dev_info Changes for v3: - Utilize ARRAY_SIZE - Drop queryctrl ioctl - Reduce default number of buffers to two - Remove unnecessary locking - video_set_drvdata() before video_register_device() diff --git a/drivers/media/usb/Kconfig b/drivers/media/usb/Kconfig index 0a7d520..8e10267 100644 --- a/drivers/media/usb/Kconfig +++ b/drivers/media/usb/Kconfig @@ -17,6 +17,7 @@ source drivers/media/usb/zr364xx/Kconfig source drivers/media/usb/stkwebcam/Kconfig source drivers/media/usb/s2255/Kconfig source drivers/media/usb/sn9c102/Kconfig +source drivers/media/usb/usbtv/Kconfig endif if MEDIA_ANALOG_TV_SUPPORT diff --git a/drivers/media/usb/Makefile b/drivers/media/usb/Makefile index 7f51d7e..0935f47 100644 --- a/drivers/media/usb/Makefile +++ b/drivers/media/usb/Makefile @@ -20,3 +20,4 @@ obj-$(CONFIG_VIDEO_STK1160) += stk1160/ obj-$(CONFIG_VIDEO_CX231XX) += cx231xx/ obj-$(CONFIG_VIDEO_TM6000) += tm6000/ obj-$(CONFIG_VIDEO_EM28XX) += em28xx/ +obj-$(CONFIG_VIDEO_USBTV) += usbtv/ diff --git a/drivers/media/usb/usbtv/Kconfig b/drivers/media/usb/usbtv/Kconfig new file mode 100644 index 000..8864436 --- /dev/null +++ b/drivers/media/usb/usbtv/Kconfig @@ -0,0 +1,10 @@ +config VIDEO_USBTV +tristate USBTV007 video capture support +depends on VIDEO_DEV +select VIDEOBUF2_VMALLOC + +---help--- + This is a video4linux2 driver for USBTV007 based video capture devices. + + To compile this driver as a module, choose M here: the + module will be called usbtv diff --git a/drivers/media/usb/usbtv/Makefile b/drivers/media/usb/usbtv/Makefile new file mode 100644 index 000..28b872f --- /dev/null +++ b/drivers/media/usb/usbtv/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_VIDEO_USBTV) += usbtv.o diff --git a/drivers/media/usb/usbtv/usbtv.c b/drivers/media/usb/usbtv/usbtv.c new file mode 100644 index 000..d44fa63 --- /dev/null +++ b/drivers/media/usb/usbtv/usbtv.c @@ -0,0 +1,696 @@ +/* + * Fushicai USBTV007 Video Grabber Driver + * + * Product web site: + * http://www.fushicai.com/products_detail/productId=d05449ee-b690-42f9-a661-aa7353894bed.html + * + * Following LWN articles were very useful in construction of this driver: + * Video4Linux2 API series: http://lwn.net/Articles/203924/ + * videobuf2 API explanation: http://lwn.net/Articles/447435/ + * Thanks go to Jonathan Corbet for providing this quality documentation. + * He is awesome. + * + * Copyright (c) 2013 Lubomir Rintel + * All rights reserved. + * No physical hardware was harmed running Windows during the + * reverse-engineering activity + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions, and the following disclaimer, + *without modification. + * 2. The name of the author may not be used to endorse or promote products + *derived from this software without specific prior written permission. + * + * Alternatively, this software may be distributed under the terms of the + * GNU General Public License (GPL). + */ + +#include linux/init.h +#include linux/list.h +#include linux/module.h +#include linux/slab.h +#include linux/usb.h +#include linux/version.h +#include linux/videodev2.h + +#include media/v4l2-device.h +#include media/v4l2-ioctl.h +#include media/videobuf2-core.h +#include media/videobuf2-vmalloc.h + +/* Hardware. */ +#define USBTV_VIDEO_ENDP 0x81 +#define USBTV_BASE 0xc000 +#define USBTV_REQUEST_REG 12 + +/* Number of concurrent isochronous urbs submitted. + * Higher numbers was seen to overly saturate the USB bus. */ +#define USBTV_ISOC_TRANSFERS 16 +#define USBTV_ISOC_PACKETS 8 + +#define USBTV_WIDTH720 +#define USBTV_HEIGHT 480 + +#define USBTV_CHUNK_SIZE 256 +#define USBTV_CHUNK240 +#define USBTV_CHUNKS (USBTV_WIDTH * USBTV_HEIGHT \ + / 2 / USBTV_CHUNK) + +/* Chunk header. */ +#define
Re: [PATCH v3] [media] usbtv: Add driver for Fushicai USBTV007 video frame grabber
On Mon 17 June 2013 11:43:13 Lubomir Rintel wrote: Reverse-engineered driver for cheapo video digitizer, made from observations of Windows XP driver. The protocol is not yet completely understood, so far we don't provide any controls, only support a single format out of three and don't support the audio device. Looks great. I've got two remaining issues: replace strncpy with the safer strlcpy and a small problem in usbtv_queue_setup. After fixing that you can add my Acked-by: Hans Verkuil hans.verk...@cisco.com to the patch. Regards, Hans Signed-off-by: Lubomir Rintel lkund...@v3.sk Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: linux-ker...@vger.kernel.org Cc: linux-media@vger.kernel.org --- Changes for v2: - Fix a typo in comment - Make prototype register settings static const - Solve parity calculation weirdness - Attempt to fix interlacing - Add timestamp to frames - [v4l2-compliance] Set pix format priv to 0 - Drop usbtv_*_fmt_vid_cap code duplication - [v4l2-compliance] Add vidioc_create_bufs - [v4l2-compliance] Use file handle priorities - Drop Driver from initial dev_info Changes for v3: - Utilize ARRAY_SIZE - Drop queryctrl ioctl - Reduce default number of buffers to two - Remove unnecessary locking - video_set_drvdata() before video_register_device() diff --git a/drivers/media/usb/Kconfig b/drivers/media/usb/Kconfig index 0a7d520..8e10267 100644 --- a/drivers/media/usb/Kconfig +++ b/drivers/media/usb/Kconfig @@ -17,6 +17,7 @@ source drivers/media/usb/zr364xx/Kconfig source drivers/media/usb/stkwebcam/Kconfig source drivers/media/usb/s2255/Kconfig source drivers/media/usb/sn9c102/Kconfig +source drivers/media/usb/usbtv/Kconfig endif if MEDIA_ANALOG_TV_SUPPORT diff --git a/drivers/media/usb/Makefile b/drivers/media/usb/Makefile index 7f51d7e..0935f47 100644 --- a/drivers/media/usb/Makefile +++ b/drivers/media/usb/Makefile @@ -20,3 +20,4 @@ obj-$(CONFIG_VIDEO_STK1160) += stk1160/ obj-$(CONFIG_VIDEO_CX231XX) += cx231xx/ obj-$(CONFIG_VIDEO_TM6000) += tm6000/ obj-$(CONFIG_VIDEO_EM28XX) += em28xx/ +obj-$(CONFIG_VIDEO_USBTV) += usbtv/ diff --git a/drivers/media/usb/usbtv/Kconfig b/drivers/media/usb/usbtv/Kconfig new file mode 100644 index 000..8864436 --- /dev/null +++ b/drivers/media/usb/usbtv/Kconfig @@ -0,0 +1,10 @@ +config VIDEO_USBTV +tristate USBTV007 video capture support +depends on VIDEO_DEV +select VIDEOBUF2_VMALLOC + +---help--- + This is a video4linux2 driver for USBTV007 based video capture devices. + + To compile this driver as a module, choose M here: the + module will be called usbtv diff --git a/drivers/media/usb/usbtv/Makefile b/drivers/media/usb/usbtv/Makefile new file mode 100644 index 000..28b872f --- /dev/null +++ b/drivers/media/usb/usbtv/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_VIDEO_USBTV) += usbtv.o diff --git a/drivers/media/usb/usbtv/usbtv.c b/drivers/media/usb/usbtv/usbtv.c new file mode 100644 index 000..d44fa63 --- /dev/null +++ b/drivers/media/usb/usbtv/usbtv.c @@ -0,0 +1,696 @@ +/* + * Fushicai USBTV007 Video Grabber Driver + * + * Product web site: + * http://www.fushicai.com/products_detail/productId=d05449ee-b690-42f9-a661-aa7353894bed.html + * + * Following LWN articles were very useful in construction of this driver: + * Video4Linux2 API series: http://lwn.net/Articles/203924/ + * videobuf2 API explanation: http://lwn.net/Articles/447435/ + * Thanks go to Jonathan Corbet for providing this quality documentation. + * He is awesome. + * + * Copyright (c) 2013 Lubomir Rintel + * All rights reserved. + * No physical hardware was harmed running Windows during the + * reverse-engineering activity + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions, and the following disclaimer, + *without modification. + * 2. The name of the author may not be used to endorse or promote products + *derived from this software without specific prior written permission. + * + * Alternatively, this software may be distributed under the terms of the + * GNU General Public License (GPL). + */ + +#include linux/init.h +#include linux/list.h +#include linux/module.h +#include linux/slab.h +#include linux/usb.h +#include linux/version.h +#include linux/videodev2.h + +#include media/v4l2-device.h +#include media/v4l2-ioctl.h +#include media/videobuf2-core.h +#include media/videobuf2-vmalloc.h + +/* Hardware. */ +#define USBTV_VIDEO_ENDP 0x81 +#define USBTV_BASE 0xc000 +#define USBTV_REQUEST_REG12 + +/* Number of concurrent isochronous urbs submitted. + * Higher numbers
Re: [PATCH v11 00/21] V4L2 clock and asynchronous probing
On Fri 14 June 2013 21:08:10 Guennadi Liakhovetski wrote:
v11 of the V4L2 clock helper and asynchronous probing patch set.
Functionally identical to v10, only differences are a couple of comment
lines and one renamed struct field - as requested by respectable
reviewers :)
Only patches #15, 16 and 18 changed.
Thanks for posting the patch adding documentation! Much appreciated.
As a result I give my ack for this patch series:
Acked-by: Hans Verkuil hans.verk...@cisco.com
Regards,
Hans
Guennadi Liakhovetski (21):
soc-camera: move common code to soc_camera.c
soc-camera: add host clock callbacks to start and stop the master
clock
pxa-camera: move interface activation and deactivation to clock
callbacks
omap1-camera: move interface activation and deactivation to clock
callbacks
atmel-isi: move interface activation and deactivation to clock
callbacks
mx3-camera: move interface activation and deactivation to clock
callbacks
mx2-camera: move interface activation and deactivation to clock
callbacks
mx1-camera: move interface activation and deactivation to clock
callbacks
sh-mobile-ceu-camera: move interface activation and deactivation to
clock callbacks
soc-camera: make .clock_{start,stop} compulsory, .add / .remove
optional
soc-camera: don't attach the client to the host during probing
sh-mobile-ceu-camera: add primitive OF support
sh-mobile-ceu-driver: support max width and height in DT
V4L2: add temporary clock helpers
V4L2: add a device pointer to struct v4l2_subdev
V4L2: support asynchronous subdevice registration
soc-camera: switch I2C subdevice drivers to use v4l2-clk
soc-camera: add V4L2-async support
sh_mobile_ceu_camera: add asynchronous subdevice probing support
imx074: support asynchronous probing
ARM: shmobile: convert ap4evb to asynchronously register camera
subdevices
.../devicetree/bindings/media/sh_mobile_ceu.txt| 18 +
arch/arm/mach-shmobile/board-ap4evb.c | 103 ++--
arch/arm/mach-shmobile/clock-sh7372.c |1 +
drivers/media/i2c/soc_camera/imx074.c | 32 +-
drivers/media/i2c/soc_camera/mt9m001.c | 17 +-
drivers/media/i2c/soc_camera/mt9m111.c | 20 +-
drivers/media/i2c/soc_camera/mt9t031.c | 19 +-
drivers/media/i2c/soc_camera/mt9t112.c | 25 +-
drivers/media/i2c/soc_camera/mt9v022.c | 17 +-
drivers/media/i2c/soc_camera/ov2640.c | 19 +-
drivers/media/i2c/soc_camera/ov5642.c | 20 +-
drivers/media/i2c/soc_camera/ov6650.c | 17 +-
drivers/media/i2c/soc_camera/ov772x.c | 15 +-
drivers/media/i2c/soc_camera/ov9640.c | 17 +-
drivers/media/i2c/soc_camera/ov9640.h |1 +
drivers/media/i2c/soc_camera/ov9740.c | 18 +-
drivers/media/i2c/soc_camera/rj54n1cb0c.c | 17 +-
drivers/media/i2c/soc_camera/tw9910.c | 24 +-
drivers/media/platform/soc_camera/atmel-isi.c | 38 +-
drivers/media/platform/soc_camera/mx1_camera.c | 48 +-
drivers/media/platform/soc_camera/mx2_camera.c | 41 +-
drivers/media/platform/soc_camera/mx3_camera.c | 44 +-
drivers/media/platform/soc_camera/omap1_camera.c | 41 +-
drivers/media/platform/soc_camera/pxa_camera.c | 46 +-
.../platform/soc_camera/sh_mobile_ceu_camera.c | 243 +--
drivers/media/platform/soc_camera/sh_mobile_csi2.c | 153 +++--
drivers/media/platform/soc_camera/soc_camera.c | 707
+---
.../platform/soc_camera/soc_camera_platform.c |2 +-
drivers/media/v4l2-core/Makefile |3 +-
drivers/media/v4l2-core/v4l2-async.c | 280
drivers/media/v4l2-core/v4l2-clk.c | 242 +++
drivers/media/v4l2-core/v4l2-common.c |2 +
include/media/sh_mobile_ceu.h |2 +
include/media/sh_mobile_csi2.h |2 +-
include/media/soc_camera.h | 39 +-
include/media/v4l2-async.h | 105 +++
include/media/v4l2-clk.h | 54 ++
include/media/v4l2-subdev.h| 10 +
38 files changed, 2035 insertions(+), 467 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/sh_mobile_ceu.txt
create mode 100644 drivers/media/v4l2-core/v4l2-async.c
create mode 100644 drivers/media/v4l2-core/v4l2-clk.c
create mode 100644 include/media/v4l2-async.h
create mode 100644 include/media/v4l2-clk.h
--
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
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
This patch adds a buffer synchronization framework based on DMA BUF[1] and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] for lock mechanism. The purpose of this framework is not only to couple cache operations, and buffer access control to CPU and DMA but also to provide easy-to-use interfaces for device drivers and potentially user application (not implemented for user applications, yet). And this framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. Changelog v2: - use atomic_add_unless to avoid potential bug. - add a macro for checking valid access type. - code clean. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get - lock - CPU or DMA access to a buffer/s - unlock - put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, test sync); dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... And the below can be used as access types: DMA_BUF_ACCESS_READ, - CPU will access a buffer for read. DMA_BUF_ACCESS_WRITE, - CPU will access a buffer for read or write. DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read or write. 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. A task may never try to unlock a buffer after taking a lock to the buffer. In this case, a timer handler to the corresponding sync object is called in five (default) seconds and then the timed-out buffer is unlocked by work queue handler to avoid lockups and to enforce resources of the buffer. The below is how to use: 1. Allocate and Initialize a sync object: struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, test sync); ... 2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... 3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: dmabuf_sync_lock(sync); ... 4. Now CPU or DMA can access all dmabufs locked in step 3. 5. Unlock all dmabufs added in a sync object after DMA or CPU access to these dmabufs is completed: dmabuf_sync_unlock(sync); And call the following functions to release all resources, dmabuf_sync_put_all(sync); dmabuf_sync_fini(sync); You can refer to actual example codes: https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/ commit/?h=dmabuf-syncid=4030bdee9bab5841ad32faade528d04cc0c5fc94
Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
Op 17-06-13 13:15, Inki Dae schreef: This patch adds a buffer synchronization framework based on DMA BUF[1] and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] for lock mechanism. The purpose of this framework is not only to couple cache operations, and buffer access control to CPU and DMA but also to provide easy-to-use interfaces for device drivers and potentially user application (not implemented for user applications, yet). And this framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. Changelog v2: - use atomic_add_unless to avoid potential bug. - add a macro for checking valid access type. - code clean. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get - lock - CPU or DMA access to a buffer/s - unlock - put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, test sync); dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... And the below can be used as access types: DMA_BUF_ACCESS_READ, - CPU will access a buffer for read. DMA_BUF_ACCESS_WRITE, - CPU will access a buffer for read or write. DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read or write. 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. A task may never try to unlock a buffer after taking a lock to the buffer. In this case, a timer handler to the corresponding sync object is called in five (default) seconds and then the timed-out buffer is unlocked by work queue handler to avoid lockups and to enforce resources of the buffer. The below is how to use: 1. Allocate and Initialize a sync object: struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, test sync); ... 2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... 3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: dmabuf_sync_lock(sync); ... 4. Now CPU or DMA can access all dmabufs locked in step 3. 5. Unlock all dmabufs added in a sync object after DMA or CPU access to these dmabufs is completed: dmabuf_sync_unlock(sync); And call the following functions to release all resources, dmabuf_sync_put_all(sync); dmabuf_sync_fini(sync); You can refer to actual example codes: https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/ commit/?h=dmabuf-syncid=4030bdee9bab5841ad32faade528d04cc0c5fc94
Re: [RFC] Add query/get/set matrix ioctls
On Mon 17 June 2013 00:09:59 Sakari Ailus wrote: Hi Hans, On Wed, Jun 12, 2013 at 02:57:21PM +0200, Hans Verkuil wrote: On Wed 12 June 2013 14:26:27 Sakari Ailus wrote: Hi Hans, Thanks for the RFC! On Wed, Jun 12, 2013 at 10:35:07AM +0200, Hans Verkuil wrote: On Tue 11 June 2013 23:33:42 Sylwester Nawrocki wrote: Hi Hans, On 06/03/2013 02:14 PM, Hans Verkuil wrote: Hi all, When working on the Motion Detection API, I realized that my proposal for two new G/S_MD_BLOCKS ioctls was too specific for the motion detection use case. The Motion Detection RFC can be found here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg62085.html What I was really attempting to do was to create an API to pass a matrix to the hardware. This is also related to a long-standing request to add support for arrays to the control API. Adding such support to the control API is in my opinion a very bad idea since the control API is meant to provide all meta data necessary in order to create e.g. control panels. Adding array support to the control API would make that very difficult, particularly with respect to GUI design. So instead this proposal creates a new API to query, get and set matrices: This looks very interesting, one use case that comes immediately to mind is configuring the quantization/Huffman tables in a hardware JPEG codec. The only thing left would have probably been setting up the comment segments, consisting of arbitrary byte strings. Actually, I realized that that can be handled as well since those segments are 1-dimensional matrices of unsigned chars. This is even more nice than your previous proposal ;) Quite generic - but I was wondering, what if we went one step further and defined QUERY/GET/ SET_PROPERTY ioctls, where the type (matrix or anything else) would be also configurable ? :-) Just brainstorming, if memory serves me well few people suggested something like this in the past. Interesting idea. This approach could be used on the Media controller interface as well. What is needed for the MC (if memory serves) is something simple to list what effectively are capabilities of entities. Basically just a list of integers. That's quite different from this highly generic proposal. I think I should have said property API instead. That's what I meant. This could be prototyped and discussed. Which device nodes that API could eventually use is another matter. From API design point of view it's somewhat odd that a device (especially when it comes to embedded systems) is visible in the system as a large number of device nodes. I know there are a huge number of reasons why it's so currently but if I were to create a new API, that's one thing I would correct. But in the context of matrix IOCTLs, this begins to be off-topic. The problem with that is that you basically create a meta-ioctl. Why not just create an ioctl for whatever you want to do? After all, an ioctl is basically a type (the command number) and a pointer. And with a property ioctl you really just wrap that into another ioctl. Is this a problem? I think so, yes. It seems to me that this just adds an unnecessary indirection that everyone (userspace and kernelspace) has to cope with. I don't see any advantage of going in this direction. To some extent one could claim the controls API does exactly that: it provides a generic way to access properties of certain kind. I like controls and extended controls even more: the standard API makes many other things easier in user space, including enumeration. One of the benefits is that you could send multiple IOCTL commands to the device at one go (if the interface is designed as such, and I think it should be). There are other ways this can be done (we discussed that in the past) without introducing complex new ioctls. And the reality is that this doesn't really Could you refresh my memory a bit? I can't remember whether we discussed that during a meeting or via an RFC. Anyway, the idea was to have something transaction based: e.g. queue up a number of ioctls, then 'commit' or 'execute' them. I seem to remember I wrote an RFC on that topic, but it was probably 1-2 years ago. I remember synchronisation of applying configurations being discussed, and, well, most of the time that certainly isn't an issue, but if you wish to ensure two configuration parameters on different subdevs take effect at the same time, there's no fully generic way to do that in the API: you have to rely on timing to some extent. You cannot sync two different pieces of hardware at the same time
[GIT PULL FOR 3.11] Media entity link handling fixes
Hi Mauro, This includes corrections of the media entity links handling and resolves potential issues when media entity drivers are in different kernel modules. It allows to keep all entities that belong to same media graph in correct state, when one of an entity's driver module gets unloaded. The following changes since commit dd8c393b3c39f7ebd9ad69ce50cc836773d512b6: [media] media: i2c: ths7303: make the pdata as a constant pointer (2013-06-13 11:42:17 -0300) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git for-v3.11-2 for you to fetch changes up to 28521e45c4478b7bc083e445573aacb7d174dd35: V4L: Remove all links of the media entity when unregistering subdev (2013-06-17 13:42:22 +0200) Sakari Ailus (2): davinci_vpfe: Clean up media entity after unregistering subdev smiapp: Clean up media entity after unregistering subdev Sylwester Nawrocki (2): media: Add a function removing all links of a media entity V4L: Remove all links of the media entity when unregistering subdev drivers/media/i2c/smiapp/smiapp-core.c |2 +- drivers/media/media-entity.c | 50 drivers/media/v4l2-core/v4l2-device.c |4 +- drivers/staging/media/davinci_vpfe/dm365_ipipe.c |4 +- drivers/staging/media/davinci_vpfe/dm365_ipipeif.c |4 +- drivers/staging/media/davinci_vpfe/dm365_isif.c|4 +- drivers/staging/media/davinci_vpfe/dm365_resizer.c | 14 +++--- drivers/staging/media/davinci_vpfe/vpfe_video.c|2 +- include/media/media-entity.h |3 ++ 9 files changed, 71 insertions(+), 16 deletions(-) Thanks, Sylwester -- 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
[GIT PULL FOR 3.10] exynos4-is driver BUG fix
Hi Mauro, Only one patch in this pull request, but it fixes pretty serious bug, that took me long time to debug. Please queue for 3.10, if possible. The following changes since commit af44ad5edd1eb6ca92ed5be48e0004e1f04bf219: [media] soc_camera: error dev remove and v4l2 call (2013-06-08 21:51:06 -0300) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git v3.10-fixes-3 for you to fetch changes up to 21c62485ee61398eadc27b4fbab66a832860c008: exynos4-is: Fix FIMC-IS clocks initialization (2013-06-17 14:27:28 +0200) Sylwester Nawrocki (1): exynos4-is: Fix FIMC-IS clocks initialization drivers/media/platform/exynos4-is/fimc-is.c | 26 -- drivers/media/platform/exynos4-is/fimc-is.h |1 - 2 files changed, 8 insertions(+), 19 deletions(-) Thanks, Sylwester -- 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 PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
-Original Message- From: Maarten Lankhorst [mailto:maarten.lankho...@canonical.com] Sent: Monday, June 17, 2013 8:35 PM To: Inki Dae Cc: dri-de...@lists.freedesktop.org; linux-fb...@vger.kernel.org; linux- arm-ker...@lists.infradead.org; linux-media@vger.kernel.org; dan...@ffwll.ch; robdcl...@gmail.com; kyungmin.p...@samsung.com; myungjoo@samsung.com; yj44@samsung.com Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework Op 17-06-13 13:15, Inki Dae schreef: This patch adds a buffer synchronization framework based on DMA BUF[1] and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] for lock mechanism. The purpose of this framework is not only to couple cache operations, and buffer access control to CPU and DMA but also to provide easy-to-use interfaces for device drivers and potentially user application (not implemented for user applications, yet). And this framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. Changelog v2: - use atomic_add_unless to avoid potential bug. - add a macro for checking valid access type. - code clean. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get - lock - CPU or DMA access to a buffer/s - unlock - put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, test sync); dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... And the below can be used as access types: DMA_BUF_ACCESS_READ, - CPU will access a buffer for read. DMA_BUF_ACCESS_WRITE, - CPU will access a buffer for read or write. DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read or write. 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. A task may never try to unlock a buffer after taking a lock to the buffer. In this case, a timer handler to the corresponding sync object is called in five (default) seconds and then the timed-out buffer is unlocked by work queue handler to avoid lockups and to enforce resources of the buffer. The below is how to use: 1. Allocate and Initialize a sync object: struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, test sync); ... 2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... 3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: dmabuf_sync_lock(sync); ... 4. Now CPU or DMA can access all dmabufs locked in
Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
Op 17-06-13 15:04, Inki Dae schreef: -Original Message- From: Maarten Lankhorst [mailto:maarten.lankho...@canonical.com] Sent: Monday, June 17, 2013 8:35 PM To: Inki Dae Cc: dri-de...@lists.freedesktop.org; linux-fb...@vger.kernel.org; linux- arm-ker...@lists.infradead.org; linux-media@vger.kernel.org; dan...@ffwll.ch; robdcl...@gmail.com; kyungmin.p...@samsung.com; myungjoo@samsung.com; yj44@samsung.com Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework Op 17-06-13 13:15, Inki Dae schreef: This patch adds a buffer synchronization framework based on DMA BUF[1] and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] for lock mechanism. The purpose of this framework is not only to couple cache operations, and buffer access control to CPU and DMA but also to provide easy-to-use interfaces for device drivers and potentially user application (not implemented for user applications, yet). And this framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. Changelog v2: - use atomic_add_unless to avoid potential bug. - add a macro for checking valid access type. - code clean. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get - lock - CPU or DMA access to a buffer/s - unlock - put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, test sync); dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... And the below can be used as access types: DMA_BUF_ACCESS_READ, - CPU will access a buffer for read. DMA_BUF_ACCESS_WRITE, - CPU will access a buffer for read or write. DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read or write. 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. A task may never try to unlock a buffer after taking a lock to the buffer. In this case, a timer handler to the corresponding sync object is called in five (default) seconds and then the timed-out buffer is unlocked by work queue handler to avoid lockups and to enforce resources of the buffer. The below is how to use: 1. Allocate and Initialize a sync object: struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, test sync); ... 2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... 3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: dmabuf_sync_lock(sync); ... 4. Now CPU or DMA can access all dmabufs locked in step 3. 5. Unlock all dmabufs added in a sync object after DMA
Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Mon, Jun 17, 2013 at 10:04:45PM +0900, Inki Dae wrote: It's just to implement a thin sync framework coupling cache operation. This approach is based on dma-buf for more generic implementation against android sync driver or KDS. The described steps may be summarized as: lock - cache operation - CPU or DMA access to a buffer/s - unlock I think that there is no need to get complicated for such approach at least for most devices sharing system memory. Simple is best. But hang on, doesn't the dmabuf API already provide that? The dmabuf API already uses dma_map_sg() and dma_unmap_sg() by providers, and the rules around the DMA API are that: dma_map_sg() /* DMA _ONLY_ has access, CPU should not access */ dma_unmap_sg() /* DMA may not access, CPU can access */ It's a little more than that if you include the sync_sg_for_cpu and sync_sg_for_device APIs too - but the above is the general idea. What this means from the dmabuf API point of view is that once you attach to a dma_buf, and call dma_buf_map_attachment() to get the SG list, the CPU doesn't have ownership of the buffer and _must_ _not_ access it via any other means - including using the other dma_buf methods, until either the appropriate dma_sync_sg_for_cpu() call has been made or the DMA mapping has been removed via dma_buf_unmap_attachment(). So, the sequence should be: dma_buf_map_attachment() /* do DMA */ dma_buf_unmap_attachment() /* CPU can now access the buffer */ -- 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] [media] usbtv: Add driver for Fushicai USBTV007 video frame grabber
On Wed, 2013-06-12 at 09:49 +0200, Hans Verkuil wrote:
...
+static int usbtv_queryctrl(struct file *file, void *priv,
+ struct v4l2_queryctrl *ctrl)
+{
+ return -EINVAL;
+}
Drop this ioctl. If it doesn't do anything, then don't specify it.
It actually does something; EINVAL here for any ctrl signals there's
zero controls.
When undefined, ENOTTY that is returned is considered invalid by
gstreamer source.
What version of gstreamer are you using? Looking at the gstreamer code it
seems that it can handle ENOTTY at least since September last year. Not
handling
ENOTTY is an application bug (there are other - rare - drivers that do not
have any controls) and as such I really don't like seeing a workaround like
this in a driver, especially since this seems like it should be working fine
with the latest gstreamer.
I was using GStreamer from RHEL6. I retried with Fedora 17 and it worked
fine.
Regards,
Lubo
--
Lubomir Rintel lkund...@v3.sk
--
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 v4] [media] usbtv: Add driver for Fushicai USBTV007 video frame grabber
Reverse-engineered driver for cheapo video digitizer, made from observations of Windows XP driver. The protocol is not yet completely understood, so far we don't provide any controls, only support a single format out of three and don't support the audio device. Signed-off-by: Lubomir Rintel lkund...@v3.sk Acked-by: Hans Verkuil hans.verk...@cisco.com Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: linux-ker...@vger.kernel.org Cc: linux-media@vger.kernel.org --- Changes for v2: - Fix a typo in comment - Make prototype register settings static const - Solve parity calculation weirdness - Attempt to fix interlacing - Add timestamp to frames - [v4l2-compliance] Set pix format priv to 0 - Drop usbtv_*_fmt_vid_cap code duplication - [v4l2-compliance] Add vidioc_create_bufs - [v4l2-compliance] Use file handle priorities - Drop Driver from initial dev_info Changes for v3: - Utilize ARRAY_SIZE - Drop queryctrl ioctl - Reduce default number of buffers to two - Remove unnecessary locking - video_set_drvdata() before video_register_device() Changes for v4: - Fix default buffer count setting - Use strlcpy() instead of strncpy() drivers/media/usb/Kconfig|1 + drivers/media/usb/Makefile |1 + drivers/media/usb/usbtv/Kconfig | 10 + drivers/media/usb/usbtv/Makefile |1 + drivers/media/usb/usbtv/usbtv.c | 696 ++ 5 files changed, 709 insertions(+), 0 deletions(-) create mode 100644 drivers/media/usb/usbtv/Kconfig create mode 100644 drivers/media/usb/usbtv/Makefile create mode 100644 drivers/media/usb/usbtv/usbtv.c diff --git a/drivers/media/usb/Kconfig b/drivers/media/usb/Kconfig index 0a7d520..8e10267 100644 --- a/drivers/media/usb/Kconfig +++ b/drivers/media/usb/Kconfig @@ -17,6 +17,7 @@ source drivers/media/usb/zr364xx/Kconfig source drivers/media/usb/stkwebcam/Kconfig source drivers/media/usb/s2255/Kconfig source drivers/media/usb/sn9c102/Kconfig +source drivers/media/usb/usbtv/Kconfig endif if MEDIA_ANALOG_TV_SUPPORT diff --git a/drivers/media/usb/Makefile b/drivers/media/usb/Makefile index 7f51d7e..0935f47 100644 --- a/drivers/media/usb/Makefile +++ b/drivers/media/usb/Makefile @@ -20,3 +20,4 @@ obj-$(CONFIG_VIDEO_STK1160) += stk1160/ obj-$(CONFIG_VIDEO_CX231XX) += cx231xx/ obj-$(CONFIG_VIDEO_TM6000) += tm6000/ obj-$(CONFIG_VIDEO_EM28XX) += em28xx/ +obj-$(CONFIG_VIDEO_USBTV) += usbtv/ diff --git a/drivers/media/usb/usbtv/Kconfig b/drivers/media/usb/usbtv/Kconfig new file mode 100644 index 000..8864436 --- /dev/null +++ b/drivers/media/usb/usbtv/Kconfig @@ -0,0 +1,10 @@ +config VIDEO_USBTV +tristate USBTV007 video capture support +depends on VIDEO_DEV +select VIDEOBUF2_VMALLOC + +---help--- + This is a video4linux2 driver for USBTV007 based video capture devices. + + To compile this driver as a module, choose M here: the + module will be called usbtv diff --git a/drivers/media/usb/usbtv/Makefile b/drivers/media/usb/usbtv/Makefile new file mode 100644 index 000..28b872f --- /dev/null +++ b/drivers/media/usb/usbtv/Makefile @@ -0,0 +1 @@ +obj-$(CONFIG_VIDEO_USBTV) += usbtv.o diff --git a/drivers/media/usb/usbtv/usbtv.c b/drivers/media/usb/usbtv/usbtv.c new file mode 100644 index 000..bf43f87 --- /dev/null +++ b/drivers/media/usb/usbtv/usbtv.c @@ -0,0 +1,696 @@ +/* + * Fushicai USBTV007 Video Grabber Driver + * + * Product web site: + * http://www.fushicai.com/products_detail/productId=d05449ee-b690-42f9-a661-aa7353894bed.html + * + * Following LWN articles were very useful in construction of this driver: + * Video4Linux2 API series: http://lwn.net/Articles/203924/ + * videobuf2 API explanation: http://lwn.net/Articles/447435/ + * Thanks go to Jonathan Corbet for providing this quality documentation. + * He is awesome. + * + * Copyright (c) 2013 Lubomir Rintel + * All rights reserved. + * No physical hardware was harmed running Windows during the + * reverse-engineering activity + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions, and the following disclaimer, + *without modification. + * 2. The name of the author may not be used to endorse or promote products + *derived from this software without specific prior written permission. + * + * Alternatively, this software may be distributed under the terms of the + * GNU General Public License (GPL). + */ + +#include linux/init.h +#include linux/list.h +#include linux/module.h +#include linux/slab.h +#include linux/usb.h +#include linux/version.h +#include linux/videodev2.h + +#include media/v4l2-device.h +#include media/v4l2-ioctl.h +#include media/videobuf2-core.h +#include media/videobuf2-vmalloc.h + +/* Hardware. */ +#define
RE: [PATCH 3/6] [media] s5p-mfc: Core support for MFC v7
Hi Arun,
I have read your patches. They seem alright, I back comments made by Hans
and Sylwester. I have one question, which follows inline.
Best wishes,
--
Kamil Debski
Linux Kernel Developer
Samsung RD Institute Poland
-Original Message-
From: Arun Kumar K [mailto:arun...@samsung.com]
Sent: Monday, June 10, 2013 3:23 PM
To: linux-media@vger.kernel.org
Cc: k.deb...@samsung.com; jtp.p...@samsung.com; s.nawro...@samsung.com;
avnd.ki...@samsung.com; arunkk.sams...@gmail.com
Subject: [PATCH 3/6] [media] s5p-mfc: Core support for MFC v7
Adds variant data and core support for the MFC v7 firmware
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c| 32
+++
drivers/media/platform/s5p-mfc/s5p_mfc_common.h |2 ++
2 files changed, 34 insertions(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index d12faa6..d6be52f 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1391,6 +1391,32 @@ static struct s5p_mfc_variant mfc_drvdata_v6 = {
.fw_name= s5p-mfc-v6.fw,
};
+struct s5p_mfc_buf_size_v6 mfc_buf_size_v7 = {
+ .dev_ctx= MFC_CTX_BUF_SIZE_V7,
+ .h264_dec_ctx = MFC_H264_DEC_CTX_BUF_SIZE_V7,
+ .other_dec_ctx = MFC_OTHER_DEC_CTX_BUF_SIZE_V7,
+ .h264_enc_ctx = MFC_H264_ENC_CTX_BUF_SIZE_V7,
+ .other_enc_ctx = MFC_OTHER_ENC_CTX_BUF_SIZE_V7,
+};
+
+struct s5p_mfc_buf_size buf_size_v7 = {
+ .fw = MAX_FW_SIZE_V7,
+ .cpb= MAX_CPB_SIZE_V7,
+ .priv = mfc_buf_size_v7,
+};
+
+struct s5p_mfc_buf_align mfc_buf_align_v7 = {
+ .base = 0,
+};
+
+static struct s5p_mfc_variant mfc_drvdata_v7 = {
+ .version= MFC_VERSION_V7,
+ .port_num = MFC_NUM_PORTS_V7,
+ .buf_size = buf_size_v7,
+ .buf_align = mfc_buf_align_v7,
+ .fw_name= s5p-mfc-v7.fw,
+};
+
static struct platform_device_id mfc_driver_ids[] = {
{
.name = s5p-mfc,
@@ -1401,6 +1427,9 @@ static struct platform_device_id mfc_driver_ids[]
= {
}, {
.name = s5p-mfc-v6,
.driver_data = (unsigned long)mfc_drvdata_v6,
+ }, {
+ .name = s5p-mfc-v7,
+ .driver_data = (unsigned long)mfc_drvdata_v7,
},
{},
};
@@ -1413,6 +1442,9 @@ static const struct of_device_id
exynos_mfc_match[] = {
}, {
.compatible = samsung,mfc-v6,
.data = mfc_drvdata_v6,
+ }, {
+ .compatible = samsung,mfc-v7,
+ .data = mfc_drvdata_v7,
},
{},
};
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index ef4074c..7281de2 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -24,6 +24,7 @@
#include media/videobuf2-core.h
#include regs-mfc.h
#include regs-mfc-v6.h
+#include regs-mfc-v7.h
/* Definitions related to MFC memory */
@@ -684,5 +685,6 @@ void set_work_bit_irqsave(struct s5p_mfc_ctx *ctx);
(dev-variant-port_num ? 1 : 0) : 0) : 0)
#define IS_TWOPORT(dev) (dev-variant-port_num == 2 ? 1 :
0)
#define IS_MFCV6(dev)(dev-variant-version = 0x60 ? 1 :
0)
+#define IS_MFCV7(dev)(dev-variant-version = 0x70 ? 1 :
0)
According to this, MFC v7 is also detected as MFC v6. Was this intended?
I think that it would be much better to use this in code:
if (IS_MFCV6(dev) || IS_MFCV7(dev))
And change the define to detect only single MFC revision:
#define IS_MFCV6(dev) (dev-variant-version = 0x60
dev-variant-version 0x70)
Other possibility I see is to change the name of the check. Although
IS_MFCV6_OR_NEWER(dev) seems too long :)
#endif /* S5P_MFC_COMMON_H_ */
--
1.7.9.5
--
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 3/8] [media] coda: do not allocate maximum number of framebuffers for encoder
The encoder only ever needs two buffers, but we'll have to increase
CODA_MAX_FRAMEBUFFERS for the decoder.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index baf0ce8..6d76f1d 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -997,7 +997,6 @@ static int coda_alloc_framebuffers(struct coda_ctx *ctx,
struct coda_q_data *q_d
ysize = round_up(q_data-width, 8) * height;
/* Allocate frame buffers */
- ctx-num_internal_frames = CODA_MAX_FRAMEBUFFERS;
for (i = 0; i ctx-num_internal_frames; i++) {
ctx-internal_frames[i].size = q_data-sizeimage;
if (fourcc == V4L2_PIX_FMT_H264 dev-devtype-product !=
CODA_DX6)
@@ -1347,6 +1346,7 @@ static int coda_start_streaming(struct vb2_queue *q,
unsigned int count)
goto out;
}
+ ctx-num_internal_frames = 2;
ret = coda_alloc_framebuffers(ctx, q_data_src, dst_fourcc);
if (ret 0) {
v4l2_err(v4l2_dev, failed to allocate framebuffers\n);
--
1.8.3.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 0/8] CODA7541 decoding support
The following patch series depends on the CODA patches queued in Kamil's branch and on the mem2mem: add support for hardware buffered queue patch I've posted earlier. It should allow decoding h.264 high profile 1080p streams on i.MX53 with the current CODA7541 firmware version 1.4.50. regards Philipp --- drivers/media/platform/coda.c | 1471 +++-- drivers/media/platform/coda.h | 107 ++- 2 files changed, 1389 insertions(+), 189 deletions(-) -- 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 7/8] [media] coda: split encoder specific parts out of device_run and irq_handler
Add coda_prepare_encode() and coda_finish_encode() functions. They are called
from coda_device_run() and coda_irq_handler(), respectively, before and after
the hardware picture run. This should make the following decoder support patch
easier to read, which will add the coda_prepare/finish_decode() equivalents.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda.c | 82 +--
1 file changed, 48 insertions(+), 34 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index 856a93e..e8b3708 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -793,9 +793,8 @@ static void coda_fill_bitstream(struct coda_ctx *ctx)
/*
* Mem-to-mem operations.
*/
-static void coda_device_run(void *m2m_priv)
+static void coda_prepare_encode(struct coda_ctx *ctx)
{
- struct coda_ctx *ctx = m2m_priv;
struct coda_q_data *q_data_src, *q_data_dst;
struct vb2_buffer *src_buf, *dst_buf;
struct coda_dev *dev = ctx-dev;
@@ -805,8 +804,6 @@ static void coda_device_run(void *m2m_priv)
u32 pic_stream_buffer_addr, pic_stream_buffer_size;
u32 dst_fourcc;
- mutex_lock(dev-coda_mutex);
-
src_buf = v4l2_m2m_next_src_buf(ctx-m2m_ctx);
dst_buf = v4l2_m2m_next_dst_buf(ctx-m2m_ctx);
q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
@@ -917,6 +914,16 @@ static void coda_device_run(void *m2m_priv)
coda_write(dev, pic_stream_buffer_addr, CODA_CMD_ENC_PIC_BB_START);
coda_write(dev, pic_stream_buffer_size / 1024,
CODA_CMD_ENC_PIC_BB_SIZE);
+}
+
+static void coda_device_run(void *m2m_priv)
+{
+ struct coda_ctx *ctx = m2m_priv;
+ struct coda_dev *dev = ctx-dev;
+
+ mutex_lock(dev-coda_mutex);
+
+ coda_prepare_encode(ctx);
if (dev-devtype-product == CODA_7541) {
coda_write(dev, CODA7_USE_BIT_ENABLE |
CODA7_USE_HOST_BIT_ENABLE |
@@ -2025,39 +2032,11 @@ static const struct v4l2_file_operations coda_fops = {
.mmap = coda_mmap,
};
-static irqreturn_t coda_irq_handler(int irq, void *data)
+static void coda_encode_finish(struct coda_ctx *ctx)
{
struct vb2_buffer *src_buf, *dst_buf;
- struct coda_dev *dev = data;
+ struct coda_dev *dev = ctx-dev;
u32 wr_ptr, start_ptr;
- struct coda_ctx *ctx;
-
- cancel_delayed_work(dev-timeout);
-
- /* read status register to attend the IRQ */
- coda_read(dev, CODA_REG_BIT_INT_STATUS);
- coda_write(dev, CODA_REG_BIT_INT_CLEAR_SET,
- CODA_REG_BIT_INT_CLEAR);
-
- ctx = v4l2_m2m_get_curr_priv(dev-m2m_dev);
- if (ctx == NULL) {
- v4l2_err(dev-v4l2_dev, Instance released before the end of
transaction\n);
- mutex_unlock(dev-coda_mutex);
- return IRQ_HANDLED;
- }
-
- if (ctx-aborting) {
- v4l2_dbg(1, coda_debug, ctx-dev-v4l2_dev,
-task has been aborted\n);
- mutex_unlock(dev-coda_mutex);
- return IRQ_HANDLED;
- }
-
- if (coda_isbusy(ctx-dev)) {
- v4l2_dbg(1, coda_debug, ctx-dev-v4l2_dev,
-coda is still busy\n);
- return IRQ_NONE;
- }
src_buf = v4l2_m2m_src_buf_remove(ctx-m2m_ctx);
dst_buf = v4l2_m2m_dst_buf_remove(ctx-m2m_ctx);
@@ -2106,6 +2085,41 @@ static irqreturn_t coda_irq_handler(int irq, void *data)
dst_buf-v4l2_buf.sequence,
(dst_buf-v4l2_buf.flags V4L2_BUF_FLAG_KEYFRAME) ?
KEYFRAME : PFRAME);
+}
+
+static irqreturn_t coda_irq_handler(int irq, void *data)
+{
+ struct coda_dev *dev = data;
+ struct coda_ctx *ctx;
+
+ cancel_delayed_work(dev-timeout);
+
+ /* read status register to attend the IRQ */
+ coda_read(dev, CODA_REG_BIT_INT_STATUS);
+ coda_write(dev, CODA_REG_BIT_INT_CLEAR_SET,
+ CODA_REG_BIT_INT_CLEAR);
+
+ ctx = v4l2_m2m_get_curr_priv(dev-m2m_dev);
+ if (ctx == NULL) {
+ v4l2_err(dev-v4l2_dev, Instance released before the end of
transaction\n);
+ mutex_unlock(dev-coda_mutex);
+ return IRQ_HANDLED;
+ }
+
+ if (ctx-aborting) {
+ v4l2_dbg(1, coda_debug, ctx-dev-v4l2_dev,
+task has been aborted\n);
+ mutex_unlock(dev-coda_mutex);
+ return IRQ_HANDLED;
+ }
+
+ if (coda_isbusy(ctx-dev)) {
+ v4l2_dbg(1, coda_debug, ctx-dev-v4l2_dev,
+coda is still busy\n);
+ return IRQ_NONE;
+ }
+
+ coda_encode_finish(ctx);
mutex_unlock(dev-coda_mutex);
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More
[PATCH 1/8] [media] coda: use vb2_set_plane_payload instead of setting v4l2_planes[0].bytesused directly
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index c4566c4..90f3386 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -1662,12 +1662,12 @@ static irqreturn_t coda_irq_handler(int irq, void *data)
wr_ptr = coda_read(dev, CODA_REG_BIT_WR_PTR(ctx-idx));
/* Calculate bytesused field */
if (dst_buf-v4l2_buf.sequence == 0) {
- dst_buf-v4l2_planes[0].bytesused = (wr_ptr - start_ptr) +
- ctx-vpu_header_size[0] +
- ctx-vpu_header_size[1] +
- ctx-vpu_header_size[2];
+ vb2_set_plane_payload(dst_buf, 0, wr_ptr - start_ptr +
+ ctx-vpu_header_size[0] +
+ ctx-vpu_header_size[1] +
+ ctx-vpu_header_size[2]);
} else {
- dst_buf-v4l2_planes[0].bytesused = (wr_ptr - start_ptr);
+ vb2_set_plane_payload(dst_buf, 0, wr_ptr - start_ptr);
}
v4l2_dbg(1, coda_debug, ctx-dev-v4l2_dev, frame size = %u\n,
--
1.8.3.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 5/8] [media] coda: add bitstream ringbuffer handling for decoder
Add a bitstream ringbuffer using kfifo. Queued source buffers are to be copied
into the bitstream ringbuffer immediately and marked as done, if possible.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda.c | 134 +-
drivers/media/platform/coda.h | 3 +
2 files changed, 134 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index 28ee3f7..1f3bd43 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -18,6 +18,7 @@
#include linux/interrupt.h
#include linux/io.h
#include linux/irq.h
+#include linux/kfifo.h
#include linux/module.h
#include linux/of_device.h
#include linux/platform_device.h
@@ -182,6 +183,7 @@ struct coda_ctx {
int streamon_out;
int streamon_cap;
u32 isequence;
+ u32 qsequence;
struct coda_q_data q_data[2];
enum coda_inst_type inst_type;
struct coda_codec *codec;
@@ -193,6 +195,9 @@ struct coda_ctx {
int gopcounter;
charvpu_header[3][64];
int vpu_header_size[3];
+ struct kfifobitstream_fifo;
+ struct mutexbitstream_mutex;
+ struct coda_aux_buf bitstream;
struct coda_aux_buf parabuf;
struct coda_aux_buf internal_frames[CODA_MAX_FRAMEBUFFERS];
struct coda_aux_buf workbuf;
@@ -200,6 +205,7 @@ struct coda_ctx {
int idx;
int reg_idx;
struct coda_iram_info iram_info;
+ u32 bit_stream_param;
};
static const u8 coda_filler_nal[14] = { 0x00, 0x00, 0x00, 0x01, 0x0c, 0xff,
@@ -249,6 +255,8 @@ static void coda_command_async(struct coda_ctx *ctx, int
cmd)
if (dev-devtype-product == CODA_7541) {
/* Restore context related registers to CODA */
+ coda_write(dev, ctx-bit_stream_param,
+ CODA_REG_BIT_BIT_STREAM_PARAM);
coda_write(dev, ctx-workbuf.paddr, CODA_REG_BIT_WORK_BUF_ADDR);
}
@@ -683,6 +691,105 @@ static const struct v4l2_ioctl_ops coda_ioctl_ops = {
.vidioc_streamoff = vidioc_streamoff,
};
+static inline int coda_get_bitstream_payload(struct coda_ctx *ctx)
+{
+ return kfifo_len(ctx-bitstream_fifo);
+}
+
+static void coda_kfifo_sync_from_device(struct coda_ctx *ctx)
+{
+ struct __kfifo *kfifo = ctx-bitstream_fifo.kfifo;
+ struct coda_dev *dev = ctx-dev;
+ u32 rd_ptr;
+
+ rd_ptr = coda_read(dev, CODA_REG_BIT_RD_PTR(ctx-reg_idx));
+ kfifo-out = (kfifo-in ~kfifo-mask) |
+ (rd_ptr - ctx-bitstream.paddr);
+ if (kfifo-out kfifo-in)
+ kfifo-out -= kfifo-mask + 1;
+}
+
+static void coda_kfifo_sync_to_device_full(struct coda_ctx *ctx)
+{
+ struct __kfifo *kfifo = ctx-bitstream_fifo.kfifo;
+ struct coda_dev *dev = ctx-dev;
+ u32 rd_ptr, wr_ptr;
+
+ rd_ptr = ctx-bitstream.paddr + (kfifo-out kfifo-mask);
+ coda_write(dev, rd_ptr, CODA_REG_BIT_RD_PTR(ctx-reg_idx));
+ wr_ptr = ctx-bitstream.paddr + (kfifo-in kfifo-mask);
+ coda_write(dev, wr_ptr, CODA_REG_BIT_WR_PTR(ctx-reg_idx));
+}
+
+static void coda_kfifo_sync_to_device_write(struct coda_ctx *ctx)
+{
+ struct __kfifo *kfifo = ctx-bitstream_fifo.kfifo;
+ struct coda_dev *dev = ctx-dev;
+ u32 wr_ptr;
+
+ wr_ptr = ctx-bitstream.paddr + (kfifo-in kfifo-mask);
+ coda_write(dev, wr_ptr, CODA_REG_BIT_WR_PTR(ctx-reg_idx));
+}
+
+static int coda_bitstream_queue(struct coda_ctx *ctx, struct vb2_buffer
*src_buf)
+{
+ u32 src_size = vb2_get_plane_payload(src_buf, 0);
+ u32 n;
+
+ n = kfifo_in(ctx-bitstream_fifo, vb2_plane_vaddr(src_buf, 0),
src_size);
+ if (n src_size)
+ return -ENOSPC;
+
+ dma_sync_single_for_device(ctx-dev-plat_dev-dev,
ctx-bitstream.paddr,
+ ctx-bitstream.size, DMA_TO_DEVICE);
+
+ ctx-qsequence++;
+
+ return 0;
+}
+
+static bool coda_bitstream_try_queue(struct coda_ctx *ctx,
+struct vb2_buffer *src_buf)
+{
+ int ret;
+
+ if (coda_get_bitstream_payload(ctx) +
+ vb2_get_plane_payload(src_buf, 0) + 512 = ctx-bitstream.size)
+ return false;
+
+ if (vb2_plane_vaddr(src_buf, 0) == NULL) {
+ v4l2_err(ctx-dev-v4l2_dev, trying to queue empty buffer\n);
+ return true;
+ }
+
+ ret = coda_bitstream_queue(ctx, src_buf);
+ if (ret 0) {
+
[PATCH 6/8] [media] coda: dynamic IRAM setup for decoder
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda.c | 50 +--
1 file changed, 48 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index 1f3bd43..856a93e 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -1212,6 +1212,7 @@ static void coda_setup_iram(struct coda_ctx *ctx)
int ipacdc_size;
int bitram_size;
int dbk_size;
+ int ovl_size;
int mb_width;
int me_size;
int size;
@@ -1273,7 +1274,47 @@ static void coda_setup_iram(struct coda_ctx *ctx)
size -= ipacdc_size;
}
- /* OVL disabled for encoder */
+ /* OVL and BTP disabled for encoder */
+ } else if (ctx-inst_type == CODA_INST_DECODER) {
+ struct coda_q_data *q_data_dst;
+ int mb_height;
+
+ q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
+ mb_width = DIV_ROUND_UP(q_data_dst-width, 16);
+ mb_height = DIV_ROUND_UP(q_data_dst-height, 16);
+
+ dbk_size = round_up(256 * mb_width, 1024);
+ if (size = dbk_size) {
+ iram_info-axi_sram_use |= CODA7_USE_HOST_DBK_ENABLE;
+ iram_info-buf_dbk_y_use = dev-iram_paddr;
+ iram_info-buf_dbk_c_use = dev-iram_paddr +
+ dbk_size / 2;
+ size -= dbk_size;
+ } else {
+ goto out;
+ }
+
+ bitram_size = round_up(128 * mb_width, 1024);
+ if (size = bitram_size) {
+ iram_info-axi_sram_use |= CODA7_USE_HOST_BIT_ENABLE;
+ iram_info-buf_bit_use = iram_info-buf_dbk_c_use +
+dbk_size / 2;
+ size -= bitram_size;
+ } else {
+ goto out;
+ }
+
+ ipacdc_size = round_up(128 * mb_width, 1024);
+ if (size = ipacdc_size) {
+ iram_info-axi_sram_use |= CODA7_USE_HOST_IP_ENABLE;
+ iram_info-buf_ip_ac_dc_use = iram_info-buf_bit_use +
+ bitram_size;
+ size -= ipacdc_size;
+ } else {
+ goto out;
+ }
+
+ ovl_size = round_up(80 * mb_width, 1024);
}
out:
@@ -1300,7 +1341,12 @@ out:
if (dev-devtype-product == CODA_7541) {
/* TODO - Enabling these causes picture errors on CODA7541 */
- if (ctx-inst_type == CODA_INST_ENCODER) {
+ if (ctx-inst_type == CODA_INST_DECODER) {
+ /* fw 1.4.50 */
+ iram_info-axi_sram_use = ~(CODA7_USE_HOST_IP_ENABLE |
+CODA7_USE_IP_ENABLE);
+ } else {
+ /* fw 13.4.29 */
iram_info-axi_sram_use = ~(CODA7_USE_HOST_IP_ENABLE |
CODA7_USE_HOST_DBK_ENABLE |
CODA7_USE_IP_ENABLE |
--
1.8.3.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 8/8] [media] coda: add CODA7541 decoding support
This patch enables decoding of h.264 and mpeg4 streams on CODA7541.
Queued output buffers are immediately copied into the bitstream
ringbuffer. A device_run can be scheduled whenever there is either
enough compressed bitstream data, or the CODA is in stream end mode.
Each successful device_run, data is read from the bitstream ringbuffer
and a frame is decoded into a free internal framebuffer. Depending on
reordering, a possibly previously decoded frame is marked as display
frame, and at the same time the display frame from the previous run
is copied out into a capture buffer by the rotator hardware.
The dequeued capture buffers are counted to send the EOS signal to
userspace with the last frame. When userspace sends the decoder stop
command or enqueues an empty output buffer, the stream end flag is
set to allow decoding the remaining frames in the bitstream
ringbuffer.
The enum_fmt/try_fmt functions return fixed capture buffer sizes
while the output queue is streaming, to allow better autonegotiation
in userspace.
A per-context buffer mutex is used to lock the picture run against
buffer dequeueing: if a job gets queued, then streamoff dequeues
the last buffer, and then device_run is called, bail out. For that
the interrupt handler has to be threaded.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda.c | 785 ++
drivers/media/platform/coda.h | 84 +
2 files changed, 811 insertions(+), 58 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index e8b3708..16f1726 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -29,6 +29,7 @@
#include media/v4l2-ctrls.h
#include media/v4l2-device.h
+#include media/v4l2-event.h
#include media/v4l2-ioctl.h
#include media/v4l2-mem2mem.h
#include media/videobuf2-core.h
@@ -47,9 +48,11 @@
#define CODA_PARA_BUF_SIZE (10 * 1024)
#define CODA_ISRAM_SIZE(2048 * 2)
#define CODADX6_IRAM_SIZE 0xb000
-#define CODA7_IRAM_SIZE0x14000 /* 81920 bytes */
+#define CODA7_IRAM_SIZE0x14000
-#define CODA_MAX_FRAMEBUFFERS 2
+#define CODA7_PS_BUF_SIZE 0x28000
+
+#define CODA_MAX_FRAMEBUFFERS 8
#define MAX_W 8192
#define MAX_H 8192
@@ -178,12 +181,16 @@ struct coda_iram_info {
struct coda_ctx {
struct coda_dev *dev;
+ struct mutexbuffer_mutex;
struct list_headlist;
+ struct work_struct skip_run;
int aborting;
+ int initialized;
int streamon_out;
int streamon_cap;
u32 isequence;
u32 qsequence;
+ u32 osequence;
struct coda_q_data q_data[2];
enum coda_inst_type inst_type;
struct coda_codec *codec;
@@ -193,12 +200,16 @@ struct coda_ctx {
struct v4l2_ctrl_handlerctrls;
struct v4l2_fh fh;
int gopcounter;
+ int runcounter;
charvpu_header[3][64];
int vpu_header_size[3];
struct kfifobitstream_fifo;
struct mutexbitstream_mutex;
struct coda_aux_buf bitstream;
+ boolprescan_failed;
struct coda_aux_buf parabuf;
+ struct coda_aux_buf psbuf;
+ struct coda_aux_buf slicebuf;
struct coda_aux_buf internal_frames[CODA_MAX_FRAMEBUFFERS];
struct coda_aux_buf workbuf;
int num_internal_frames;
@@ -206,6 +217,8 @@ struct coda_ctx {
int reg_idx;
struct coda_iram_info iram_info;
u32 bit_stream_param;
+ u32 frm_dis_flg;
+ int display_idx;
};
static const u8 coda_filler_nal[14] = { 0x00, 0x00, 0x00, 0x01, 0x0c, 0xff,
@@ -257,6 +270,8 @@ static void coda_command_async(struct coda_ctx *ctx, int
cmd)
/* Restore context related registers to CODA */
coda_write(dev, ctx-bit_stream_param,
CODA_REG_BIT_BIT_STREAM_PARAM);
+ coda_write(dev, ctx-frm_dis_flg,
+ CODA_REG_BIT_FRM_DIS_FLG(ctx-reg_idx));
coda_write(dev, ctx-workbuf.paddr, CODA_REG_BIT_WORK_BUF_ADDR);
}
@@ -331,6 +346,8 @@ static struct coda_codec codadx6_codecs[] = {
static struct coda_codec coda7_codecs[] = {
[PATCH 4/8] [media] coda: update CODA7541 to firmware 1.4.50
This patch splits the global workbuf into a global tempbuf and a per-context
workbuf, adds the codec mode aux register, and restores the work buffer
pointer on commands. With the new firmware, there is only a single set of
read/write pointers which need to be restored between context switches.
This allows more than four active contexts at the same time.
All auxiliary buffers are now allocated through a helper function to avoid
code duplication.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda.c | 235 +++---
drivers/media/platform/coda.h | 9 ++
2 files changed, 182 insertions(+), 62 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index 6d76f1d..28ee3f7 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -41,7 +41,8 @@
#define CODA_FMO_BUF_SIZE 32
#define CODADX6_WORK_BUF_SIZE (288 * 1024 + CODA_FMO_BUF_SIZE * 8 * 1024)
-#define CODA7_WORK_BUF_SIZE(512 * 1024 + CODA_FMO_BUF_SIZE * 8 * 1024)
+#define CODA7_WORK_BUF_SIZE(128 * 1024)
+#define CODA7_TEMP_BUF_SIZE(304 * 1024)
#define CODA_PARA_BUF_SIZE (10 * 1024)
#define CODA_ISRAM_SIZE(2048 * 2)
#define CODADX6_IRAM_SIZE 0xb000
@@ -129,6 +130,7 @@ struct coda_dev {
struct clk *clk_ahb;
struct coda_aux_buf codebuf;
+ struct coda_aux_buf tempbuf;
struct coda_aux_buf workbuf;
struct gen_pool *iram_pool;
long unsigned int iram_vaddr;
@@ -153,6 +155,7 @@ struct coda_params {
u8 mpeg4_inter_qp;
u8 gop_size;
int codec_mode;
+ int codec_mode_aux;
enum v4l2_mpeg_video_multi_slice_mode slice_mode;
u32 framerate;
u16 bitrate;
@@ -192,8 +195,10 @@ struct coda_ctx {
int vpu_header_size[3];
struct coda_aux_buf parabuf;
struct coda_aux_buf internal_frames[CODA_MAX_FRAMEBUFFERS];
+ struct coda_aux_buf workbuf;
int num_internal_frames;
int idx;
+ int reg_idx;
struct coda_iram_info iram_info;
};
@@ -241,10 +246,18 @@ static int coda_wait_timeout(struct coda_dev *dev)
static void coda_command_async(struct coda_ctx *ctx, int cmd)
{
struct coda_dev *dev = ctx-dev;
+
+ if (dev-devtype-product == CODA_7541) {
+ /* Restore context related registers to CODA */
+ coda_write(dev, ctx-workbuf.paddr, CODA_REG_BIT_WORK_BUF_ADDR);
+ }
+
coda_write(dev, CODA_REG_BIT_BUSY_FLAG, CODA_REG_BIT_BUSY);
coda_write(dev, ctx-idx, CODA_REG_BIT_RUN_INDEX);
coda_write(dev, ctx-params.codec_mode, CODA_REG_BIT_RUN_COD_STD);
+ coda_write(dev, ctx-params.codec_mode_aux, CODA7_REG_BIT_RUN_AUX_STD);
+
coda_write(dev, cmd, CODA_REG_BIT_RUN_COMMAND);
}
@@ -959,21 +972,6 @@ static void coda_wait_finish(struct vb2_queue *q)
coda_lock(ctx);
}
-static void coda_free_framebuffers(struct coda_ctx *ctx)
-{
- int i;
-
- for (i = 0; i CODA_MAX_FRAMEBUFFERS; i++) {
- if (ctx-internal_frames[i].vaddr) {
- dma_free_coherent(ctx-dev-plat_dev-dev,
- ctx-internal_frames[i].size,
- ctx-internal_frames[i].vaddr,
- ctx-internal_frames[i].paddr);
- ctx-internal_frames[i].vaddr = NULL;
- }
- }
-}
-
static void coda_parabuf_write(struct coda_ctx *ctx, int index, u32 value)
{
struct coda_dev *dev = ctx-dev;
@@ -985,28 +983,69 @@ static void coda_parabuf_write(struct coda_ctx *ctx, int
index, u32 value)
p[index ^ 1] = value;
}
+static int coda_alloc_aux_buf(struct coda_dev *dev,
+ struct coda_aux_buf *buf, size_t size)
+{
+ buf-vaddr = dma_alloc_coherent(dev-plat_dev-dev, size, buf-paddr,
+ GFP_KERNEL);
+ if (!buf-vaddr)
+ return -ENOMEM;
+
+ buf-size = size;
+
+ return 0;
+}
+
+static inline int coda_alloc_context_buf(struct coda_ctx *ctx,
+struct coda_aux_buf *buf, size_t size)
+{
+ return coda_alloc_aux_buf(ctx-dev, buf, size);
+}
+
+static void coda_free_aux_buf(struct coda_dev *dev,
+ struct coda_aux_buf *buf)
+{
+ if (buf-vaddr) {
+ dma_free_coherent(dev-plat_dev-dev, buf-size,
+ buf-vaddr, buf-paddr);
+ buf-vaddr = NULL;
+ buf-size = 0;
+ }
+}
+
+static void coda_free_framebuffers(struct coda_ctx
[PATCH 2/8] [media] coda: dynamic IRAM setup for encoder
This sets up IRAM areas used as temporary memory for the different
hardware units depending on the frame size.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda.c | 145 +++---
drivers/media/platform/coda.h | 11 +++-
2 files changed, 146 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index 90f3386..baf0ce8 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -160,6 +160,18 @@ struct coda_params {
u32 slice_max_mb;
};
+struct coda_iram_info {
+ u32 axi_sram_use;
+ phys_addr_t buf_bit_use;
+ phys_addr_t buf_ip_ac_dc_use;
+ phys_addr_t buf_dbk_y_use;
+ phys_addr_t buf_dbk_c_use;
+ phys_addr_t buf_ovl_use;
+ phys_addr_t buf_btp_use;
+ phys_addr_t search_ram_paddr;
+ int search_ram_size;
+};
+
struct coda_ctx {
struct coda_dev *dev;
struct list_headlist;
@@ -182,6 +194,7 @@ struct coda_ctx {
struct coda_aux_buf internal_frames[CODA_MAX_FRAMEBUFFERS];
int num_internal_frames;
int idx;
+ struct coda_iram_info iram_info;
};
static const u8 coda_filler_nal[14] = { 0x00, 0x00, 0x00, 0x01, 0x0c, 0xff,
@@ -791,6 +804,10 @@ static void coda_device_run(void *m2m_priv)
CODA7_REG_BIT_AXI_SRAM_USE);
}
+ if (dev-devtype-product != CODA_DX6)
+ coda_write(dev, ctx-iram_info.axi_sram_use,
+ CODA7_REG_BIT_AXI_SRAM_USE);
+
/* 1 second timeout in case CODA locks up */
schedule_delayed_work(dev-timeout, HZ);
@@ -1026,6 +1043,110 @@ static int coda_h264_padding(int size, char *p)
return nal_size;
}
+static void coda_setup_iram(struct coda_ctx *ctx)
+{
+ struct coda_iram_info *iram_info = ctx-iram_info;
+ struct coda_dev *dev = ctx-dev;
+ int ipacdc_size;
+ int bitram_size;
+ int dbk_size;
+ int mb_width;
+ int me_size;
+ int size;
+
+ memset(iram_info, 0, sizeof(*iram_info));
+ size = dev-iram_size;
+
+ if (dev-devtype-product == CODA_DX6)
+ return;
+
+ if (ctx-inst_type == CODA_INST_ENCODER) {
+ struct coda_q_data *q_data_src;
+
+ q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+ mb_width = DIV_ROUND_UP(q_data_src-width, 16);
+
+ /* Prioritize in case IRAM is too small for everything */
+ me_size = round_up(round_up(q_data_src-width, 16) * 36 + 2048,
+ 1024);
+ iram_info-search_ram_size = me_size;
+ if (size = iram_info-search_ram_size) {
+ if (dev-devtype-product == CODA_7541)
+ iram_info-axi_sram_use |=
CODA7_USE_HOST_ME_ENABLE;
+ iram_info-search_ram_paddr = dev-iram_paddr;
+ size -= iram_info-search_ram_size;
+ } else {
+ pr_err(IRAM is smaller than the search ram size\n);
+ goto out;
+ }
+
+ /* Only H.264BP and H.263P3 are considered */
+ dbk_size = round_up(128 * mb_width, 1024);
+ if (size = dbk_size) {
+ iram_info-axi_sram_use |= CODA7_USE_HOST_DBK_ENABLE;
+ iram_info-buf_dbk_y_use = dev-iram_paddr +
+ iram_info-search_ram_size;
+ iram_info-buf_dbk_c_use = iram_info-buf_dbk_y_use +
+ dbk_size / 2;
+ size -= dbk_size;
+ } else {
+ goto out;
+ }
+
+ bitram_size = round_up(128 * mb_width, 1024);
+ if (size = bitram_size) {
+ iram_info-axi_sram_use |= CODA7_USE_HOST_BIT_ENABLE;
+ iram_info-buf_bit_use = iram_info-buf_dbk_c_use +
+dbk_size / 2;
+ size -= bitram_size;
+ } else {
+ goto out;
+ }
+
+ ipacdc_size = round_up(128 * mb_width, 1024);
+ if (size = ipacdc_size) {
+ iram_info-axi_sram_use |= CODA7_USE_HOST_IP_ENABLE;
+ iram_info-buf_ip_ac_dc_use = iram_info-buf_bit_use +
+ bitram_size;
+ size -= ipacdc_size;
+ }
+
+ /* OVL disabled for encoder */
+ }
+
+out:
+ switch (dev-devtype-product) {
+ case CODA_DX6:
+
Re: Doing a v4l-utils-1.0.0 release
Hello, On 6/14/13 9:15 AM, Hans de Goede wrote: So how about taking current master and releasing that as a 1.0.0 release ? I'm fine with preparing a 1.0.0 release. But I'm under the impression that the libdvbv5 interface is not polished enough to build a shared library from it. So I'd like to change the autoconf default to false and skip installing the static and shared library. Any objections? Thanks, Gregor -- 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 v4 00/11] media: davinci: vpif driver cleanup
From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch series cleans the VPIF driver, uses devm_* api wherever required and uses module_platform_driver() to simplify the code. This patch series applies on http://git.linuxtv.org/hverkuil/media_tree.git/ shortlog/refs/heads/for-v3.11 and is tested on OMAP-L138 EVM. Changes for v2: 1: Rebased on v3.11 branch of Hans. 2: Dropped the patches which removed headers as mentioned by Laurent. Changes for v3: 1: Splitted the patches logically as mentioned by Laurent. 2: Fixed review comments pointed by Laurent. 3: Included Ack's. Changes for v4: 1: Rebased on v3.11 branch of Hans. 2: Fixed review comments pointed by Laurent and Sergei. 3: Included Ack's. 4: Removed unnecessary loop for IRQ resource. Lad, Prabhakar (11): media: davinci: vpif: remove unwanted header mach/hardware.h and sort the includes alphabetically media: davinci: vpif: Convert to devm_* api media: davinci: vpif: remove unnecessary braces around defines media: davinci: vpif_capture: move the freeing of irq and global variables to remove() media: davinci: vpif_capture: use module_platform_driver() media: davinci: vpif_capture: Convert to devm_* api media: davinci: vpif_capture: remove unnecessary loop for IRQ resource media: davinci: vpif_display: move the freeing of irq and global variables to remove() media: davinci: vpif_display: use module_platform_driver() media: davinci: vpif_display: Convert to devm_* api media: davinci: vpif_display: remove unnecessary loop for IRQ resource drivers/media/platform/davinci/vpif.c | 45 --- drivers/media/platform/davinci/vpif_capture.c | 76 + drivers/media/platform/davinci/vpif_display.c | 65 + 3 files changed, 39 insertions(+), 147 deletions(-) -- 1.7.9.5 -- 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 v4 09/11] media: davinci: vpif_display: use module_platform_driver()
From: Lad, Prabhakar prabhakar.cse...@gmail.com
This patch uses module_platform_driver() to simplify the code.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/davinci/vpif_display.c | 18 +-
1 file changed, 1 insertion(+), 17 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index 371af34..473d1a9 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -1937,20 +1937,4 @@ static __refdata struct platform_driver vpif_driver = {
.remove = vpif_remove,
};
-static __init int vpif_init(void)
-{
- return platform_driver_register(vpif_driver);
-}
-
-/*
- * vpif_cleanup: This function un-registers device and driver to the kernel,
- * frees requested irq handler and de-allocates memory allocated for channel
- * objects.
- */
-static void vpif_cleanup(void)
-{
- platform_driver_unregister(vpif_driver);
-}
-
-module_init(vpif_init);
-module_exit(vpif_cleanup);
+module_platform_driver(vpif_driver);
--
1.7.9.5
--
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 v4 02/11] media: davinci: vpif: Convert to devm_* api
From: Lad, Prabhakar prabhakar.cse...@gmail.com
Use devm_ioremap_resource instead of reques_mem_region()/ioremap().
This ensures more consistent error values and simplifies error paths.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/davinci/vpif.c | 27 ---
1 file changed, 4 insertions(+), 23 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif.c
b/drivers/media/platform/davinci/vpif.c
index 761c825..164c1b7 100644
--- a/drivers/media/platform/davinci/vpif.c
+++ b/drivers/media/platform/davinci/vpif.c
@@ -37,8 +37,6 @@ MODULE_LICENSE(GPL);
#define VPIF_CH2_MAX_MODES (15)
#define VPIF_CH3_MAX_MODES (02)
-static resource_size_t res_len;
-static struct resource *res;
spinlock_t vpif_lock;
void __iomem *vpif_base;
@@ -421,23 +419,12 @@ EXPORT_SYMBOL(vpif_channel_getfid);
static int vpif_probe(struct platform_device *pdev)
{
- int status = 0;
+ static struct resource *res;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENOENT;
-
- res_len = resource_size(res);
-
- res = request_mem_region(res-start, res_len, res-name);
- if (!res)
- return -EBUSY;
-
- vpif_base = ioremap(res-start, res_len);
- if (!vpif_base) {
- status = -EBUSY;
- goto fail;
- }
+ vpif_base = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(vpif_base))
+ return PTR_ERR(vpif_base);
pm_runtime_enable(pdev-dev);
pm_runtime_get(pdev-dev);
@@ -445,17 +432,11 @@ static int vpif_probe(struct platform_device *pdev)
spin_lock_init(vpif_lock);
dev_info(pdev-dev, vpif probe success\n);
return 0;
-
-fail:
- release_mem_region(res-start, res_len);
- return status;
}
static int vpif_remove(struct platform_device *pdev)
{
pm_runtime_disable(pdev-dev);
- iounmap(vpif_base);
- release_mem_region(res-start, res_len);
return 0;
}
--
1.7.9.5
--
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 v4 10/11] media: davinci: vpif_display: Convert to devm_* api
From: Lad, Prabhakar prabhakar.cse...@gmail.com
use devm_request_irq() instead of request_irq(). This ensures
more consistent error values and simplifies error paths.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/davinci/vpif_display.c | 35 +++--
1 file changed, 10 insertions(+), 25 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index 473d1a9..1bf289d 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -1652,15 +1652,14 @@ static __init int vpif_probe(struct platform_device
*pdev)
while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, res_idx))) {
for (i = res-start; i = res-end; i++) {
- if (request_irq(i, vpif_channel_isr, IRQF_SHARED,
- VPIF_Display, (void *)
- (vpif_obj.dev[res_idx]-channel_id))) {
- err = -EBUSY;
- for (j = 0; j i; j++)
- free_irq(j, (void *)
- (vpif_obj.dev[res_idx]-channel_id));
+ err = devm_request_irq(pdev-dev, i, vpif_channel_isr,
+IRQF_SHARED, VPIF_Display,
+(void *)(vpif_obj.dev[res_idx]-
+channel_id));
+ if (err) {
+ err = -EINVAL;
vpif_err(VPIF IRQ request failed\n);
- goto vpif_int_err;
+ goto vpif_unregister;
}
}
res_idx++;
@@ -1678,7 +1677,7 @@ static __init int vpif_probe(struct platform_device *pdev)
video_device_release(ch-video_dev);
}
err = -ENOMEM;
- goto vpif_int_err;
+ goto vpif_unregister;
}
/* Initialize field of video device */
@@ -1812,13 +1811,8 @@ vpif_sd_error:
/* Note: does nothing if ch-video_dev == NULL */
video_device_release(ch-video_dev);
}
-vpif_int_err:
+vpif_unregister:
v4l2_device_unregister(vpif_obj.v4l2_dev);
- for (i = 0; i res_idx; i++) {
- res = platform_get_resource(pdev, IORESOURCE_IRQ, i);
- for (j = res-start; j = res-end; j++)
- free_irq(j, (void *)(vpif_obj.dev[i]-channel_id));
- }
return err;
}
@@ -1829,16 +1823,7 @@ vpif_int_err:
static int vpif_remove(struct platform_device *device)
{
struct channel_obj *ch;
- struct resource *res;
- int irq_num;
- int i = 0;
-
- while ((res = platform_get_resource(device, IORESOURCE_IRQ, i))) {
- for (irq_num = res-start; irq_num = res-end; irq_num++)
- free_irq(irq_num,
-(void *)(vpif_obj.dev[i]-channel_id));
- i++;
- }
+ int i;
v4l2_device_unregister(vpif_obj.v4l2_dev);
--
1.7.9.5
--
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 v4 08/11] media: davinci: vpif_display: move the freeing of irq and global variables to remove()
From: Lad, Prabhakar prabhakar.cse...@gmail.com
Ideally the freeing of irq's and the global variables needs to be
done in the remove() rather than module_exit(), this patch moves
the freeing up of irq's and freeing the memory allocated to channel
objects to remove() callback of struct platform_driver.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
drivers/media/platform/davinci/vpif_display.c | 30 ++---
1 file changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index 6c521f2..371af34 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -1829,10 +1829,20 @@ vpif_int_err:
static int vpif_remove(struct platform_device *device)
{
struct channel_obj *ch;
- int i;
+ struct resource *res;
+ int irq_num;
+ int i = 0;
+
+ while ((res = platform_get_resource(device, IORESOURCE_IRQ, i))) {
+ for (irq_num = res-start; irq_num = res-end; irq_num++)
+ free_irq(irq_num,
+(void *)(vpif_obj.dev[i]-channel_id));
+ i++;
+ }
v4l2_device_unregister(vpif_obj.v4l2_dev);
+ kfree(vpif_obj.sd);
/* un-register device */
for (i = 0; i VPIF_DISPLAY_MAX_DEVICES; i++) {
/* Get the pointer to the channel object */
@@ -1841,6 +1851,7 @@ static int vpif_remove(struct platform_device *device)
video_unregister_device(ch-video_dev);
ch-video_dev = NULL;
+ kfree(vpif_obj.dev[i]);
}
return 0;
@@ -1938,24 +1949,7 @@ static __init int vpif_init(void)
*/
static void vpif_cleanup(void)
{
- struct platform_device *pdev;
- struct resource *res;
- int irq_num;
- int i = 0;
-
- pdev = container_of(vpif_dev, struct platform_device, dev);
-
- while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, i))) {
- for (irq_num = res-start; irq_num = res-end; irq_num++)
- free_irq(irq_num,
-(void *)(vpif_obj.dev[i]-channel_id));
- i++;
- }
-
platform_driver_unregister(vpif_driver);
- kfree(vpif_obj.sd);
- for (i = 0; i VPIF_DISPLAY_MAX_DEVICES; i++)
- kfree(vpif_obj.dev[i]);
}
module_init(vpif_init);
--
1.7.9.5
--
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 v4 03/11] media: davinci: vpif: remove unnecessary braces around defines
From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch removes unnecessary braces around defines. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/platform/davinci/vpif.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c index 164c1b7..cd08e52 100644 --- a/drivers/media/platform/davinci/vpif.c +++ b/drivers/media/platform/davinci/vpif.c @@ -32,10 +32,10 @@ MODULE_DESCRIPTION(TI DaVinci Video Port Interface driver); MODULE_LICENSE(GPL); -#define VPIF_CH0_MAX_MODES (22) -#define VPIF_CH1_MAX_MODES (02) -#define VPIF_CH2_MAX_MODES (15) -#define VPIF_CH3_MAX_MODES (02) +#define VPIF_CH0_MAX_MODES 22 +#define VPIF_CH1_MAX_MODES 2 +#define VPIF_CH2_MAX_MODES 15 +#define VPIF_CH3_MAX_MODES 2 spinlock_t vpif_lock; -- 1.7.9.5 -- 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 v4 11/11] media: davinci: vpif_display: remove unnecessary loop for IRQ resource
From: Lad, Prabhakar prabhakar.cse...@gmail.com
For vpif display driver each IRQ resource contains a single IRQ
so drop the second loop.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
drivers/media/platform/davinci/vpif_display.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_display.c
b/drivers/media/platform/davinci/vpif_display.c
index 1bf289d..e6e5736 100644
--- a/drivers/media/platform/davinci/vpif_display.c
+++ b/drivers/media/platform/davinci/vpif_display.c
@@ -1651,16 +1651,14 @@ static __init int vpif_probe(struct platform_device
*pdev)
}
while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, res_idx))) {
- for (i = res-start; i = res-end; i++) {
- err = devm_request_irq(pdev-dev, i, vpif_channel_isr,
-IRQF_SHARED, VPIF_Display,
-(void *)(vpif_obj.dev[res_idx]-
-channel_id));
- if (err) {
- err = -EINVAL;
- vpif_err(VPIF IRQ request failed\n);
- goto vpif_unregister;
- }
+ err = devm_request_irq(pdev-dev, res-start, vpif_channel_isr,
+ IRQF_SHARED, VPIF_Display,
+ (void *)(vpif_obj.dev[res_idx]-
+ channel_id));
+ if (err) {
+ err = -EINVAL;
+ vpif_err(VPIF IRQ request failed\n);
+ goto vpif_unregister;
}
res_idx++;
}
--
1.7.9.5
--
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 v4 06/11] media: davinci: vpif_capture: Convert to devm_* api
From: Lad, Prabhakar prabhakar.cse...@gmail.com
use devm_request_irq() instead of request_irq(). This ensures
more consistent error values and simplifies error paths.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/davinci/vpif_capture.c | 36 +
1 file changed, 12 insertions(+), 24 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 091c7a4..a4e0eab 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -2016,14 +2016,14 @@ static __init int vpif_probe(struct platform_device
*pdev)
while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, res_idx))) {
for (i = res-start; i = res-end; i++) {
- if (request_irq(i, vpif_channel_isr, IRQF_SHARED,
- VPIF_Capture, (void *)
- (vpif_obj.dev[res_idx]-channel_id))) {
- err = -EBUSY;
- for (j = 0; j i; j++)
- free_irq(j, (void *)
- (vpif_obj.dev[res_idx]-channel_id));
- goto vpif_int_err;
+ err = devm_request_irq(pdev-dev, i, vpif_channel_isr,
+IRQF_SHARED, VPIF_Capture,
+(void *)(vpif_obj.dev[res_idx]-
+channel_id));
+ if (err) {
+ err = -EINVAL;
+ goto vpif_unregister;
+
}
}
res_idx++;
@@ -2040,7 +2040,7 @@ static __init int vpif_probe(struct platform_device *pdev)
video_device_release(ch-video_dev);
}
err = -ENOMEM;
- goto vpif_int_err;
+ goto vpif_unregister;
}
/* Initialize field of video device */
@@ -2141,13 +2141,9 @@ vpif_sd_error:
/* Note: does nothing if ch-video_dev == NULL */
video_device_release(ch-video_dev);
}
-vpif_int_err:
+vpif_unregister:
v4l2_device_unregister(vpif_obj.v4l2_dev);
- for (i = 0; i res_idx; i++) {
- res = platform_get_resource(pdev, IORESOURCE_IRQ, i);
- for (j = res-start; j = res-end; j++)
- free_irq(j, (void *)(vpif_obj.dev[i]-channel_id));
- }
+
return err;
}
@@ -2160,15 +2156,7 @@ vpif_int_err:
static int vpif_remove(struct platform_device *device)
{
struct channel_obj *ch;
- struct resource *res;
- int irq_num, i = 0;
-
- while ((res = platform_get_resource(device, IORESOURCE_IRQ, i))) {
- for (irq_num = res-start; irq_num = res-end; irq_num++)
- free_irq(irq_num,
-(void *)(vpif_obj.dev[i]-channel_id));
- i++;
- }
+ int i;
v4l2_device_unregister(vpif_obj.v4l2_dev);
--
1.7.9.5
--
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 v4 07/11] media: davinci: vpif_capture: remove unnecessary loop for IRQ resource
From: Lad, Prabhakar prabhakar.cse...@gmail.com
For vpif capture driver each IRQ resource contains a single IRQ
so drop the second loop.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
drivers/media/platform/davinci/vpif_capture.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index a4e0eab..5514175 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -2015,16 +2015,13 @@ static __init int vpif_probe(struct platform_device
*pdev)
}
while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, res_idx))) {
- for (i = res-start; i = res-end; i++) {
- err = devm_request_irq(pdev-dev, i, vpif_channel_isr,
-IRQF_SHARED, VPIF_Capture,
-(void *)(vpif_obj.dev[res_idx]-
-channel_id));
- if (err) {
- err = -EINVAL;
- goto vpif_unregister;
-
- }
+ err = devm_request_irq(pdev-dev, res-start, vpif_channel_isr,
+ IRQF_SHARED, VPIF_Capture,
+ (void *)(vpif_obj.dev[res_idx]-
+ channel_id));
+ if (err) {
+ err = -EINVAL;
+ goto vpif_unregister;
}
res_idx++;
}
--
1.7.9.5
--
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 v4 05/11] media: davinci: vpif_capture: use module_platform_driver()
From: Lad, Prabhakar prabhakar.cse...@gmail.com
This patch uses module_platform_driver() to simplify the code.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/davinci/vpif_capture.c | 28 +
1 file changed, 1 insertion(+), 27 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index 7d3c449..091c7a4 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -2270,30 +2270,4 @@ static __refdata struct platform_driver vpif_driver = {
.remove = vpif_remove,
};
-/**
- * vpif_init: initialize the vpif driver
- *
- * This function registers device and driver to the kernel, requests irq
- * handler and allocates memory
- * for channel objects
- */
-static __init int vpif_init(void)
-{
- return platform_driver_register(vpif_driver);
-}
-
-/**
- * vpif_cleanup : This function clean up the vpif capture resources
- *
- * This will un-registers device and driver to the kernel, frees
- * requested irq handler and de-allocates memory allocated for channel
- * objects.
- */
-static void vpif_cleanup(void)
-{
- platform_driver_unregister(vpif_driver);
-}
-
-/* Function for module initialization and cleanup */
-module_init(vpif_init);
-module_exit(vpif_cleanup);
+module_platform_driver(vpif_driver);
--
1.7.9.5
--
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 v4 04/11] media: davinci: vpif_capture: move the freeing of irq and global variables to remove()
From: Lad, Prabhakar prabhakar.cse...@gmail.com
Ideally the freeing of irq's and the global variables needs to be
done in the remove() rather than module_exit(), this patch moves
the freeing up of irq's and freeing the memory allocated to channel
objects to remove() callback of struct platform_driver.
Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
drivers/media/platform/davinci/vpif_capture.c | 29 ++---
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/media/platform/davinci/vpif_capture.c
b/drivers/media/platform/davinci/vpif_capture.c
index d004531..7d3c449 100644
--- a/drivers/media/platform/davinci/vpif_capture.c
+++ b/drivers/media/platform/davinci/vpif_capture.c
@@ -2159,17 +2159,27 @@ vpif_int_err:
*/
static int vpif_remove(struct platform_device *device)
{
- int i;
struct channel_obj *ch;
+ struct resource *res;
+ int irq_num, i = 0;
+
+ while ((res = platform_get_resource(device, IORESOURCE_IRQ, i))) {
+ for (irq_num = res-start; irq_num = res-end; irq_num++)
+ free_irq(irq_num,
+(void *)(vpif_obj.dev[i]-channel_id));
+ i++;
+ }
v4l2_device_unregister(vpif_obj.v4l2_dev);
+ kfree(vpif_obj.sd);
/* un-register device */
for (i = 0; i VPIF_CAPTURE_MAX_DEVICES; i++) {
/* Get the pointer to the channel object */
ch = vpif_obj.dev[i];
/* Unregister video device */
video_unregister_device(ch-video_dev);
+ kfree(vpif_obj.dev[i]);
}
return 0;
}
@@ -2281,24 +2291,7 @@ static __init int vpif_init(void)
*/
static void vpif_cleanup(void)
{
- struct platform_device *pdev;
- struct resource *res;
- int irq_num;
- int i = 0;
-
- pdev = container_of(vpif_dev, struct platform_device, dev);
- while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, i))) {
- for (irq_num = res-start; irq_num = res-end; irq_num++)
- free_irq(irq_num,
-(void *)(vpif_obj.dev[i]-channel_id));
- i++;
- }
-
platform_driver_unregister(vpif_driver);
-
- kfree(vpif_obj.sd);
- for (i = 0; i VPIF_CAPTURE_MAX_DEVICES; i++)
- kfree(vpif_obj.dev[i]);
}
/* Function for module initialization and cleanup */
--
1.7.9.5
--
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 v4 01/11] media: davinci: vpif: remove unwanted header mach/hardware.h and sort the includes alphabetically
From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch removes unwanted header include of mach/hardware.h and along side sorts the header inclusion alphabetically. Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/platform/davinci/vpif.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/media/platform/davinci/vpif.c b/drivers/media/platform/davinci/vpif.c index ea82a8b..761c825 100644 --- a/drivers/media/platform/davinci/vpif.c +++ b/drivers/media/platform/davinci/vpif.c @@ -17,18 +17,16 @@ * GNU General Public License for more details. */ +#include linux/err.h #include linux/init.h +#include linux/io.h +#include linux/kernel.h #include linux/module.h #include linux/platform_device.h -#include linux/spinlock.h -#include linux/kernel.h -#include linux/io.h -#include linux/err.h #include linux/pm_runtime.h +#include linux/spinlock.h #include linux/v4l2-dv-timings.h -#include mach/hardware.h - #include vpif.h MODULE_DESCRIPTION(TI DaVinci Video Port Interface driver); -- 1.7.9.5 -- 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 v11 14/21] V4L2: add temporary clock helpers
Hi Guennadi, Thanks for the patch. On Sat, Jun 15, 2013 at 12:38 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Typical video devices like camera sensors require an external clock source. Many such devices cannot even access their hardware registers without a running clock. These clock sources should be controlled by their consumers. This should be performed, using the generic clock framework. Unfortunately so far only very few systems have been ported to that framework. This patch adds a set of temporary helpers, mimicking the generic clock API, to V4L2. Platforms, adopting the clock API, should switch to using it. Eventually this temporary API should be removed. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com Regards, --Prabhakar Lad -- 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] V4L2: add documentation for V4L2 clock helpers and asynchronous probing
Hi Guennadi, Thanks for the patch. On Mon, Jun 17, 2013 at 11:34 AM, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: Add documentation for the V4L2 clock and V4L2 asynchronous probing APIs to v4l2-framework.txt. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Reviewed-by: Lad, Prabhakar prabhakar.cse...@gmail.com Regards, --Prabhakar Lad -- 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 PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
2013/6/17 Russell King - ARM Linux li...@arm.linux.org.uk
Exactly right. But that is not definitely my point. Could you please see
the below simple example?:
(Presume that CPU and DMA share a buffer and the buffer is mapped with user
space as cachable)
handle1 = drm_gem_fd_to_handle(a dmabuf fd); 1
...
va1 = drm_gem_mmap(handle1);
va2 = drm_gem_mmap(handle2);
va3 = malloc(size);
...
while (conditions) {
memcpy(va1, some data, size);
No!
Well, the first thing to say here is that under the requirements of the
DMA API, the above is immediately invalid, because you're writing to a
buffer which under the terms of the DMA API is currently owned by the
DMA agent, *not* by the CPU. You're supposed to call dma_sync_sg_for_cpu()
before you do that - but how is userspace supposed to know that requirement?
Why should userspace even _have_ to know these requirements of the DMA
API?
It's also entirely possible that drm_gem_fd_to_handle() (which indirectly
causes dma_map_sg() on the buffers scatterlist) followed by mmap'ing it
into userspace is a bug too, as it has the potential to touch caches or
stuff in ways that maybe the DMA or IOMMU may not expect - but I'm not
going to make too big a deal about that, because I don't think we have
anything that picky.
However, the first point above is the most important one, and exposing
the quirks of the DMA API to userland is certainly not a nice thing to be
doing. This needs to be fixed - we can't go and enforce an API which is
deeply embedded within the kernel all the way out to userland.
What we need is something along the lines of:
(a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
or
(b) drm_gem_prime_import() not to call dma_buf_map_attachment() at all.
and for the scatterlist to be mapped for DMA at the point where the DMA
operation is initiated, and unmapped at the point where the DMA operation
is complete.
So no, the problem is not that we need more APIs and code - we need the
existing kernel API fixed so that we don't go exposing userspace to the
requirements of the DMA API. Unless we do that, we're going to end
up with a huge world of pain, where kernel architecture people need to
audit every damned DRM userspace implementation that happens to be run
on their platform, and that's not something arch people really can
afford to do.
Basically, I think the dma_buf stuff needs to be rewritten with the
requirements of the DMA API in the forefront of whosever mind is doing
the rewriting.
Note: the existing stuff does have the nice side effect of being able
to pass buffers which do not have a struct page * associated with them
through the dma_buf API - I think we can still preserve that by having
dma_buf provide a couple of new APIs to do the SG list map/sync/unmap,
but in any case we need to fix the existing API so that:
dma_buf_map_attachment() becomes dma_buf_get_sg()
dma_buf_unmap_attachment() becomes dma_buf_put_sg()
both getting rid of the DMA direction argument, and then we have four
new dma_buf calls:
dma_buf_map_sg()
dma_buf_unmap_sg()
dma_buf_sync_sg_for_cpu()
dma_buf_sync_sg_for_device()
which do the actual sg map/unmap via the DMA API *at the appropriate
time for DMA*.
So, the summary of this is - at the moment, I regard DRM Prime and dmabuf
to be utterly broken in design for architectures such as ARM where the
requirements of the DMA API have to be followed if you're going to have
a happy life.
--
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 PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
2013/6/17 Russell King - ARM Linux li...@arm.linux.org.uk
Exactly right. But that is not definitely my point. Could you please see
the below simple example?:
(Presume that CPU and DMA share a buffer and the buffer is mapped with user
space as cachable)
handle1 = drm_gem_fd_to_handle(a dmabuf fd); 1
...
va1 = drm_gem_mmap(handle1);
va2 = drm_gem_mmap(handle2);
va3 = malloc(size);
...
while (conditions) {
memcpy(va1, some data, size);
No!
Well, the first thing to say here is that under the requirements of the
DMA API, the above is immediately invalid, because you're writing to a
buffer which under the terms of the DMA API is currently owned by the
DMA agent, *not* by the CPU. You're supposed to call dma_sync_sg_for_cpu()
before you do that - but how is userspace supposed to know that requirement?
Why should userspace even _have_ to know these requirements of the DMA
API?
It's also entirely possible that drm_gem_fd_to_handle() (which indirectly
causes dma_map_sg() on the buffers scatterlist) followed by mmap'ing it
into userspace is a bug too, as it has the potential to touch caches or
stuff in ways that maybe the DMA or IOMMU may not expect - but I'm not
going to make too big a deal about that, because I don't think we have
anything that picky.
However, the first point above is the most important one, and exposing
the quirks of the DMA API to userland is certainly not a nice thing to be
doing. This needs to be fixed - we can't go and enforce an API which is
deeply embedded within the kernel all the way out to userland.
What we need is something along the lines of:
(a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
or
(b) drm_gem_prime_import() not to call dma_buf_map_attachment() at all.
and for the scatterlist to be mapped for DMA at the point where the DMA
operation is initiated, and unmapped at the point where the DMA operation
is complete.
So no, the problem is not that we need more APIs and code - we need the
existing kernel API fixed so that we don't go exposing userspace to the
requirements of the DMA API. Unless we do that, we're going to end
up with a huge world of pain, where kernel architecture people need to
audit every damned DRM userspace implementation that happens to be run
on their platform, and that's not something arch people really can
afford to do.
Basically, I think the dma_buf stuff needs to be rewritten with the
requirements of the DMA API in the forefront of whosever mind is doing
the rewriting.
Note: the existing stuff does have the nice side effect of being able
to pass buffers which do not have a struct page * associated with them
through the dma_buf API - I think we can still preserve that by having
dma_buf provide a couple of new APIs to do the SG list map/sync/unmap,
but in any case we need to fix the existing API so that:
dma_buf_map_attachment() becomes dma_buf_get_sg()
dma_buf_unmap_attachment() becomes dma_buf_put_sg()
both getting rid of the DMA direction argument, and then we have four
new dma_buf calls:
dma_buf_map_sg()
dma_buf_unmap_sg()
dma_buf_sync_sg_for_cpu()
dma_buf_sync_sg_for_device()
which do the actual sg map/unmap via the DMA API *at the appropriate
time for DMA*.
So, the summary of this is - at the moment, I regard DRM Prime and dmabuf
to be utterly broken in design for architectures such as ARM where the
requirements of the DMA API have to be followed if you're going to have
a happy life.
An addendum to the above:
I'll also point out that the whole thing of having random buffers mapped
into userspace, and doing DMA on them is _highly_ architecture specific.
I'm told that PARISC is one architecture where this does not work (because
DMA needs to have some kind of congruence factor programmed into it which
can be different between kernel and userspace mappings of the same
physical mappings.
I ran into this when trying to come up with a cross-arch DMA-API mmap API,
and PARISC ended up killing the idea off (the remains of that attempt is
the dma_mmap_* stuff in ARM's asm/dma-mapping.h.) However, this was for
the DMA coherent stuff, not the streaming API, which is what _this_
DMA prime/dma_buf stuff is about.
What I'm saying is think _very_ _carefully_ about userspace having
interleaved access to random DMA buffers. Arguably, DRM should _not_
allow this.
--
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 v2 17/38] [media] platform: Check for ARCH_EXYNOS separately
ARCH_EXYNOS is going to be excluded from PLAT_S5P, so it must be checked separately in Exynos-related Kconfig entries. Cc: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Kamil Debski k.deb...@samsung.com Cc: Tomasz Stanislawski t.stanisl...@samsung.com Cc: Jeongtae Park jtp.p...@samsung.com Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/platform/Kconfig| 6 +++--- drivers/media/platform/exynos4-is/Kconfig | 3 ++- drivers/media/platform/s5p-tv/Kconfig | 2 +- 3 files changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 0494d27..bce695d 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -159,7 +159,7 @@ config VIDEO_MEM2MEM_DEINTERLACE config VIDEO_SAMSUNG_S5P_G2D tristate Samsung S5P and EXYNOS4 G2D 2d graphics accelerator driver - depends on VIDEO_DEV VIDEO_V4L2 PLAT_S5P + depends on VIDEO_DEV VIDEO_V4L2 (PLAT_S5P || ARCH_EXYNOS) select VIDEOBUF2_DMA_CONTIG select V4L2_MEM2MEM_DEV default n @@ -169,7 +169,7 @@ config VIDEO_SAMSUNG_S5P_G2D config VIDEO_SAMSUNG_S5P_JPEG tristate Samsung S5P/Exynos4 JPEG codec driver - depends on VIDEO_DEV VIDEO_V4L2 PLAT_S5P + depends on VIDEO_DEV VIDEO_V4L2 (PLAT_S5P || ARCH_EXYNOS) select VIDEOBUF2_DMA_CONTIG select V4L2_MEM2MEM_DEV ---help--- @@ -177,7 +177,7 @@ config VIDEO_SAMSUNG_S5P_JPEG config VIDEO_SAMSUNG_S5P_MFC tristate Samsung S5P MFC Video Codec - depends on VIDEO_DEV VIDEO_V4L2 PLAT_S5P + depends on VIDEO_DEV VIDEO_V4L2 (PLAT_S5P || ARCH_EXYNOS) select VIDEOBUF2_DMA_CONTIG default n help diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig index 6ff99b5..004fd0b 100644 --- a/drivers/media/platform/exynos4-is/Kconfig +++ b/drivers/media/platform/exynos4-is/Kconfig @@ -1,7 +1,8 @@ config VIDEO_SAMSUNG_EXYNOS4_IS bool Samsung S5P/EXYNOS4 SoC series Camera Subsystem driver - depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API PLAT_S5P PM_RUNTIME + depends on VIDEO_V4L2 VIDEO_V4L2_SUBDEV_API PM_RUNTIME + depends on (PLAT_S5P || ARCH_EXYNOS) help Say Y here to enable camera host interface devices for Samsung S5P and EXYNOS SoC series. diff --git a/drivers/media/platform/s5p-tv/Kconfig b/drivers/media/platform/s5p-tv/Kconfig index 7b659bd..369a4c1 100644 --- a/drivers/media/platform/s5p-tv/Kconfig +++ b/drivers/media/platform/s5p-tv/Kconfig @@ -8,7 +8,7 @@ config VIDEO_SAMSUNG_S5P_TV bool Samsung TV driver for S5P platform - depends on PLAT_S5P PM_RUNTIME + depends on (PLAT_S5P || ARCH_EXYNOS) PM_RUNTIME default n ---help--- Say Y here to enable selecting the TV output devices for -- 1.8.2.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] Documentation: Update driver's directory in video4linux/fimc.txt
Update the documentation with the driver's path changed in commit 56fa1a6a6a7da91e7ece8b01b0ae8adb2926e434 [media] s5p-fimc: Change the driver directory to exynos4-is Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Documentation/video4linux/fimc.txt | 21 +++-- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/Documentation/video4linux/fimc.txt b/Documentation/video4linux/fimc.txt index 25f4d34..e51f1b5 100644 --- a/Documentation/video4linux/fimc.txt +++ b/Documentation/video4linux/fimc.txt @@ -1,6 +1,6 @@ Samsung S5P/EXYNOS4 FIMC driver -Copyright (C) 2012 Samsung Electronics Co., Ltd. +Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd. --- The FIMC (Fully Interactive Mobile Camera) device available in Samsung @@ -10,7 +10,7 @@ data from LCD controller (FIMD) through the SoC internal writeback data path. There are multiple FIMC instances in the SoCs (up to 4), having slightly different capabilities, like pixel alignment constraints, rotator availability, LCD writeback support, etc. The driver is located at -drivers/media/platform/s5p-fimc directory. +drivers/media/platform/exynos4-is directory. 1. Supported SoCs = @@ -36,21 +36,21 @@ Not currently supported: = - media device driver - drivers/media/platform/s5p-fimc/fimc-mdevice.[ch] + drivers/media/platform/exynos4-is/media-dev.[ch] - camera capture video device driver - drivers/media/platform/s5p-fimc/fimc-capture.c + drivers/media/platform/exynos4-is/fimc-capture.c - MIPI-CSI2 receiver subdev - drivers/media/platform/s5p-fimc/mipi-csis.[ch] + drivers/media/platform/exynos4-is/mipi-csis.[ch] - video post-processor (mem-to-mem) - drivers/media/platform/s5p-fimc/fimc-core.c + drivers/media/platform/exynos4-is/fimc-core.c - common files - drivers/media/platform/s5p-fimc/fimc-core.h - drivers/media/platform/s5p-fimc/fimc-reg.h - drivers/media/platform/s5p-fimc/regs-fimc.h + drivers/media/platform/exynos4-is/fimc-core.h + drivers/media/platform/exynos4-is/fimc-reg.h + drivers/media/platform/exynos4-is/regs-fimc.h 4. User space interfaces @@ -143,7 +143,8 @@ or retrieve the information from /dev/media? with help of the media-ctl tool: 6. Platform support === -The machine code (plat-s5p and arch/arm/mach-*) must select following options +The machine code (arch/arm/plat-samsung and arch/arm/mach-*) must select +following options: CONFIG_S5P_DEV_FIMC0 mandatory CONFIG_S5P_DEV_FIMC1 \ -- 1.7.9.5 -- 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 v2 32/38] [media] exynos4-is: Remove check for SOC_EXYNOS4412
Since SOC_EXYNOS4412 Kconfig symbol has been removed, it is enough to check for SOC_EXYNOS4212 for both SoCs from Exynos4x12 series. Cc: linux-media@vger.kernel.org Cc: Mauro Carvalho Chehab mche...@redhat.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Tomasz Figa t.f...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/media/platform/exynos4-is/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig index 004fd0b..0d4fd5c 100644 --- a/drivers/media/platform/exynos4-is/Kconfig +++ b/drivers/media/platform/exynos4-is/Kconfig @@ -33,7 +33,7 @@ config VIDEO_S5P_MIPI_CSIS To compile this driver as a module, choose M here: the module will be called s5p-csis. -if SOC_EXYNOS4212 || SOC_EXYNOS4412 || SOC_EXYNOS5250 +if SOC_EXYNOS4212 || SOC_EXYNOS5250 config VIDEO_EXYNOS_FIMC_LITE tristate EXYNOS FIMC-LITE camera interface driver -- 1.8.2.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] MAINTAINERS: Update S5P/Exynos FIMC driver entry
This change is mainly to update the driver's path changed from drivers/media/platform/s5p-fimc to drivers/media/platform/exynos4-is/. While at it, remove non-existent files rule, move the whole entry to the Samsung drivers section and add the patch tracking system URL. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- MAINTAINERS | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3d7782b..d2c5618 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1153,15 +1153,6 @@ L: linux-media@vger.kernel.org S: Maintained F: drivers/media/platform/s5p-g2d/ -ARM/SAMSUNG S5P SERIES FIMC SUPPORT -M: Kyungmin Park kyungmin.p...@samsung.com -M: Sylwester Nawrocki s.nawro...@samsung.com -L: linux-arm-ker...@lists.infradead.org -L: linux-media@vger.kernel.org -S: Maintained -F: arch/arm/plat-samsung/include/plat/*fimc* -F: drivers/media/platform/s5p-fimc/ - ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT M: Kyungmin Park kyungmin.p...@samsung.com M: Kamil Debski k.deb...@samsung.com @@ -6930,6 +6921,14 @@ F: drivers/regulator/s5m*.c F: drivers/rtc/rtc-sec.c F: include/linux/mfd/samsung/ +SAMSUNG S5P/EXYNOS4 SOC SERIES CAMERA SUBSYSTEM DRIVERS +M: Kyungmin Park kyungmin.p...@samsung.com +M: Sylwester Nawrocki s.nawro...@samsung.com +L: linux-media@vger.kernel.org +Q: https://patchwork.linuxtv.org/project/linux-media/list/ +S: Supported +F: drivers/media/platform/exynos4-is/ + SAMSUNG S3C24XX/S3C64XX SOC SERIES CAMIF DRIVER M: Sylwester Nawrocki sylvester.nawro...@gmail.com L: linux-media@vger.kernel.org -- 1.7.9.5 -- 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 v4 00/11] media: davinci: vpif driver cleanup
Hi Prabhakar, Thank you for the patches. On Monday 17 June 2013 20:50:40 Prabhakar Lad wrote: From: Lad, Prabhakar prabhakar.cse...@gmail.com This patch series cleans the VPIF driver, uses devm_* api wherever required and uses module_platform_driver() to simplify the code. This patch series applies on http://git.linuxtv.org/hverkuil/media_tree.git/ shortlog/refs/heads/for-v3.11 and is tested on OMAP-L138 EVM. Changes for v2: 1: Rebased on v3.11 branch of Hans. 2: Dropped the patches which removed headers as mentioned by Laurent. Changes for v3: 1: Splitted the patches logically as mentioned by Laurent. 2: Fixed review comments pointed by Laurent. 3: Included Ack's. Changes for v4: 1: Rebased on v3.11 branch of Hans. 2: Fixed review comments pointed by Laurent and Sergei. 3: Included Ack's. 4: Removed unnecessary loop for IRQ resource. For the whole series, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Lad, Prabhakar (11): media: davinci: vpif: remove unwanted header mach/hardware.h and sort the includes alphabetically media: davinci: vpif: Convert to devm_* api media: davinci: vpif: remove unnecessary braces around defines media: davinci: vpif_capture: move the freeing of irq and global variables to remove() media: davinci: vpif_capture: use module_platform_driver() media: davinci: vpif_capture: Convert to devm_* api media: davinci: vpif_capture: remove unnecessary loop for IRQ resource media: davinci: vpif_display: move the freeing of irq and global variables to remove() media: davinci: vpif_display: use module_platform_driver() media: davinci: vpif_display: Convert to devm_* api media: davinci: vpif_display: remove unnecessary loop for IRQ resource drivers/media/platform/davinci/vpif.c | 45 --- drivers/media/platform/davinci/vpif_capture.c | 76 +- drivers/media/platform/davinci/vpif_display.c | 65 + 3 files changed, 39 insertions(+), 147 deletions(-) -- 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
[GIT PULL for v3.10-rc7] V4L/DVB fixes
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus For a series of fixes for Kernel 3.10. There are some usual driver fixes (mostly on s5p/exynos playform drivers), plus some fixes at V4L2 core. Thank you! Mauro Latest commit at the branch: af44ad5edd1eb6ca92ed5be48e0004e1f04bf219 [media] soc_camera: error dev remove and v4l2 call The following changes since commit df90e2258950fd631cdbf322c1ee1f22068391aa: Merge branch 'devel-for-v3.10' into v4l_for_linus (2013-04-30 09:01:04 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus for you to fetch changes up to af44ad5edd1eb6ca92ed5be48e0004e1f04bf219: [media] soc_camera: error dev remove and v4l2 call (2013-06-08 21:51:06 -0300) Andrzej Hajda (3): [media] s5p-mfc: separate encoder parameters for h264 and mpeg4 [media] s5p-mfc: v4l2 controls setup routine moved to initialization code [media] s5p-mfc: added missing end-of-lines in debug messages Arnd Bergmann (1): [media] radio-si476x: depend on SND_SOC Arun Kumar K (2): [media] s5p-mfc: Update v6 encoder buffer alloc [media] s5p-mfc: Remove special clock usage in driver Axel Lin (2): [media] s5c73m3: Fix off-by-one valid range checking for fie-index [media] exynos4-is: Fix off-by-one valid range checking for is-config_index Geert Uytterhoeven (1): [media] v4l2: SI476X MFD - Do not use binary constants Hans Verkuil (6): [media] DocBook: media: update codec section, drop obsolete 'suspended' state [media] vpfe-capture.c: remove unused label probe_free_lock [media] DocBook/media/v4l: update version number [media] cx88: fix NULL pointer dereference [media] v4l2-ctrls: V4L2_CTRL_CLASS_FM_RX controls are also valid radio controls [media] v4l2-ioctl: don't print the clips list Hans de Goede (2): [media] pwc: Fix comment wrt lock ordering [media] gspca-sonixb: Adjust hstart on sn9c103 + pas202 John Sheu (1): [media] v4l2: mem2mem: save irq flags correctly Katsuya Matsubara (3): [media] sh_veu: invoke v4l2_m2m_job_finish() even if a job has been aborted [media] sh_veu: keep power supply until the m2m context is released [media] sh_veu: fix the buffer size calculation Lad, Prabhakar (3): [media] media: davinci: vpbe: fix layer availability for NV12 format [media] davinci: vpfe: fix error path in probe [media] drivers/staging: davinci: vpfe: fix dependency for building the driver Philipp Zabel (2): [media] v4l2-mem2mem: add v4l2_m2m_create_bufs helper [media] coda: v4l2-compliance fix: add VIDIOC_CREATE_BUFS support Sachin Kamat (3): [media] exynos4-is: Fix potential null pointer dereference in mipi-csis.c [media] s3c-camif: Fix incorrect variable type [media] s5p-mfc: Add NULL check for allocated buffer Seung-Woo Kim (2): [media] media: vb2: return for polling if a buffer is available [media] media: v4l2-mem2mem: return for polling if a buffer is available Sylwester Nawrocki (6): [media] exynos4-is: Correct fimc-lite compatible property description [media] s5p-mfc: Remove unused s5p_mfc_get_decoded_status_v6() function [media] exynos4-is: Prevent NULL pointer dereference when firmware isn't loaded [media] exynos4-is: Ensure fimc-is clocks are not enabled until properly configured [media] exynos4-is: Fix reported colorspace at FIMC-IS-ISP subdev [media] exynos4-is: Remove sysreg clock handling Wei Yongjun (1): [media] davinci: vpfe: fix error return code in vpfe_probe() Wenbing Wang (1): [media] soc_camera: error dev remove and v4l2 call Xiong Zhou (1): [media] staging/solo6x10: select the desired font Documentation/DocBook/media/v4l/dev-codec.xml | 35 + Documentation/DocBook/media/v4l/v4l2.xml | 2 +- .../devicetree/bindings/media/exynos-fimc-lite.txt | 2 +- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 2 +- drivers/media/pci/cx88/cx88-alsa.c | 7 +- drivers/media/pci/cx88/cx88-video.c| 8 +-- drivers/media/platform/coda.c | 9 +++ drivers/media/platform/davinci/vpbe_display.c | 15 drivers/media/platform/davinci/vpfe_capture.c | 3 +- drivers/media/platform/exynos4-is/fimc-is-regs.c | 2 +- drivers/media/platform/exynos4-is/fimc-is.c| 22 +++--- drivers/media/platform/exynos4-is/fimc-is.h| 1 - drivers/media/platform/exynos4-is/fimc-isp.c | 4 +- drivers/media/platform/exynos4-is/mipi-csis.c | 2 +- drivers/media/platform/s3c-camif/camif-core.h | 2 +- drivers/media/platform/s5p-mfc/s5p_mfc.c | 8 +-- drivers/media/platform/s5p-mfc/s5p_mfc_common.h| 6 +-
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Mon Jun 17 19:00:22 CEST 2013 git branch: test git hash: 3080f8c77f277eb87397d639581ebea859f9ea41 gcc version:i686-linux-gcc (GCC) 4.8.0 host hardware: x86_64 host os:3.8-3.slh.2-amd64 linux-git-arm-at91: ERRORS linux-git-arm-davinci: OK linux-git-arm-exynos: ERRORS linux-git-arm-mx: ERRORS linux-git-arm-omap: ERRORS linux-git-arm-omap1: ERRORS linux-git-arm-pxa: ERRORS linux-git-blackfin: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: ERRORS linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.10-rc1-i686: WARNINGS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-2.6.31.14-x86_64: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.10-rc1-x86_64: WARNINGS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS apps: WARNINGS spec-git: OK 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 Media Infrastructure API from this daily build 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: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Tue, Jun 18, 2013 at 02:19:04AM +0900, Inki Dae wrote:
It seems like that all pages of the scatterlist should be mapped with
DMA every time DMA operation is started (or drm_xxx_set_src_dma_buffer
function call), and the pages should be unmapped from DMA again every
time DMA operation is completed: internally, including each cache
operation.
Correct.
Isn't that big overhead?
Yes, if you _have_ to do a cache operation to ensure that the DMA agent
can see the data the CPU has written.
And If there is no problem, we should accept such overhead?
If there is no problem then why are we discussing this and why do we need
this API extension? :)
Actually, drm_gem_fd_to_handle() includes to map a
given dmabuf with iommu table (just logical data) of the DMA. And then, the
device address (or iova) already mapped will be set to buffer register of
the DMA with drm_xxx_set_src/dst_dma_buffer(handle1, ...) call.
Consider this with a PIPT cache:
dma_map_sg()- at this point, the kernel addresses of these
buffers are cleaned and invalidated for the DMA
userspace writes to the buffer, the data sits in the CPU cache
Because the cache is PIPT, this data becomes visible to the
kernel as well.
DMA is started, and it writes to the buffer
Now, at this point, which is the correct data? The data physically in the
RAM which the DMA has written, or the data in the CPU cache. It may
the answer is - they both are, and the loss of either can be a potential
data corruption issue - there is no way to tell which data should be
kept but the system is in an inconsistent state and _one_ of them will
have to be discarded.
dma_unmap_sg() - at this point, the kernel addresses of the
buffers are _invalidated_ and any data in those
cache lines is discarded
Which also means that the data in userspace will also be discarded with
PIPT caches.
This is precisely why we have buffer rules associated with the DMA API,
which are these:
dma_map_sg()
- the buffer transfers ownership from the CPU to the DMA agent.
- the CPU may not alter the buffer in any way.
while (cpu_wants_access) {
dma_sync_sg_for_cpu()
- the buffer transfers ownership from the DMA to the CPU.
- the DMA may not alter the buffer in any way.
dma_sync_sg_for_device()
- the buffer transfers ownership from the CPU to the DMA
- the CPU may not alter the buffer in any way.
}
dma_unmap_sg()
- the buffer transfers ownership from the DMA to the CPU.
- the DMA may not alter the buffer in any way.
Any violation of that is likely to lead to data corruption. Now, some
may say that the DMA API is only about the kernel mapping. Yes it is,
because it takes no regard what so ever about what happens with the
userspace mappings. This is absolutely true when you have VIVT or
aliasing VIPT caches.
Now consider that with a PIPT cache, or a non-aliasing VIPT cache (which
is exactly the same behaviourally from this aspect) any modification of
a userspace mapping is precisely the same as modifying the kernel space
mapping - and what you find is that the above rules end up _inherently_
applying to the userspace mappings as well.
In other words, userspace applications which have mapped the buffers
must _also_ respect these rules.
And there's no way in hell that I'd ever trust userspace to get this
anywhere near right, and I *really* do not like these kinds of internal
kernel API rules being exposed to userspace.
And so the idea that userspace should be allowed to setup DMA transfers
via set source buffer, set destination buffer calls into an API is
just plain rediculous. No, userspace should be allowed to ask for
please copy from buffer X to buffer Y using this transform.
Also remember that drm_xxx_set_src/dst_dma_buffer() would have to
deal with the DRM object IDs for the buffer, and not the actual buffer
information themselves - that is kept within the kernel, so the kernel
knows what's happening.
--
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] V4L2: add documentation for V4L2 clock helpers and asynchronous probing
Hi Guennadi, Thank you for the patch. Overall it looks pretty good, please see below for some small comments. If you've been wondering why your stock of comas is so low, wonder no more: I've found them :-D On Monday 17 June 2013 08:04:10 Guennadi Liakhovetski wrote: Add documentation for the V4L2 clock and V4L2 asynchronous probing APIs to v4l2-framework.txt. Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Hopefully we can commit the actual patches now, while we refine the documentation. Documentation/video4linux/v4l2-framework.txt | 62 ++- 1 files changed, 60 insertions(+), 2 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index a300b28..159a83a 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -326,8 +326,27 @@ that width, height and the media bus pixel code are equal on both source and sink of the link. Subdev drivers are also free to use this function to perform the checks mentioned above in addition to their own checks. -A device (bridge) driver needs to register the v4l2_subdev with the -v4l2_device: +There are currently two ways to register subdevices with the V4L2 core. The +first (traditional) possibility is to have subdevices registered by bridge +drivers. This can be done, when the bridge driver has the complete s/done, /done/ +information about subdevices, connected to it and knows exactly when to s/subdevices,/subdevices/ +register them. This is typically the case for internal subdevices, like +video data processing units within SoCs or complex pluggable boards, +camera sensors in USB cameras or connected to SoCs, which pass information +about them to bridge drivers, usually in their platform data. + +There are however also situations, where subdevices have to be registered s/situations,/situations/ +asynchronously to bridge devices. An example of such a configuration is +Device Tree based systems, on which information about subdevices is made s/systems,/systems/ +available to the system indpendently from the bridge devices, e.g. when s/indpendently/independently/ +subdevices are defined in DT as I2C device nodes. The API, used in this s/API,/API/ +second case is described further below. + +Using one or the other registration method only affects the probing +process, the run-time bridge-subdevice interaction is in both cases the same. + +In the synchronous case a device (bridge) driver needs to register the +v4l2_subdev with the v4l2_device: int err = v4l2_device_register_subdev(v4l2_dev, sd); @@ -394,6 +413,25 @@ controlled through GPIO pins. This distinction is only relevant when setting up the device, but once the subdev is registered it is completely transparent. +In the asynchronous case subdevices register themselves using the +v4l2_async_register_subdev() function. Unregistration is performed, using s/performed,/performed/ +the v4l2_async_unregister_subdev() call. Subdevices registered this way +are stored on a global list of subdevices, ready to be picked up by bridge s/on/in/ +drivers. + +Bridge drivers in turn have to register a notifier object with an array of +subdevice descriptors, that the bridge device needs for its operation. This s/descriptors,/descriptors/ +is performed using the v4l2_async_notifier_register() call. To unregister +the notifier the driver has to call v4l2_async_notifier_unregister(). The +former of the two functions takes two arguments: a pointer to struct +v4l2_device and a pointer to struct v4l2_async_notifier. The latter +contains a pointer to an array of pointers to subdevice descriptors of +type struct v4l2_async_subdev type. Isn't it the other way around ? +The V4L2 core will then use these descriptors to match asynchronously +registered subdevices to them. If a match is detected the .bound() notifier +callback is called. After all subdevices have been located the .complete() +callback is called. When a subdevice is removed from the system the +.unbind() method is called. All three callbacks are optional. + + V4L2 sub-device userspace API - @@ -1061,3 +1099,23 @@ available event type is 'class base + 1'. An example on how the V4L2 events may be used can be found in the OMAP 3 ISP driver (drivers/media/platform/omap3isp). + + +V4L2 clocks +--- + +Many subdevices, like camera sensors, TV decoders and encoders, need a +clock signal to be supplied by the system. Often this clock is supplied by +the respective bridge device. The Linux kernel provides a Common Clock +Framework for this purpose, however, it is not (yet) available on all +architectures. Besides, the nature of the multi-functional (clock, data + +synchronisation, I2C control) connection of subdevices to the system might +impose special requirements on the
Re: [REVIEWv2 PATCH 08/12] f_uvc: add v4l2_device and replace parent with v4l2_dev
Hi Hans,
Thanks for the patch.
On Wednesday 12 June 2013 17:00:58 Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
This driver did not yet support struct v4l2_device, so add it. This
make it possible to replace the deprecated parent field with the
v4l2_dev field, allowing the eventual removal of the parent field.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/usb/gadget/f_uvc.c |9 -
drivers/usb/gadget/uvc.h |2 ++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/f_uvc.c b/drivers/usb/gadget/f_uvc.c
index 38dcedd..1d06567 100644
--- a/drivers/usb/gadget/f_uvc.c
+++ b/drivers/usb/gadget/f_uvc.c
@@ -413,7 +413,7 @@ uvc_register_video(struct uvc_device *uvc)
if (video == NULL)
return -ENOMEM;
- video-parent = cdev-gadget-dev;
+ video-v4l2_dev = uvc-v4l2_dev;
video-fops = uvc_v4l2_fops;
video-release = video_device_release;
strlcpy(video-name, cdev-gadget-name, sizeof(video-name));
@@ -570,6 +570,7 @@ uvc_function_unbind(struct usb_configuration *c, struct
usb_function *f) INFO(cdev, uvc_function_unbind\n);
video_unregister_device(uvc-vdev);
+ v4l2_device_unregister(uvc-v4l2_dev);
uvc-control_ep-driver_data = NULL;
uvc-video.ep-driver_data = NULL;
@@ -697,6 +698,11 @@ uvc_function_bind(struct usb_configuration *c, struct
usb_function *f) if ((ret = usb_function_deactivate(f)) 0)
goto error;
+ if (v4l2_device_register(cdev-gadget-dev, uvc-v4l2_dev)) {
+ printk(KERN_INFO v4l2_device_register failed\n);
+ goto error;
+ }
+
/* Initialise video. */
ret = uvc_video_init(uvc-video);
if (ret 0)
@@ -712,6 +718,7 @@ uvc_function_bind(struct usb_configuration *c, struct
usb_function *f) return 0;
error:
+ v4l2_device_unregister(uvc-v4l2_dev);
if (uvc-vdev)
video_device_release(uvc-vdev);
diff --git a/drivers/usb/gadget/uvc.h b/drivers/usb/gadget/uvc.h
index 817e9e1..7a9111d 100644
--- a/drivers/usb/gadget/uvc.h
+++ b/drivers/usb/gadget/uvc.h
@@ -57,6 +57,7 @@ struct uvc_event
#include linux/videodev2.h
#include linux/version.h
#include media/v4l2-fh.h
+#include media/v4l2-device.h
#include uvc_queue.h
@@ -145,6 +146,7 @@ enum uvc_state
struct uvc_device
{
struct video_device *vdev;
+ struct v4l2_device v4l2_dev;
enum uvc_state state;
struct usb_function func;
struct uvc_video video;
--
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: [REVIEWv2 PATCH 12/12] v4l2-framework: update documentation
Hi Hans, Thanks for the patch. On Wednesday 12 June 2013 17:01:02 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com 'parent' was renamed to 'dev_parent'. Clarify how/when this should be used. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com with a small comment below. --- Documentation/video4linux/v4l2-framework.txt | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 24353ec..3944d5c 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -574,9 +574,13 @@ of the video device exits. The default video_device_release() callback just calls kfree to free the allocated memory. +There is also a video_device_release_empty() function that does nothing +(is empty) and can be used if the struct is embedded and there is nothing +to do when it is released. + You should also set these fields: -- v4l2_dev: set to the v4l2_device parent device. +- v4l2_dev: must be set to the v4l2_device parent device. - name: set to something descriptive and unique. @@ -613,15 +617,16 @@ You should also set these fields: If you want to have a separate priority state per (group of) device node(s), then you can point it to your own struct v4l2_prio_state. -- parent: you only set this if v4l2_device was registered with NULL as +- dev_parent: you only set this if v4l2_device was registered with NULL as the parent device struct. This only happens in cases where one hardware device has multiple PCI devices that all share the same v4l2_device core. The cx88 driver is an example of this: one core v4l2_device struct, but - it is used by both an raw video PCI device (cx8800) and a MPEG PCI device - (cx8802). Since the v4l2_device cannot be associated with a particular - PCI device it is setup without a parent device. But when the struct - video_device is setup you do know which parent PCI device to use. + it is used by both a raw video PCI device (cx8800) and a MPEG PCI device + (cx8802). Since the v4l2_device cannot be associated with a two PCI s/a two/two/ + devices at the same time it is setup without a parent device. But when + the struct video_device is initialized you *do* know which parent PCI + device to use and so you set dev_device to the correct PCI device. - flags: optional. Set to V4L2_FL_USE_FH_PRIO if you want to let the framework handle the VIDIOC_G/S_PRIORITY ioctls. This requires that you use struct -- 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 3.11] Media entity link handling fixes
Hi Sylwester, A bit late, but for the whole series, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com As discussed privately earlier today, sorry for not having handled the patches myself. I will gather media controller related patches in the future. On Monday 17 June 2013 14:12:18 Sylwester Nawrocki wrote: Hi Mauro, This includes corrections of the media entity links handling and resolves potential issues when media entity drivers are in different kernel modules. It allows to keep all entities that belong to same media graph in correct state, when one of an entity's driver module gets unloaded. The following changes since commit dd8c393b3c39f7ebd9ad69ce50cc836773d512b6: [media] media: i2c: ths7303: make the pdata as a constant pointer (2013-06-13 11:42:17 -0300) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git for-v3.11-2 for you to fetch changes up to 28521e45c4478b7bc083e445573aacb7d174dd35: V4L: Remove all links of the media entity when unregistering subdev (2013-06-17 13:42:22 +0200) Sakari Ailus (2): davinci_vpfe: Clean up media entity after unregistering subdev smiapp: Clean up media entity after unregistering subdev Sylwester Nawrocki (2): media: Add a function removing all links of a media entity V4L: Remove all links of the media entity when unregistering subdev drivers/media/i2c/smiapp/smiapp-core.c |2 +- drivers/media/media-entity.c | 50 + drivers/media/v4l2-core/v4l2-device.c |4 +- drivers/staging/media/davinci_vpfe/dm365_ipipe.c |4 +- drivers/staging/media/davinci_vpfe/dm365_ipipeif.c |4 +- drivers/staging/media/davinci_vpfe/dm365_isif.c|4 +- drivers/staging/media/davinci_vpfe/dm365_resizer.c | 14 +++--- drivers/staging/media/davinci_vpfe/vpfe_video.c|2 +- include/media/media-entity.h |3 ++ 9 files changed, 71 insertions(+), 16 deletions(-) -- 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: [RFC PATCH 2/2] davinci_vpfe: Clean up media entity after unregistering subdev
Hi Sylwester, On Sun, Jun 16, 2013 at 11:16:44PM +0200, Sylwester Nawrocki wrote: Hi, On 06/12/2013 06:44 AM, Prabhakar Lad wrote: On Tue, Jun 11, 2013 at 4:20 PM, Sakari Ailussakari.ai...@iki.fi wrote: media_entity_cleanup() frees the links array which will be accessed by media_entity_remove_links() called by v4l2_device_unregister_subdev(). Signed-off-by: Sakari Ailussakari.ai...@iki.fi Acked-by: Lad, Prabhakarprabhakar.cse...@gmail.com I have added these two patches to my tree for 3.11 (in branch for-v3.11-2). Please let me know if you would like it to be handled differently. This was what I was looking forward to. Thanks! -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.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
[no subject]
Loan Syndicacion Am AFG Guaranty Trust Bank, zu strukturieren wir Kreditlinien treffen Sie unsere Kunden spezifischen geschäftlichen Anforderungen und einen deutlichen Mehrwert für unsere Kunden Unternehmen. eine Division der AFG Finance und Private Bank plc. Wenn Sie erwägen, eine große Akquisition oder ein Großprojekt sind, können Sie brauchen eine erhebliche Menge an Kredit. AFG Guaranty Trust Bank setzen können zusammen das Syndikat, das die gesamte Kredit schnürt für Sie. Als Bank mit internationaler Reichweite, sind wir gekommen, um Darlehen zu identifizieren Syndizierungen als Teil unseres Kerngeschäfts und durch spitzte diese Zeile aggressiv sind wir an einem Punkt, wo wir kommen, um als erkannt haben Hauptakteur in diesem Bereich. öffnen Sie ein Girokonto heute mit einem Minimum Bankguthaben von 500 £ und Getup zu £ 10.000 als Darlehen und auch den Hauch einer Chance und gewann die Sterne Preis von £ 500.000 in die sparen und gewinnen promo in may.aply jetzt. mit dem Folowing Informationen über Rechtsanwalt steven lee das Konto Offizier. FULL NAME; Wohnadresse; E-MAIL-ADRESSE; Telefonnummer; Nächsten KINS; MUTTER MAIDEN NAME; Familienstand; BÜROADRESSE; ALTERNATIVE Telefonnummer; TO @ yahoo.com bar.stevenlee NOTE; ALLE Darlehen sind für 10JAHRE RATE VALID ANGEBOT ENDET BALD SO JETZT HURRY -- 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] mxl111sf: don't redefine pr_err/info/debug
eek... I'd rather merge it than ack it -- why don't I see it in patchwork?
I'll try to merge it tonight or tomorrow.
Cheers,
Mike
On Thu, Jun 13, 2013 at 2:09 AM, Hans Verkuil hverk...@xs4all.nl wrote:
On Thu May 23 2013 08:50:43 Hans Verkuil wrote:
Remove the silly redefines of pr_err/info/debug.
This improves readability and it also gets rid of a bunch of warnings when
compiling this driver for older kernels using the compatibility media_build
system.
Mike,
Can you Ack this?
Thanks,
Hans
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c |8 +--
drivers/media/usb/dvb-usb-v2/mxl111sf.c | 90
-
2 files changed, 45 insertions(+), 53 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
b/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
index ef4c65f..879c529 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
@@ -31,8 +31,6 @@ MODULE_PARM_DESC(debug, set debugging level (1=info
(or-able)).);
if (mxl111sf_tuner_debug) \
mxl_printk(KERN_DEBUG, fmt, ##arg)
-#define err pr_err
-
/*
*/
struct mxl111sf_tuner_state {
@@ -113,7 +111,7 @@ static struct mxl111sf_reg_ctrl_info
*mxl111sf_calc_phy_tune_regs(u32 freq,
filt_bw = 63;
break;
default:
- err(%s: invalid bandwidth setting!, __func__);
+ pr_err(%s: invalid bandwidth setting!, __func__);
return NULL;
}
@@ -304,12 +302,12 @@ static int mxl111sf_tuner_set_params(struct
dvb_frontend *fe)
bw = 8;
break;
default:
- err(%s: bandwidth not set!, __func__);
+ pr_err(%s: bandwidth not set!, __func__);
return -EINVAL;
}
break;
default:
- err(%s: modulation type not supported!, __func__);
+ pr_err(%s: modulation type not supported!, __func__);
return -EINVAL;
}
ret = mxl1x1sf_tune_rf(fe, c-frequency, bw);
diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
index efdcb15..e97964e 100644
--- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
+++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
@@ -52,12 +52,6 @@ MODULE_PARM_DESC(rfswitch, force rf switch position
(0=auto, 1=ext, 2=int).);
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
-#define deb_info pr_debug
-#define deb_reg pr_debug
-#define deb_adv pr_debug
-#define err pr_err
-#define info pr_info
-
int mxl111sf_ctrl_msg(struct dvb_usb_device *d,
u8 cmd, u8 *wbuf, int wlen, u8 *rbuf, int rlen)
{
@@ -65,7 +59,7 @@ int mxl111sf_ctrl_msg(struct dvb_usb_device *d,
int ret;
u8 sndbuf[1+wlen];
- deb_adv(%s(wlen = %d, rlen = %d)\n, __func__, wlen, rlen);
+ pr_debug(%s(wlen = %d, rlen = %d)\n, __func__, wlen, rlen);
memset(sndbuf, 0, 1+wlen);
@@ -98,12 +92,12 @@ int mxl111sf_read_reg(struct mxl111sf_state *state, u8
addr, u8 *data)
if (buf[0] == addr)
*data = buf[1];
else {
- err(invalid response reading reg: 0x%02x != 0x%02x, 0x%02x,
+ pr_err(invalid response reading reg: 0x%02x != 0x%02x,
0x%02x,
addr, buf[0], buf[1]);
ret = -EINVAL;
}
- deb_reg(R: (0x%02x, 0x%02x)\n, addr, *data);
+ pr_debug(R: (0x%02x, 0x%02x)\n, addr, *data);
fail:
return ret;
}
@@ -113,11 +107,11 @@ int mxl111sf_write_reg(struct mxl111sf_state *state,
u8 addr, u8 data)
u8 buf[] = { addr, data };
int ret;
- deb_reg(W: (0x%02x, 0x%02x)\n, addr, data);
+ pr_debug(W: (0x%02x, 0x%02x)\n, addr, data);
ret = mxl111sf_ctrl_msg(state-d, MXL_CMD_REG_WRITE, buf, 2, NULL, 0);
if (mxl_fail(ret))
- err(error writing reg: 0x%02x, val: 0x%02x, addr, data);
+ pr_err(error writing reg: 0x%02x, val: 0x%02x, addr, data);
return ret;
}
@@ -134,7 +128,7 @@ int mxl111sf_write_reg_mask(struct mxl111sf_state *state,
#if 1
/* dont know why this usually errors out on the first try */
if (mxl_fail(ret))
- err(error writing addr: 0x%02x, mask: 0x%02x,
+ pr_err(error writing addr: 0x%02x, mask: 0x%02x,
data: 0x%02x, retrying..., addr, mask, data);
ret = mxl111sf_read_reg(state, addr, val);
@@ -167,7 +161,7 @@ int mxl111sf_ctrl_program_regs(struct mxl111sf_state
*state,
ctrl_reg_info[i].mask,
ctrl_reg_info[i].data);
if (mxl_fail(ret)) {
-
[GIT PULL] git://linuxtv.org/mkrufky/tuners r820t
The following changes since commit e049ca5e854263c821a15c0e25fe2ae202c365e1: [media] staging/media: lirc_imon: fix leaks in imon_probe() (2013-06-17 15:52:20 -0300) are available in the git repository at: git://linuxtv.org/mkrufky/tuners r820t for you to fetch changes up to a02dfce109f6dcddf1bfd973f9b3000cd74c3590: r820t: fix imr calibration (2013-06-17 19:32:45 -0400) Gianluca Gennari (3): r820t: remove redundant initializations in r820t_attach() r820t: avoid potential memcpy buffer overflow in shadow_store() r820t: fix imr calibration drivers/media/tuners/r820t.c | 17 +++-- 1 file changed, 7 insertions(+), 10 deletions(-) -- 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
[GIT PULL] git://linuxtv.org/mkrufky/tuners mxl111sf
The following changes since commit e049ca5e854263c821a15c0e25fe2ae202c365e1: [media] staging/media: lirc_imon: fix leaks in imon_probe() (2013-06-17 15:52:20 -0300) are available in the git repository at: git://linuxtv.org/mkrufky/tuners mxl111sf for you to fetch changes up to 0fca4f2af6a176bf4c980643e70c99d11d002094: mxl111sf: don't redefine pr_err/info/debug (2013-06-17 19:56:40 -0400) Hans Verkuil (1): mxl111sf: don't redefine pr_err/info/debug drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c | 8 +++- drivers/media/usb/dvb-usb-v2/mxl111sf.c | 90 ++ 2 files changed, 45 insertions(+), 53 deletions(-) -- 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] MAINTAINERS: Update S5P/Exynos FIMC driver entry
Hi Sylwester, Just a couple of nits inline. On 17 June 2013 22:12, Sylwester Nawrocki s.nawro...@samsung.com wrote: This change is mainly to update the driver's path changed from drivers/media/platform/s5p-fimc to drivers/media/platform/exynos4-is/. While at it, remove non-existent files rule, move the whole entry to the Samsung drivers section and add the patch tracking system URL. How about adding git URL too (of your repo)? Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- MAINTAINERS | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 3d7782b..d2c5618 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1153,15 +1153,6 @@ L: linux-media@vger.kernel.org S: Maintained F: drivers/media/platform/s5p-g2d/ -ARM/SAMSUNG S5P SERIES FIMC SUPPORT -M: Kyungmin Park kyungmin.p...@samsung.com -M: Sylwester Nawrocki s.nawro...@samsung.com -L: linux-arm-ker...@lists.infradead.org -L: linux-media@vger.kernel.org -S: Maintained -F: arch/arm/plat-samsung/include/plat/*fimc* -F: drivers/media/platform/s5p-fimc/ - ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT Probably ARM could be removed from here too and may be other places if they exist just like below entry. M: Kyungmin Park kyungmin.p...@samsung.com M: Kamil Debski k.deb...@samsung.com @@ -6930,6 +6921,14 @@ F: drivers/regulator/s5m*.c F: drivers/rtc/rtc-sec.c F: include/linux/mfd/samsung/ +SAMSUNG S5P/EXYNOS4 SOC SERIES CAMERA SUBSYSTEM DRIVERS +M: Kyungmin Park kyungmin.p...@samsung.com +M: Sylwester Nawrocki s.nawro...@samsung.com +L: linux-media@vger.kernel.org +Q: https://patchwork.linuxtv.org/project/linux-media/list/ +S: Supported +F: drivers/media/platform/exynos4-is/ + Considering alphabetical order (now that ARM is removed), this block should come after SAMSUNG S3C24XX/S3C64XX... SAMSUNG S3C24XX/S3C64XX SOC SERIES CAMIF DRIVER M: Sylwester Nawrocki sylvester.nawro...@gmail.com L: linux-media@vger.kernel.org -- -- With warm regards, Sachin -- 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] Documentation: Update driver's directory in video4linux/fimc.txt
Hi Sylwester, -The machine code (plat-s5p and arch/arm/mach-*) must select following options +The machine code (arch/arm/plat-samsung and arch/arm/mach-*) must select +following options: After the recent platform code cleanup the below entries are not found in arch/arm/mach-* (checked in linux-next). CONFIG_S5P_DEV_FIMC0 mandatory CONFIG_S5P_DEV_FIMC1 \ -- With warm regards, Sachin -- 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 3/6] [media] s5p-mfc: Core support for MFC v7
Hi Kamil, Thank you for the review. #define IS_MFCV6(dev)(dev-variant-version = 0x60 ? 1 : 0) +#define IS_MFCV7(dev)(dev-variant-version = 0x70 ? 1 : 0) According to this, MFC v7 is also detected as MFC v6. Was this intended? Yes this was intentional as most of v7 will be reusing the v6 code and only minor changes are there w.r.t firmware interface. I think that it would be much better to use this in code: if (IS_MFCV6(dev) || IS_MFCV7(dev)) And change the define to detect only single MFC revision: #define IS_MFCV6(dev) (dev-variant-version = 0x60 dev-variant-version 0x70) I kept it like that since the macro IS_MFCV6() is used quite frequently in the driver. Also if MFCv8 comes which is again similar to v6 (not sure about this), then it will add another OR condition to this check. Other possibility I see is to change the name of the check. Although IS_MFCV6_OR_NEWER(dev) seems too long :) How about making it IS_MFCV6_PLUS()? Regards Arun -- 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 -next] [media] coda: fix missing unlock on error in coda_stop_streaming()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
Add the missing unlock before return from function coda_stop_streaming()
in the error handling case.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/media/platform/coda.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
index df4ada88..2c3cd17 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda.c
@@ -1347,6 +1347,7 @@ static int coda_stop_streaming(struct vb2_queue *q)
if (coda_command_sync(ctx, CODA_COMMAND_SEQ_END)) {
v4l2_err(dev-v4l2_dev,
CODA_COMMAND_SEQ_END failed\n);
+ mutex_unlock(dev-coda_mutex);
return -ETIMEDOUT;
}
mutex_unlock(dev-coda_mutex);
--
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 3/6] [media] s5p-mfc: Core support for MFC v7
On 18 June 2013 10:21, Arun Kumar K arunkk.sams...@gmail.com wrote: Hi Kamil, Thank you for the review. #define IS_MFCV6(dev)(dev-variant-version = 0x60 ? 1 : 0) +#define IS_MFCV7(dev)(dev-variant-version = 0x70 ? 1 : 0) According to this, MFC v7 is also detected as MFC v6. Was this intended? Yes this was intentional as most of v7 will be reusing the v6 code and only minor changes are there w.r.t firmware interface. I think that it would be much better to use this in code: if (IS_MFCV6(dev) || IS_MFCV7(dev)) And change the define to detect only single MFC revision: #define IS_MFCV6(dev) (dev-variant-version = 0x60 dev-variant-version 0x70) I kept it like that since the macro IS_MFCV6() is used quite frequently in the driver. Also if MFCv8 comes which is again similar to v6 (not sure about this), then it will add another OR condition to this check. Other possibility I see is to change the name of the check. Although IS_MFCV6_OR_NEWER(dev) seems too long :) How about making it IS_MFCV6_PLUS()? Technically #define IS_MFCV6(dev)(dev-variant-version = 0x60...) means all lower versions are also higher versions. This may not cause much of a problem (other than the macro being a misnomer) as all current higher versions are supersets of lower versions. But this is not guaranteed(?). Hence changing the definition of the macro to (dev-variant-version = 0x60 dev-variant-version 0x70) as Kamil suggested or renaming it to IS_MFCV6_PLUS() makes sense. OTOH, do we really have intermediate version numbers? For e.g. 0x61, 0x72, etc? If not we can make it just: #define IS_MFCV6(dev)(dev-variant-version == 0x60 ? 1 : 0) -- With warm regards, Sachin -- 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 PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
-Original Message-
From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
Sent: Tuesday, June 18, 2013 3:21 AM
To: Inki Dae
Cc: Maarten Lankhorst; linux-fbdev; Kyungmin Park; DRI mailing list; Rob
Clark; myungjoo.ham; YoungJun Cho; Daniel Vetter; linux-arm-
ker...@lists.infradead.org; linux-media@vger.kernel.org
Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
framework
On Tue, Jun 18, 2013 at 02:19:04AM +0900, Inki Dae wrote:
It seems like that all pages of the scatterlist should be mapped with
DMA every time DMA operation is started (or drm_xxx_set_src_dma_buffer
function call), and the pages should be unmapped from DMA again every
time DMA operation is completed: internally, including each cache
operation.
Correct.
Isn't that big overhead?
Yes, if you _have_ to do a cache operation to ensure that the DMA agent
can see the data the CPU has written.
And If there is no problem, we should accept such overhead?
If there is no problem then why are we discussing this and why do we need
this API extension? :)
Ok, another issue regardless of dmabuf-sync. Reasonable to me even though
big overhead. Besides, it seems like that most DRM drivers have same issue.
Therefore, we may need to solve this issue like below:
- do not map a dmabuf with DMA. And just create/update buffer object
of importer.
- map the buffer with DMA every time DMA start or iommu page fault
occurs.
- unmap the buffer from DMA every time DMA operation is completed
With the above approach, cache operation portion of my approach,
dmabuf-sync, can be removed. However, I'm not sure that we really have to
use the above approach with a big overhead. Of course, if we don't use the
above approach then user processes would need to do each cache operation
before DMA operation is started and also after DMA operation is completed in
some cases; user space mapped with physical memory as cachable, and CPU and
DMA share the same buffer.
So I'd like to ask for other DRM maintainers. How do you think about it? it
seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained by
Rob) and GEM CMA helper also have same issue Russell pointed out. I think
not only the above approach but also the performance is very important.
Thanks,
Inki Dae
Actually, drm_gem_fd_to_handle() includes to map a
given dmabuf with iommu table (just logical data) of the DMA. And then,
the
device address (or iova) already mapped will be set to buffer register
of
the DMA with drm_xxx_set_src/dst_dma_buffer(handle1, ...) call.
Consider this with a PIPT cache:
dma_map_sg()- at this point, the kernel addresses of these
buffers are cleaned and invalidated for the DMA
userspace writes to the buffer, the data sits in the CPU cache
Because the cache is PIPT, this data becomes visible to the
kernel as well.
DMA is started, and it writes to the buffer
Now, at this point, which is the correct data? The data physically in the
RAM which the DMA has written, or the data in the CPU cache. It may
the answer is - they both are, and the loss of either can be a potential
data corruption issue - there is no way to tell which data should be
kept but the system is in an inconsistent state and _one_ of them will
have to be discarded.
dma_unmap_sg() - at this point, the kernel addresses of the
buffers are _invalidated_ and any data in those
cache lines is discarded
Which also means that the data in userspace will also be discarded with
PIPT caches.
This is precisely why we have buffer rules associated with the DMA API,
which are these:
dma_map_sg()
- the buffer transfers ownership from the CPU to the DMA agent.
- the CPU may not alter the buffer in any way.
while (cpu_wants_access) {
dma_sync_sg_for_cpu()
- the buffer transfers ownership from the DMA to the CPU.
- the DMA may not alter the buffer in any way.
dma_sync_sg_for_device()
- the buffer transfers ownership from the CPU to the DMA
- the CPU may not alter the buffer in any way.
}
dma_unmap_sg()
- the buffer transfers ownership from the DMA to the CPU.
- the DMA may not alter the buffer in any way.
Any violation of that is likely to lead to data corruption. Now, some
may say that the DMA API is only about the kernel mapping. Yes it is,
because it takes no regard what so ever about what happens with the
userspace mappings. This is absolutely true when you have VIVT or
aliasing VIPT caches.
Now consider that with a PIPT cache, or a non-aliasing VIPT cache (which
is exactly the same behaviourally from this aspect) any modification of
a userspace mapping is precisely the same as modifying the kernel space
mapping - and what
Re: [PATCH 3/6] [media] s5p-mfc: Core support for MFC v7
Hi Sachin, On Tue, Jun 18, 2013 at 10:56 AM, Sachin Kamat sachin.ka...@linaro.org wrote: On 18 June 2013 10:21, Arun Kumar K arunkk.sams...@gmail.com wrote: Hi Kamil, Thank you for the review. #define IS_MFCV6(dev)(dev-variant-version = 0x60 ? 1 : 0) +#define IS_MFCV7(dev)(dev-variant-version = 0x70 ? 1 : 0) According to this, MFC v7 is also detected as MFC v6. Was this intended? Yes this was intentional as most of v7 will be reusing the v6 code and only minor changes are there w.r.t firmware interface. I think that it would be much better to use this in code: if (IS_MFCV6(dev) || IS_MFCV7(dev)) And change the define to detect only single MFC revision: #define IS_MFCV6(dev) (dev-variant-version = 0x60 dev-variant-version 0x70) I kept it like that since the macro IS_MFCV6() is used quite frequently in the driver. Also if MFCv8 comes which is again similar to v6 (not sure about this), then it will add another OR condition to this check. Other possibility I see is to change the name of the check. Although IS_MFCV6_OR_NEWER(dev) seems too long :) How about making it IS_MFCV6_PLUS()? Technically #define IS_MFCV6(dev)(dev-variant-version = 0x60...) means all lower versions are also higher versions. This may not cause much of a problem (other than the macro being a misnomer) as all current higher versions are supersets of lower versions. But this is not guaranteed(?). Till now we havent encountered otherwise and we can only hope that it remains like this :) Hence changing the definition of the macro to (dev-variant-version = 0x60 dev-variant-version 0x70) as Kamil suggested or renaming it to IS_MFCV6_PLUS() makes sense. OTOH, do we really have intermediate version numbers? For e.g. 0x61, 0x72, etc? If not we can make it just: #define IS_MFCV6(dev)(dev-variant-version == 0x60 ? 1 : 0) The v6 version we use is actually v6.5 and v7 is v7.2. In mainline we havent used any FW sub-versions yet. Regards Arun -- 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
