Re: noisy dev_dbg_ratelimited()
On Thu, 16 Aug 2012 22:29:43 +0200 Hin-Tak Leung ht...@users.sourceforge.net wrote: --- On Thu, 16/8/12, Antti Palosaari cr...@iki.fi wrote: Hello Hiroshi On 08/16/2012 10:12 AM, Hiroshi Doyu wrote: Hi Antti, Antti Palosaari cr...@iki.fi wrote @ Thu, 16 Aug 2012 03:11:56 +0200: Hello Hiroshi, I see you have added dev_dbg_ratelimited() recently, commit 6ca045930338485a8cdef117e74372aa1678009d . However it seems to be noisy as expected similar behavior than normal dev_dbg() without a ratelimit. I looked ratelimit.c and there is: printk(KERN_WARNING %s: %d callbacks suppressed\n, func, rs-missed); What it looks my eyes it will print those callbacks suppressed always because KERN_WARNING. Right. Can the following fix the problem? No. That silences dev_dbg_reatelimited() totally. dev_dbg() works as expected printing all the debugs. But when I change it to dev_dbg_reatelimited() all printings are silenced. I tested again locally. With DEBUG, it prints sometimes with inserting ...28916 callbacks suppressed, without DEBUG, it doesn't print anything. This looks the expected behavior. That's probably correct - the patch looks a bit strange... I did not try the patch, but had a quick look at the file and noted that in include/linux/device.h, info (and possibly another level) are treated specially... just thought I should mention this. I may not get your point correctly, but I think that the debug case is different from the others(info, warn, err...etc) because, the others always prints anything, but not debug depends on DEBUG. With DEBUG it's expected to print at least something, and without DEBUG it's expected to print nothing at all. -- 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 1/1] driver-core: Shut up dev_dbg_reatelimited() without DEBUG
dev_dbg_reatelimited() without DEBUG printed 217078 callbacks
suppressed. This shouldn't print anything without DEBUG.
Signed-off-by: Hiroshi Doyu hd...@nvidia.com
Reported-by: Antti Palosaari cr...@iki.fi
---
include/linux/device.h |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index eb945e1..d4dc26e 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -962,9 +962,13 @@ do {
\
dev_level_ratelimited(dev_notice, dev, fmt, ##__VA_ARGS__)
#define dev_info_ratelimited(dev, fmt, ...)\
dev_level_ratelimited(dev_info, dev, fmt, ##__VA_ARGS__)
+#if defined(DEBUG)
#define dev_dbg_ratelimited(dev, fmt, ...) \
dev_level_ratelimited(dev_dbg, dev, fmt, ##__VA_ARGS__)
-
+#else
+#define dev_dbg_ratelimited(dev, fmt, ...) \
+ no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
+#endif
/*
* Stupid hackaround for existing uses of non-printk uses dev_info
*
--
1.7.5.4
--
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-Trivial] [media] s5p-mfc: Add missing braces around sizeof
Silences the following warnings:
WARNING: sizeof *ctx should be sizeof(*ctx)
WARNING: sizeof *dev should be sizeof(*dev)
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index e3e616d..815affe 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -649,7 +649,7 @@ static int s5p_mfc_open(struct file *file)
return -ERESTARTSYS;
dev-num_inst++;/* It is guarded by mfc_mutex in vfd */
/* Allocate memory for context */
- ctx = kzalloc(sizeof *ctx, GFP_KERNEL);
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx) {
mfc_err(Not enough memory\n);
ret = -ENOMEM;
@@ -961,7 +961,7 @@ static int s5p_mfc_probe(struct platform_device *pdev)
int ret;
pr_debug(%s++\n, __func__);
- dev = devm_kzalloc(pdev-dev, sizeof *dev, GFP_KERNEL);
+ dev = devm_kzalloc(pdev-dev, sizeof(*dev), GFP_KERNEL);
if (!dev) {
dev_err(pdev-dev, Not enough memory for MFC device\n);
return -ENOMEM;
--
1.7.4.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-Trivial 1/2] [media] s5p-fimc: Replace asm/* headers with linux/*
Silences the following warning: WARNING: Use #include linux/sizes.h instead of asm/sizes.h Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/media/platform/s5p-fimc/fimc-core.h |2 +- drivers/media/platform/s5p-fimc/fimc-lite.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/s5p-fimc/fimc-core.h b/drivers/media/platform/s5p-fimc/fimc-core.h index 808ccc6..e787f65 100644 --- a/drivers/media/platform/s5p-fimc/fimc-core.h +++ b/drivers/media/platform/s5p-fimc/fimc-core.h @@ -17,7 +17,7 @@ #include linux/types.h #include linux/videodev2.h #include linux/io.h -#include asm/sizes.h +#include linux/sizes.h #include media/media-entity.h #include media/videobuf2-core.h diff --git a/drivers/media/platform/s5p-fimc/fimc-lite.h b/drivers/media/platform/s5p-fimc/fimc-lite.h index 44424ee..8dc3e9b 100644 --- a/drivers/media/platform/s5p-fimc/fimc-lite.h +++ b/drivers/media/platform/s5p-fimc/fimc-lite.h @@ -9,7 +9,7 @@ #ifndef FIMC_LITE_H_ #define FIMC_LITE_H_ -#include asm/sizes.h +#include linux/sizes.h #include linux/io.h #include linux/irqreturn.h #include linux/platform_device.h -- 1.7.4.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-Trivial 2/2] [media] s5p-fimc: Add missing braces around sizeof
Silences the following warning:
WARNING: sizeof *ctx should be sizeof(*ctx)
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
---
drivers/media/platform/s5p-fimc/fimc-capture.c |2 +-
drivers/media/platform/s5p-fimc/fimc-m2m.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/s5p-fimc/fimc-capture.c
b/drivers/media/platform/s5p-fimc/fimc-capture.c
index 8e413dd..5283957 100644
--- a/drivers/media/platform/s5p-fimc/fimc-capture.c
+++ b/drivers/media/platform/s5p-fimc/fimc-capture.c
@@ -1593,7 +1593,7 @@ static int fimc_register_capture_device(struct fimc_dev
*fimc,
struct vb2_queue *q;
int ret = -ENOMEM;
- ctx = kzalloc(sizeof *ctx, GFP_KERNEL);
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx)
return -ENOMEM;
diff --git a/drivers/media/platform/s5p-fimc/fimc-m2m.c
b/drivers/media/platform/s5p-fimc/fimc-m2m.c
index c587011..1b1e564 100644
--- a/drivers/media/platform/s5p-fimc/fimc-m2m.c
+++ b/drivers/media/platform/s5p-fimc/fimc-m2m.c
@@ -661,7 +661,7 @@ static int fimc_m2m_open(struct file *file)
if (fimc-vid_cap.refcnt 0)
goto unlock;
- ctx = kzalloc(sizeof *ctx, GFP_KERNEL);
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
if (!ctx) {
ret = -ENOMEM;
goto unlock;
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] [media] mem2mem_testdev: unlock and return error code properly
Hi Dan,
On Tuesday, August 14, 2012 8:59 AM Dan Carpenter wrote:
We recently added locking to this function, but there was an error path
which accidentally returned holding a lock. Also we returned zero on
failure on some paths instead of the error code.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
Thanks for the patch!
Acked-by: Marek Szyprowski m.szyprow...@samsung.com
---
Applies to linux-next.
diff --git a/drivers/media/video/mem2mem_testdev.c
b/drivers/media/video/mem2mem_testdev.c
index 0aa8c47..0b496f3 100644
--- a/drivers/media/video/mem2mem_testdev.c
+++ b/drivers/media/video/mem2mem_testdev.c
@@ -911,10 +911,9 @@ static int m2mtest_open(struct file *file)
v4l2_ctrl_new_custom(hdl, m2mtest_ctrl_trans_time_msec, NULL);
v4l2_ctrl_new_custom(hdl, m2mtest_ctrl_trans_num_bufs, NULL);
if (hdl-error) {
- int err = hdl-error;
-
+ rc = hdl-error;
v4l2_ctrl_handler_free(hdl);
- return err;
+ goto open_unlock;
}
ctx-fh.ctrl_handler = hdl;
v4l2_ctrl_handler_setup(hdl);
@@ -946,7 +945,7 @@ static int m2mtest_open(struct file *file)
open_unlock:
mutex_unlock(dev-dev_mutex);
- return 0;
+ return rc;
}
static int m2mtest_release(struct file *file)
Best regards
--
Marek Szyprowski
Samsung Poland RD Center
--
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: [RFCv3 PATCH 3/8] v4l2-subdev: add support for the new edid ioctls.
Hi Hans I didnt catch this sentence in the documentation of the API It is not possible to set part of an EDID, it is always all or nothing. . Guess, I have to read the documentation thoroughly before making assumptions. It makes my question irrelevant. Best Regards Soby Mathew On Thu, Aug 16, 2012 at 11:25 PM, Soby Mathew soby.linu...@gmail.com wrote: Hi Hans, For EDID update, it is recommended that the HPD line be toggled after the EDID update is completed. So for the driver to detect the EDID write is complete, probably a field mentioning the EDID write completed would be good, so that the HPD toggling can be done by the driver. Best Regards Soby Mathew clipped -- 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.7] V4L2: add missing pieces to support HDMI et al and add adv7604/ad9389b drivers
Hi Mauro, There have been no comments since RFCv3 of this patch series, so this is the final pull request. RFCv3 is here: http://www.mail-archive.com/linux-media@vger.kernel.org/msg50265.html Changes since RFCv3: Changed the ioctl numbers for the SUBDEV_G/S_EDID ioctls to unused numbers from videodev2.h to prevent potential clashes. Regards, Hans The following changes since commit 88f8472c9fc6c08f5113887471f1f4aabf7b2929: [media] Fix some Makefile rules (2012-08-16 19:55:03 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git hdmi3 for you to fetch changes up to eed20bebd69e227595ccda188826d016a26bb7aa: ad9389b: driver for the Analog Devices AD9389B video encoder. (2012-08-17 09:55:54 +0200) Hans Verkuil (8): v4l2 core: add the missing pieces to support DVI/HDMI/DisplayPort. V4L2 spec: document the new DV controls and ioctls. v4l2-subdev: add support for the new edid ioctls. v4l2-ctrls.c: add support for the new DV controls. v4l2-common: add v4l_match_dv_timings. v4l2-common: add CVT and GTF detection functions. adv7604: driver for the Analog Devices ADV7604 video decoder. ad9389b: driver for the Analog Devices AD9389B video encoder. Documentation/DocBook/media/v4l/biblio.xml| 40 ++ Documentation/DocBook/media/v4l/controls.xml | 161 +++ Documentation/DocBook/media/v4l/v4l2.xml |1 + drivers/media/i2c/Kconfig | 23 + drivers/media/i2c/Makefile|2 + drivers/media/i2c/ad9389b.c | 1328 + drivers/media/i2c/adv7604.c | 1959 +++ drivers/media/v4l2-core/v4l2-common.c | 358 +++ drivers/media/v4l2-core/v4l2-compat-ioctl32.c | 57 +++ drivers/media/v4l2-core/v4l2-ctrls.c | 39 ++ drivers/media/v4l2-core/v4l2-ioctl.c | 13 + drivers/media/v4l2-core/v4l2-subdev.c |6 + include/linux/v4l2-subdev.h | 10 + include/linux/videodev2.h | 23 + include/media/ad9389b.h | 49 ++ include/media/adv7604.h | 153 +++ include/media/v4l2-chip-ident.h |6 + include/media/v4l2-common.h | 13 + include/media/v4l2-subdev.h |2 + 19 files changed, 4243 insertions(+) create mode 100644 drivers/media/i2c/ad9389b.c create mode 100644 drivers/media/i2c/adv7604.c create mode 100644 include/media/ad9389b.h create mode 100644 include/media/adv7604.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
Re: [PATCH-Trivial] [media] s5p-mfc: Add missing braces around sizeof
Hi Sachin, On 08/17/2012 08:22 AM, Sachin Kamat wrote: Silences the following warnings: WARNING: sizeof *ctx should be sizeof(*ctx) WARNING: sizeof *dev should be sizeof(*dev) Signed-off-by: Sachin Kamat sachin.ka...@linaro.org I've added this one to my tree. 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: [PATCH-Trivial 1/2] [media] s5p-fimc: Replace asm/* headers with linux/*
Hi Sachin, On 08/17/2012 08:28 AM, Sachin Kamat wrote: Silences the following warning: WARNING: Use #include linux/sizes.h instead of asm/sizes.h Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Added both to my tree. 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: [PATCH] media: davinci: vpif: add check for NULL handler
Hi Sekhar,
On Friday 17 August 2012 11:07 AM, Sekhar Nori wrote:
On 8/17/2012 10:51 AM, Prabhakar Lad wrote:
Hi Laurent,
Thanks for the review.
On Thursday 16 August 2012 08:43 PM, Laurent Pinchart wrote:
Hi Prabhakar,
Thanks for the patch.
On Thursday 16 August 2012 19:32:00 Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/davinci/vpif_capture.c | 12 +++-
drivers/media/video/davinci/vpif_display.c | 14 --
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c index 266025e..a87b7a5 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -311,12 +311,14 @@ static int vpif_start_streaming(struct vb2_queue *vq,
unsigned int count) }
/* configure 1 or 2 channel mode */
- ret = vpif_config_data-setup_input_channel_mode
- (vpif-std_info.ycmux_mode);
+ if (vpif_config_data-setup_input_channel_mode) {
+ ret = vpif_config_data-setup_input_channel_mode
+ (vpif-std_info.ycmux_mode);
- if (ret 0) {
- vpif_dbg(1, debug, can't set vpif channel mode\n);
- return ret;
+ if (ret 0) {
+ vpif_dbg(1, debug, can't set vpif channel mode\n);
+ return ret;
+ }
This change looks good to me. However, note that you will need to get rid
of
board code callbacks at some point to implement device tree support. It
would
be worth thinking about how to do so now.
Currently VPIF driver is only used by dm646x, and the handlers for this
in the the board code are not null. This patch is intended for da850
where this handlers will be null.
}
/* Call vpif_set_params function to set the parameters and addresses */
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c index e129c98..1e35f92 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -280,12 +280,14 @@ static int vpif_start_streaming(struct vb2_queue *vq,
unsigned int count) }
/* clock settings */
- ret =
- vpif_config_data-set_clock(ch-vpifparams.std_info.ycmux_mode,
- ch-vpifparams.std_info.hd_sd);
- if (ret 0) {
- vpif_err(can't set clock\n);
- return ret;
+ if (vpif_config_data-set_clock) {
Does the DaVinci platform use the common clock framework ? If so, a better
fix
for this would be to pass a clock name through platform data instead of
using
a callback function.
Currently DaVinci is not using the common clock framework.
Can you ACK this patch?
Yes, DaVinci has not migrated to common clock framework (yet). However,
even without that it should be possible to use clock API in driver code.
Using a callback to enable clocks or even passing the clock name from
platform data would be bypassing an existing framework. Clock name
should be IP specific, so it should be possible to use that in driver.
The callback is not actually dealing with PSC clock's but with system
module registers.
Thx,
--Prabhakar
Thanks,
Sekhar
--
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 0/5] Generic panel framework
Hi, On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote: I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If Oookay, where to start... ;) A few cosmetic/general comments first. I find the file naming a bit strange. You have panel.c, which is the core framework, panel-dbi.c, which is the DBI bus, panel-r61517.c, which is driver for r61517 panel... Perhaps something in this direction (in order): panel-core.c, mipi-dbi-bus.c, panel-r61517.c? And we probably end up with quite a lot of panel drivers, perhaps we should already divide these into separate directories, and then we wouldn't need to prefix each panel with panel- at all. --- Should we aim for DT only solution from the start? DT is the direction we are going, and I feel the older platform data stuff would be deprecated soon. --- Something missing from the intro is how this whole thing should be used. It doesn't help if we know how to turn on the panel, we also need to display something on it =). So I think some kind of diagram/example of how, say, drm would use this thing, and also how the SoC specific DBI bus driver would be done, would clarify things. --- We have discussed face to face about the different hardware setups and scenarios that we should support, but I'll list some of them here for others: 1) We need to support chains of external display chips and panels. A simple example is a chip that takes DSI in, and outputs DPI. In that case we'd have a chain of SoC - DSI2DPI - DPI panel. In final products I think two external devices is the maximum (at least I've never seen three devices in a row), but in theory and in development environments the chain can be arbitrarily long. Also the connections are not necessarily 1-to-1, but a device can take one input while it has two outputs, or a device can take two inputs. Now, I think two external devices is a must requirement. I'm not sure if supporting more is an important requirement. However, if we support two devices, it could be that it's trivial to change the framework to support n devices. 2) Panels and display chips are all but standard. They very often have their own sequences how to do things, have bugs, or implement some feature in slightly different way than some other panel. This is why the panel driver should be able to control or define the way things happen. As an example, Sharp LQ043T1DG01 panel (www.sharpsme.com/download/LQ043T1DG01-SP-072106pdf). It is enabled with the following sequence: - Enable VCC and AVDD regulators - Wait min 50ms - Enable full video stream (pck, syncs, pixels) from SoC - Wait min 0.5ms - Set DISP GPIO, which turns on the display panel Here we could split the enabling of panel to two parts, prepare (in this case starts regulators and waits 50ms) and finish (wait 0.5ms and set DISP GPIO), and the upper layer would start the video stream in between. I realize this could be done with the PANEL_ENABLE_* levels in your RFC, but I don't think the concepts quite match: - PANEL_ENABLE_BLANK level is needed for smart panels, as we need to configure them and send the initial frame at that operating level. With dummy panels there's really no such level, there's just one enable sequence that is always done right away. - I find waiting at the beginning of a function very ugly (what are we waiting for?) and we'd need that when changing the panel to PANEL_ENABLE_ON level. - It's still limited if the panel is a stranger one (see following example). Consider the following theoretical panel enable example, taken to absurd level just to show the general problem: - Enable regulators - Enable video stream - Wait 50ms - Disable video stream - Set enable GPIO - Enable video stream This one would be rather impossible with the upper layer handling the enabling of the video stream. Thus I see that the panel driver needs to control the sequences, and the Sharp panel driver's enable would look something like: regulator_enable(...); sleep(); dpi_enable_video(); sleep(); gpip_set(..); Note that even with this model we still need the PANEL_ENABLE levels you have. --- I'm not sure I understand the panel unload problem you mentioned. Nobody should have direct references to the panel functions, so there shouldn't be any automatic references that would prevent module unloading. So when the user does rmmod panel-mypanel, the panel driver's remove will be called. It'll unregister itself from the panel framework, which causes notifications and the display driver will stop using the panel. After that nobody has pointers to the panel, and it can safely be unloaded. It could cause some locking issues, though. First the panel's remove could take a lock, but the remove sequence would cause the display driver to call disable on the panel, which could again try to take the same lock... Tomi signature.asc Description: This is a digitally signed message part
[GIT PULL FOR v3.7] Aptina sensor drivers patches
Hi Mauro, The following changes since commit 88f8472c9fc6c08f5113887471f1f4aabf7b2929: [media] Fix some Makefile rules (2012-08-16 19:55:03 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git omap3isp-sensors-next Laurent Pinchart (4): v4l2-ctrls: Add v4l2_ctrl_[gs]_ctrl_int64() mt9v032: Provide link frequency control mt9v032: Export horizontal and vertical blanking as V4L2 controls mt9p031: Fix horizontal and vertical blanking configuration Sakari Ailus (1): mt9v032: Provide pixel rate control drivers/media/i2c/mt9p031.c | 12 ++-- drivers/media/i2c/mt9v032.c | 100 - drivers/media/v4l2-core/v4l2-ctrls.c | 135 - include/media/mt9v032.h |3 + include/media/v4l2-ctrls.h | 23 ++ 5 files changed, 209 insertions(+), 64 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: [PATCH] media: davinci: vpif: add check for NULL handler
On 8/17/2012 2:45 PM, Laurent Pinchart wrote:
Hi Prabhakar,
On Friday 17 August 2012 14:02:19 Prabhakar Lad wrote:
On Friday 17 August 2012 11:07 AM, Sekhar Nori wrote:
On 8/17/2012 10:51 AM, Prabhakar Lad wrote:
On Thursday 16 August 2012 08:43 PM, Laurent Pinchart wrote:
On Thursday 16 August 2012 19:32:00 Prabhakar Lad wrote:
From: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/davinci/vpif_capture.c | 12 +++-
drivers/media/video/davinci/vpif_display.c | 14 --
2 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c index 266025e..a87b7a5
100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -311,12 +311,14 @@ static int vpif_start_streaming(struct vb2_queue
*vq,
unsigned int count) }
/* configure 1 or 2 channel mode */
-ret = vpif_config_data-setup_input_channel_mode
-(vpif-std_info.ycmux_mode);
+if (vpif_config_data-setup_input_channel_mode) {
+ret = vpif_config_data-setup_input_channel_mode
+
(vpif-std_info.ycmux_mode);
-if (ret 0) {
-vpif_dbg(1, debug, can't set vpif channel mode\n);
-return ret;
+if (ret 0) {
+vpif_dbg(1, debug, can't set vpif channel
mode\n);
+return ret;
+}
This change looks good to me. However, note that you will need to get
rid of board code callbacks at some point to implement device tree
support. It would be worth thinking about how to do so now.
Currently VPIF driver is only used by dm646x, and the handlers for this
in the the board code are not null. This patch is intended for da850
where this handlers will be null.
}
/* Call vpif_set_params function to set the parameters and
addresses
*/
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c index e129c98..1e35f92
100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -280,12 +280,14 @@ static int vpif_start_streaming(struct vb2_queue
*vq,
unsigned int count) }
/* clock settings */
-ret =
-
vpif_config_data-set_clock(ch-vpifparams.std_info.ycmux_mode,
-ch-vpifparams.std_info.hd_sd);
-if (ret 0) {
-vpif_err(can't set clock\n);
-return ret;
+if (vpif_config_data-set_clock) {
Does the DaVinci platform use the common clock framework ? If so, a
better fix for this would be to pass a clock name through platform data
instead of using a callback function.
Currently DaVinci is not using the common clock framework.
Can you ACK this patch?
Yes, DaVinci has not migrated to common clock framework (yet). However,
even without that it should be possible to use clock API in driver code.
Using a callback to enable clocks or even passing the clock name from
platform data would be bypassing an existing framework. Clock name
should be IP specific, so it should be possible to use that in driver.
The callback is not actually dealing with PSC clock's but with system
module registers.
Good to know. Then you'll have to create an API to expose the system module
registers to drivers.
Yes something like that is needed. Konstantin Baydarov is working on a
MFD driver for a similar module that exists in OMAP world called
control module.
I guess this patch can go in though since it does not add any new
accesses but merely lets the existing function be passed as NULL.
Thanks,
Sekhar
[1] https://patchwork.kernel.org/patch/1236491/
--
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 3/5] video: panel: Add MIPI DBI bus support
Hi Tomi,
Thank you for the review.
On Friday 17 August 2012 12:03:02 Tomi Valkeinen wrote:
On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
+/*
-
+ * Bus operations
+ */
+
+void panel_dbi_write_command(struct panel_dbi_device *dev, unsigned long
cmd) +{
+ dev-bus-ops-write_command(dev-bus, cmd);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_write_command);
+
+void panel_dbi_write_data(struct panel_dbi_device *dev, unsigned long
data) +{
+ dev-bus-ops-write_data(dev-bus, data);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_write_data);
+
+unsigned long panel_dbi_read_data(struct panel_dbi_device *dev)
+{
+ return dev-bus-ops-read_data(dev-bus);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_read_data);
I'm not that familiar with how to implement bus drivers, can you
describe in pseudo code how the SoC's DBI driver would register these?
Sure.
The DBI bus driver first needs to create a panel_dbi_bus_ops instance:
static const struct panel_dbi_bus_ops sh_mobile_lcdc_dbi_bus_ops = {
.write_command = lcdc_dbi_write_command,
.write_data = lcdc_dbi_write_data,
.read_data = lcdc_dbi_read_data,
};
and a panel_dbi_bus instance, usually embedded in its private driver data
structure, and initialize it by setting its dev and ops fields:
ch-dbi_bus.dev = ch-lcdc-dev;
ch-dbi_bus.ops = sh_mobile_lcdc_dbi_bus_ops;
In my current implementation, the panel_dbi_device is created in board code:
static struct panel_dbi_device migor_panel_device = {
.name = r61505,
.id = 0,
.dev= {
.platform_data = migor_panel_info,
},
};
A pointer to that structure is passed to the DBI master driver, which then
registers the device:
panel_dbi_device_register(dbi, ch-dbi_bus);
With a DT-based solution the DBI core will expose a function to register DBI
devices from OF nodes.
The bus itself is currently not registered with the DBI code because there was
no need to.
I think write/read data functions are a bit limited. Shouldn't they be
something like write_data(const u8 *buf, int size) and read_data(u8
*buf, int len)?
Good point. My hardware doesn't support multi-byte read/write operations
directly so I haven't thought about adding those.
Can your hardware group command + data writes in a single operation ? If so we
should expose that at the API level as well.
Is DBI limited to 8-bit data transfers for commands ? Pixels can be
transferred 16-bit at a time, commands might as well. While DCS only specifies
8-bit command/data, DBI panels that are not DCS compliant can use 16-bit
command/data (the R61505 panel, albeit a SYS-80 panel, does so).
Something that's totally missing is configuring the DBI bus. There are a
bunch of timing related values that need to be configured. See
include/video/omapdss.h struct rfbi_timings. While the struct is OMAP
specific, if I recall right most of the values match to the MIPI DBI
spec.
I've left that out currently, and thought about passing that information as
platform data to the DBI bus driver. That's the easiest solution, but I agree
that it's a hack. Panel should expose their timing requirements to the DBI
host. API wise that wouldn't be difficult (we only need to add timing
information to the panel platform data and add a function to the DBI API to
retrieve it), one of challenges might be to express it in a way that's both
universal enough and easy to use for DBI bus drivers.
And this makes me wonder, you use DBI bus for SYS-80 panel. The busses
may look similar in operation, but are they really so similar when you
take into account the timings (and perhaps something else, it's been
years since I read the MIPI DBI spec)?
I'll have to check all the details. SYS-80 is similar to DBI-B, but supports a
wider bus width of 18 bits. I think the interfaces are similar enough to use a
single bus implementation, possibly with quirks and/or options (see SCCB
support in I2C for instance, with flags to ignore acks, force a stop bit
generation, ...). We would duplicate lots of code if we had two different
implementations, and would prevent a DBI panel to be attached to a SYS-80 host
and vice-versa (the format is known to work).
Then there's the start_transfer. This is something I'm not sure what is
the best way to handle it, but the same problems that I mentioned in the
previous post related to enable apply here also. For example, what if
the panel needs to be update in two parts? This is done in Nokia N9.
From panel's perspective, it'd be best to handle it somewhat like this
(although asynchronously, probably):
write_update_area(0, 0, xres, yres / 2);
write_memory_start()
start_pixel_transfer();
wait_transfer_done();
write_update_area(0, yres / 2, xres, yres / 2);
write_memory_start()
start_pixel_transfer();
Why I said I'm
V4L2 API ambiguities: workshop presentation
Hi all, I've prepared a presentation for the upcoming workshop based on my RFC and the comments I received. It is available here: http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.pdf Attendees of the workshop: please review this before the workshop starts. I want to go through this list fairly quickly (particularly slides 1-14) so we can have more time for other topics. 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 3/5] video: panel: Add MIPI DBI bus support
On Fri, 2012-08-17 at 12:02 +0200, Laurent Pinchart wrote:
Hi Tomi,
Thank you for the review.
On Friday 17 August 2012 12:03:02 Tomi Valkeinen wrote:
On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
+/*
-
+ * Bus operations
+ */
+
+void panel_dbi_write_command(struct panel_dbi_device *dev, unsigned long
cmd) +{
+ dev-bus-ops-write_command(dev-bus, cmd);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_write_command);
+
+void panel_dbi_write_data(struct panel_dbi_device *dev, unsigned long
data) +{
+ dev-bus-ops-write_data(dev-bus, data);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_write_data);
+
+unsigned long panel_dbi_read_data(struct panel_dbi_device *dev)
+{
+ return dev-bus-ops-read_data(dev-bus);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_read_data);
I'm not that familiar with how to implement bus drivers, can you
describe in pseudo code how the SoC's DBI driver would register these?
Sure.
The DBI bus driver first needs to create a panel_dbi_bus_ops instance:
static const struct panel_dbi_bus_ops sh_mobile_lcdc_dbi_bus_ops = {
.write_command = lcdc_dbi_write_command,
.write_data = lcdc_dbi_write_data,
.read_data = lcdc_dbi_read_data,
};
Thanks for the example, I think it cleared up things a bit.
As I mentioned earlier, I really think panel is not right here. While
the whole framework may be called panel framework, the bus drivers are
not panels, and we should support external chips also, which are not
panels either.
I think write/read data functions are a bit limited. Shouldn't they be
something like write_data(const u8 *buf, int size) and read_data(u8
*buf, int len)?
Good point. My hardware doesn't support multi-byte read/write operations
directly so I haven't thought about adding those.
OMAP HW doesn't support it either. Well, not quite true, as OMAP's
system DMA could be used to write a buffer to the DBI output. But that's
really the same as doing the write with a a loop with CPU.
But first, the data type should be byte, not unsigned long. How would
you write 8 bits or 16 bits with your API? And second, if the function
takes just u8, you'd need lots of calls to do simple writes.
Can your hardware group command + data writes in a single operation ? If so
we
should expose that at the API level as well.
No it can't. But with DCS that is a common operation, so we could have
some helpers to send command + data with one call. Then again, I'd hope
to have DCS somehow as a separate library, which would then use
DBI/DSI/whatnot to actually send the data.
I'm not quite sure how easy that is because of the differences between
the busses.
Is DBI limited to 8-bit data transfers for commands ? Pixels can be
transferred 16-bit at a time, commands might as well. While DCS only
specifies
8-bit command/data, DBI panels that are not DCS compliant can use 16-bit
command/data (the R61505 panel, albeit a SYS-80 panel, does so).
I have to say I don't remember much about DBI =). Looking at OMAP's
driver, which was made for omap2 and hasn't been much updated since, I
see that there are 4 modes, 8/9/12/16 bits. I think that defines how
many of the parallel data lines are used.
However, I don't think that matters for the panel driver when it wants
to send data. The panel driver should just call dbi_write(buf, buf_len),
and the dbi driver would send the data in the buffer according to the
bus width.
Also note that some chips need to change the bus width on the fly. The
chip used on N800 wants configuration to be done with 8-bits, and pixel
transfers with 16-bits. Who knows why...
So I think this, and generally most of the configuration, should be
somewhat dynamic, so that the panel driver can change them when it
needs.
Something that's totally missing is configuring the DBI bus. There are a
bunch of timing related values that need to be configured. See
include/video/omapdss.h struct rfbi_timings. While the struct is OMAP
specific, if I recall right most of the values match to the MIPI DBI
spec.
I've left that out currently, and thought about passing that information as
platform data to the DBI bus driver. That's the easiest solution, but I agree
that it's a hack. Panel should expose their timing requirements to the DBI
host. API wise that wouldn't be difficult (we only need to add timing
information to the panel platform data and add a function to the DBI API to
retrieve it), one of challenges might be to express it in a way that's both
universal enough and easy to use for DBI bus drivers.
As I pointed above, I think the panel driver shouldn't expose it, but
the panel driver should somehow set it. Or at least allowed to change it
in some manner. This is actually again, the same problem as with enable
and transfer: who controls what's going on.
How I think it should work is something like:
Re: [RFC 0/5] Generic panel framework
Hi Tomi, Thanks a lot for the review. On Friday 17 August 2012 11:38:14 Tomi Valkeinen wrote: On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote: I will appreciate all reviews, comments, criticisms, ideas, remarks, ... If Oookay, where to start... ;) A few cosmetic/general comments first. I find the file naming a bit strange. You have panel.c, which is the core framework, panel-dbi.c, which is the DBI bus, panel-r61517.c, which is driver for r61517 panel... Perhaps something in this direction (in order): panel-core.c, mipi-dbi-bus.c, panel-r61517.c? That looks good to me. I'll then rename panel_dbi_* to mipi_dbi_*. And we probably end up with quite a lot of panel drivers, perhaps we should already divide these into separate directories, and then we wouldn't need to prefix each panel with panel- at all. What kind of directory structure do you have in mind ? Panels are already isolated in drivers/video/panel/ so we could already ditch the panel- prefix in drivers. Would you also create include/video/panel/ ? --- Should we aim for DT only solution from the start? DT is the direction we are going, and I feel the older platform data stuff would be deprecated soon. Don't forget about non-ARM architectures :-/ We need panel drivers for SH as well, which doesn't use DT. I don't think that would be a big issue, a DT- compliant solution should be easy to use through board code and platform data as well. --- Something missing from the intro is how this whole thing should be used. It doesn't help if we know how to turn on the panel, we also need to display something on it =). So I think some kind of diagram/example of how, say, drm would use this thing, and also how the SoC specific DBI bus driver would be done, would clarify things. Of course. If I had all that information already I would have shared it :-) This is really a first RFC, my goal is to make sure that I'm going in the right direction. --- We have discussed face to face about the different hardware setups and scenarios that we should support, but I'll list some of them here for others: 1) We need to support chains of external display chips and panels. A simple example is a chip that takes DSI in, and outputs DPI. In that case we'd have a chain of SoC - DSI2DPI - DPI panel. In final products I think two external devices is the maximum (at least I've never seen three devices in a row), but in theory and in development environments the chain can be arbitrarily long. Also the connections are not necessarily 1-to-1, but a device can take one input while it has two outputs, or a device can take two inputs. Now, I think two external devices is a must requirement. I'm not sure if supporting more is an important requirement. However, if we support two devices, it could be that it's trivial to change the framework to support n devices. 2) Panels and display chips are all but standard. They very often have their own sequences how to do things, have bugs, or implement some feature in slightly different way than some other panel. This is why the panel driver should be able to control or define the way things happen. As an example, Sharp LQ043T1DG01 panel (www.sharpsme.com/download/LQ043T1DG01-SP-072106pdf). It is enabled with the following sequence: - Enable VCC and AVDD regulators - Wait min 50ms - Enable full video stream (pck, syncs, pixels) from SoC - Wait min 0.5ms - Set DISP GPIO, which turns on the display panel Here we could split the enabling of panel to two parts, prepare (in this case starts regulators and waits 50ms) and finish (wait 0.5ms and set DISP GPIO), and the upper layer would start the video stream in between. I realize this could be done with the PANEL_ENABLE_* levels in your RFC, but I don't think the concepts quite match: - PANEL_ENABLE_BLANK level is needed for smart panels, as we need to configure them and send the initial frame at that operating level. With dummy panels there's really no such level, there's just one enable sequence that is always done right away. - I find waiting at the beginning of a function very ugly (what are we waiting for?) and we'd need that when changing the panel to PANEL_ENABLE_ON level. - It's still limited if the panel is a stranger one (see following example). Consider the following theoretical panel enable example, taken to absurd level just to show the general problem: - Enable regulators - Enable video stream - Wait 50ms - Disable video stream - Set enable GPIO - Enable video stream This one would be rather impossible with the upper layer handling the enabling of the video stream. Thus I see that the panel driver needs to control the sequences, and the Sharp panel driver's enable would look something like: regulator_enable(...); sleep(); dpi_enable_video(); sleep(); gpip_set(..); I have to admit I have no better solution to propose at the moment, even if I
gstreamer caps and v4l2
I know this is slightly off topic for this list, but I hope
someone here can help me. I have asked on the gstreamer list,
but it's quite often slow/unreliable.
I'm trying to capture video using v4l2src. The problem is
that my sensor only delivers bayer RGB and I can't figure
out what the caps should be to match. The Linux driver calls
the video mode SGRBG10
When I tried these caps
'video/x-raw-bayer,format=(string)grbg,width=2592,height=1944'
it failed with this assertion:
gst_v4l2src_fixate: assertion `G_VALUE_TYPE (v) == GST_TYPE_LIST' failed
So, I thought I might need a more general string:
'video/x-raw-bayer,format=(string){bggr,grbg,gbrg,rggb},width=2592,height=1944'
which now fails with:
gst_value_get_fourcc: assertion `GST_VALUE_HOLDS_FOURCC (value)' failed
Any ideas how I tell v4l2src the details of my sensor?
Thanks
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--
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 0/5] Generic panel framework
On Fri, 2012-08-17 at 13:10 +0200, Laurent Pinchart wrote: What kind of directory structure do you have in mind ? Panels are already isolated in drivers/video/panel/ so we could already ditch the panel- prefix in drivers. The same directory also contains files for the framework and buses. But perhaps there's no need for additional directories if the amount of non-panel files is small. And you can easily see from the name that they are not panel drivers (e.g. mipi_dbi_bus.c). Would you also create include/video/panel/ ? Perhaps that would be good. Well, having all the files prefixed with panel- is not bad as such, but just feel extra. --- Should we aim for DT only solution from the start? DT is the direction we are going, and I feel the older platform data stuff would be deprecated soon. Don't forget about non-ARM architectures :-/ We need panel drivers for SH as well, which doesn't use DT. I don't think that would be a big issue, a DT- compliant solution should be easy to use through board code and platform data as well. I didn't forget about them as I didn't even think about them ;). I somehow had the impression that other architectures would also use DT, sooner or later. I could be mistaken, though. And true, it's not a big issue to support both DT and non-DT versions, but I've been porting omap stuff for DT and keeping the old platform data stuff also there, and it just feels burdensome. For very simple panels it's easy, but when you've passing lots of parameters the code starts to get longer. This one would be rather impossible with the upper layer handling the enabling of the video stream. Thus I see that the panel driver needs to control the sequences, and the Sharp panel driver's enable would look something like: regulator_enable(...); sleep(); dpi_enable_video(); sleep(); gpip_set(..); I have to admit I have no better solution to propose at the moment, even if I don't really like making the panel control the video stream. When several devices will be present in the chain all of them might have similar annoying requirements, and my feeling is that the resulting code will be quite messy. At the end of the day the only way to really find out is to write an implementation. If we have a chain of devices, and each device uses the bus interface from the previous device in the chain, there shouldn't be a problem. In that model each device can handle the task however is best for it. I think the problems come from the divided control we'll have. I mean, if the panel driver would decide itself what to send to its output, and it would provide the data (think of an i2c device), this would be very simple. And it actually is for things like configuration data etc, but not so for video stream. It could cause some locking issues, though. First the panel's remove could take a lock, but the remove sequence would cause the display driver to call disable on the panel, which could again try to take the same lock... We have two possible ways of calling panel operations, either directly (panel- bus-ops-enable(...)) or indirectly (panel_enable(...)). The former is what V4L2 currently does with subdevs, and requires display drivers to hold a reference to the panel. The later can do without a direct reference only if we use a global lock, which is something I would like to Wouldn't panel_enable() just do the same panel-bus-ops-enable() anyway, and both require a panel reference? I don't see the difference. avoid. A panel-wide lock wouldn't work, as the access function would need to take the lock on a panel instance that can be removed at any time. Can't this be handled with some kind of get/put refcounting? If there's a ref, it can't be removed. Generally about locks, if we define that panel ops may only be called exclusively, does it simplify things? I think we can make such requirements, as there should be only one display framework that handles the panel. Then we don't need locking for things like enable/disable. Of course we need to be careful about things where calls come from outside the display framework. I guess one such thing is rmmod, but if that causes a notification to the display framework, which again handles locking, it shouldn't be a problem. Another thing to be careful about is if the panel internally uses irqs, workqueues, sysfs files or such. In that case it needs to handle locking. Tomi signature.asc Description: This is a digitally signed message part
Preferred setup for development?
I'm looking for information about what distributions people are using, and how they go about testing their code. The reason is, I'm running Ubuntu for my main distribution, and it seems like I'll have to go through a lot of hoops in order to compile and test changes to the kernel. I realize that I could probably just use the media_build tree, and add the changes there. But, I'd prefer to go the same route that the majority of the developers here do. So, my questions are these: 1. Do you use a specific distribution for development, or a roll your own (like Linux from Scratch)? 2. If you use a distribution, which one? 3. Do you do your development on physical computers or on virtual machines (or both)? 4. Do you have a machine that's dedicated to development, or is it one that you use for other things? 5. Do you use a newer computer, or older computer for development? (or both) For anyone using the media_build tree (instead of the media_git tree): Are you able to seamlessly implement changes that are in the media_git tree files to the media_build tree, or do you have to make changes in order to get them to compile? Are your files able to be implemented into the media_git tree seamlessly, or do you have to make changes to get them to compile? If you're able to use the media_build tree, and the changes you make can be implemented in the media_git tree without hassle, I may go that route instead. I downloaded a Slackware DVD, as it appears to be one that you can roll your own kernel without too much of a hassle. But, I want to get people's opinions before I start. Thanks to everyone who responds, and have a great day:) Patrick. -- 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: Preferred setup for development?
Hello Patrick, There are some information at: http://git.linuxtv.org/media_tree.git On Fri, Aug 17, 2012 at 8:50 AM, Patrick Dickey pdickeyb...@gmail.com wrote: I'm looking for information about what distributions people are using, and how they go about testing their code. The reason is, I'm running Ubuntu for my main distribution, and it seems like I'll have to go through a lot of hoops in order to compile and test changes to the kernel. I realize that I could probably just use the media_build tree, and add the changes there. But, I'd prefer to go the same route that the majority of the developers here do. So, my questions are these: 1. Do you use a specific distribution for development, or a roll your own (like Linux from Scratch)? 2. If you use a distribution, which one? I like and use Fedora. 3. Do you do your development on physical computers or on virtual machines (or both)? Most on physical. I use VM for some testing. 4. Do you have a machine that's dedicated to development, or is it one that you use for other things? My notebook for everything. 5. Do you use a newer computer, or older computer for development? (or both) For anyone using the media_build tree (instead of the media_git tree): Are you able to seamlessly implement changes that are in the media_git tree files to the media_build tree, or do you have to make changes in order to get them to compile? Are your files able to be implemented into the media_git tree seamlessly, or do you have to make changes to get them to compile? If you're able to use the media_build tree, and the changes you make can be implemented in the media_git tree without hassle, I may go that route instead. I downloaded a Slackware DVD, as it appears to be one that you can roll your own kernel without too much of a hassle. But, I want to get people's opinions before I start. The key points for Fedora / Ubuntu / ... are: - how to generate the initrd for allowing you to book your custom Kernel - what Kernel options are needed for your distro to work I like to follow distro specific instructions for generate Kernel packages. This works for me for Fedora. I follow: http://fedoraproject.org/wiki/Docs/CustomKernel Thanks to everyone who responds, and have a great day:) Patrick. -- 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 []'s -- Peter Senna Tschudin peter.se...@gmail.com gpg id: 48274C36 -- 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
[ANN] media_build should work again!
I've updated the media_build scripts to reflect the new file organization. Most of the work was actually in dealing with some driver changes that required compat code and that had nothing to do with the reorganization. I'll have to wait for the daily build tonight to know for certain whether all linux kernels are compiling fine, so I might have to do some finetuning this weekend if there are still some failures. 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 3/5] video: panel: Add MIPI DBI bus support
Hi Tomi,
On Friday 17 August 2012 13:51:49 Tomi Valkeinen wrote:
On Fri, 2012-08-17 at 12:02 +0200, Laurent Pinchart wrote:
On Friday 17 August 2012 12:03:02 Tomi Valkeinen wrote:
On Fri, 2012-08-17 at 02:49 +0200, Laurent Pinchart wrote:
+/*
--
---
+ * Bus operations
+ */
+
+void panel_dbi_write_command(struct panel_dbi_device *dev, unsigned
long
cmd) +{
+ dev-bus-ops-write_command(dev-bus, cmd);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_write_command);
+
+void panel_dbi_write_data(struct panel_dbi_device *dev, unsigned long
data) +{
+ dev-bus-ops-write_data(dev-bus, data);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_write_data);
+
+unsigned long panel_dbi_read_data(struct panel_dbi_device *dev)
+{
+ return dev-bus-ops-read_data(dev-bus);
+}
+EXPORT_SYMBOL_GPL(panel_dbi_read_data);
I'm not that familiar with how to implement bus drivers, can you
describe in pseudo code how the SoC's DBI driver would register these?
Sure.
The DBI bus driver first needs to create a panel_dbi_bus_ops instance:
static const struct panel_dbi_bus_ops sh_mobile_lcdc_dbi_bus_ops = {
.write_command = lcdc_dbi_write_command,
.write_data = lcdc_dbi_write_data,
.read_data = lcdc_dbi_read_data,
};
Thanks for the example, I think it cleared up things a bit.
As I mentioned earlier, I really think panel is not right here. While
the whole framework may be called panel framework, the bus drivers are
not panels, and we should support external chips also, which are not
panels either.
I agree. I've renamed panel_dbi_* to mipi_dbi_*.
I think write/read data functions are a bit limited. Shouldn't they be
something like write_data(const u8 *buf, int size) and read_data(u8
*buf, int len)?
Good point. My hardware doesn't support multi-byte read/write operations
directly so I haven't thought about adding those.
OMAP HW doesn't support it either. Well, not quite true, as OMAP's
system DMA could be used to write a buffer to the DBI output. But that's
really the same as doing the write with a a loop with CPU.
But first, the data type should be byte, not unsigned long. How would
you write 8 bits or 16 bits with your API?
u8 and u16 both fit in an unsigned long :-) Please see below.
And second, if the function takes just u8, you'd need lots of calls to do
simple writes.
I agree, an array write function is a good idea.
Can your hardware group command + data writes in a single operation ? If
so we should expose that at the API level as well.
No it can't. But with DCS that is a common operation, so we could have
some helpers to send command + data with one call.
Agreed.
Then again, I'd hope to have DCS somehow as a separate library, which would
then use DBI/DSI/whatnot to actually send the data.
I'm not quite sure how easy that is because of the differences between
the busses.
Is DBI limited to 8-bit data transfers for commands ? Pixels can be
transferred 16-bit at a time, commands might as well. While DCS only
specifies 8-bit command/data, DBI panels that are not DCS compliant can
use 16-bit command/data (the R61505 panel, albeit a SYS-80 panel, does
so).
I have to say I don't remember much about DBI =). Looking at OMAP's
driver, which was made for omap2 and hasn't been much updated since, I
see that there are 4 modes, 8/9/12/16 bits. I think that defines how
many of the parallel data lines are used.
SYS-80 also has an 18-bits mode, where bits 0 and 9 are always ignored when
transferring instructions and data other than pixels (for pixels the 18-bits
bus width can be used to transfer RGB666 in a single clock cycle).
See page 87 of
http://read.pudn.com/downloads91/sourcecode/others/348230/e61505_103a.pdf.
However, I don't think that matters for the panel driver when it wants
to send data. The panel driver should just call dbi_write(buf, buf_len),
and the dbi driver would send the data in the buffer according to the
bus width.
According to the DCS specification, commands and parameters are transferred
using 8-bit data. Non-DCS panels can however use wider commands and parameters
(all commands and parameters are 16-bits wide for the R61505 for instance).
We can add an API to switch the DBI bus width on the fly. For Renesas hardware
this would just require shifting bits around to output the 8-bit or 16-bit
commands on the right data lines (the R61505 uses D17-D9 in 8-bit mode, while
the DCS specification mentions D7-D0) based on how the panel is connected and
on which lines the panel expects data.
As commands can be expressed on either 8 or 16 bits I would use a 16 type for
them.
For parameters, we can either express everything as u8 * in the DBI bus
operations, or use a union similar to i2c_smbus_data
union i2c_smbus_data {
Re: Preferred setup for development?
On Fri August 17 2012 13:50:25 Patrick Dickey wrote: I'm looking for information about what distributions people are using, and how they go about testing their code. The reason is, I'm running Ubuntu for my main distribution, and it seems like I'll have to go through a lot of hoops in order to compile and test changes to the kernel. I realize that I could probably just use the media_build tree, and add the changes there. But, I'd prefer to go the same route that the majority of the developers here do. So, my questions are these: 1. Do you use a specific distribution for development, or a roll your own (like Linux from Scratch)? I used LFS a long time ago. It's great to learn how a linux system is put together, but it takes way too much time to upgrade. I've used several distros in the past but I'm now running aptosid, which is a rolling Debian sid distro. But I do build my own kernel. 2. If you use a distribution, which one? 3. Do you do your development on physical computers or on virtual machines (or both)? Physical for the most part. 4. Do you have a machine that's dedicated to development, or is it one that you use for other things? Both. I use my main PC for development, but I also have more specialized PCs to test certain things. 5. Do you use a newer computer, or older computer for development? (or both) I tend to upgrade to something faster every so often :-) For anyone using the media_build tree (instead of the media_git tree): Are you able to seamlessly implement changes that are in the media_git tree files to the media_build tree, or do you have to make changes in order to get them to compile? Are your files able to be implemented into the media_git tree seamlessly, or do you have to make changes to get them to compile? If you have to make changes, let me know. It should be seamless. Occasionally things break with media_build if new code is merged in media-git, but I try to be on top of it. If you're able to use the media_build tree, and the changes you make can be implemented in the media_git tree without hassle, I may go that route instead. I downloaded a Slackware DVD, as it appears to be one that you can roll your own kernel without too much of a hassle. But, I want to get people's opinions before I start. Generally, building your own kernel isn't that hard. Figuring it out tends to be a one-time job. But if you just touch media drivers and do not intend to do any work elsewhere in the kernel, then media_build should work well. 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: V4L2 API ambiguities: workshop presentation
Hi, On 08/17/2012 12:35 PM, Hans Verkuil wrote: Hi all, I've prepared a presentation for the upcoming workshop based on my RFC and the comments I received. It is available here: http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.pdf Attendees of the workshop: please review this before the workshop starts. I want to go through this list fairly quickly (particularly slides 1-14) so we can have more time for other topics. A note on the Pixel Aspect Ratio from me, since I won't be attending: I'm not sure if having a VIDIOC_G_PIXELASPECT is enough, it will work to get the current mode, but not for enumerating. Also it will not work with TRY_FMT, that is one cannot find out the actual pixelaspect until after a S_FMT. As mentioned in previous mail I think at a minimum the results of ENUM_FRAMESIZES should contain the pixel aspect per framesize, there is enough reserved space in the relevant structs to make this happen 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: V4L2 API ambiguities: workshop presentation
On Fri August 17 2012 14:48:23 Hans de Goede wrote: Hi, On 08/17/2012 12:35 PM, Hans Verkuil wrote: Hi all, I've prepared a presentation for the upcoming workshop based on my RFC and the comments I received. It is available here: http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.pdf Attendees of the workshop: please review this before the workshop starts. I want to go through this list fairly quickly (particularly slides 1-14) so we can have more time for other topics. A note on the Pixel Aspect Ratio from me, since I won't be attending: I'm not sure if having a VIDIOC_G_PIXELASPECT is enough, it will work to get the current mode, but not for enumerating. Also it will not work with TRY_FMT, that is one cannot find out the actual pixelaspect until after a S_FMT. As mentioned in previous mail I think at a minimum the results of ENUM_FRAMESIZES should contain the pixel aspect per framesize, there is enough reserved space in the relevant structs to make this happen Pixel aspect doesn't belong in the FMT ioctls: the pixel aspect ratio is a property of the video input/output format, but the FMT ioctls deal with scaling as well, so the aspect ratio would then be scaled as well, making it very complex indeed. Regarding ENUM_FRAMESIZES: it makes sense to add an aspect ratio here for use with sensors. But for video receivers ENUM_FRAMESIZES isn't applicable. 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: [Workshop-2011] V4L2 API ambiguities: workshop presentation
On Friday 17 August 2012 14:55:13 Hans Verkuil wrote: On Fri August 17 2012 14:48:23 Hans de Goede wrote: On 08/17/2012 12:35 PM, Hans Verkuil wrote: Hi all, I've prepared a presentation for the upcoming workshop based on my RFC and the comments I received. It is available here: http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.odp http://hverkuil.home.xs4all.nl/presentations/v4l2-workshop-2012.pdf Attendees of the workshop: please review this before the workshop starts. I want to go through this list fairly quickly (particularly slides 1-14) so we can have more time for other topics. A note on the Pixel Aspect Ratio from me, since I won't be attending: I'm not sure if having a VIDIOC_G_PIXELASPECT is enough, it will work to get the current mode, but not for enumerating. Also it will not work with TRY_FMT, that is one cannot find out the actual pixelaspect until after a S_FMT. As mentioned in previous mail I think at a minimum the results of ENUM_FRAMESIZES should contain the pixel aspect per framesize, there is enough reserved space in the relevant structs to make this happen Pixel aspect doesn't belong in the FMT ioctls: the pixel aspect ratio is a property of the video input/output format, but the FMT ioctls deal with scaling as well, so the aspect ratio would then be scaled as well, making it very complex indeed. Regarding ENUM_FRAMESIZES: it makes sense to add an aspect ratio here for use with sensors. But for video receivers ENUM_FRAMESIZES isn't applicable. Do we have sensors with non-square pixels ? -- 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 3/5] video: panel: Add MIPI DBI bus support
On Fri, 2012-08-17 at 14:33 +0200, Laurent Pinchart wrote:
But first, the data type should be byte, not unsigned long. How would
you write 8 bits or 16 bits with your API?
u8 and u16 both fit in an unsigned long :-) Please see below.
Ah, I see, so the driver would just discard 24 bits or 16 bits from the
ulong. I somehow thought that if you have 8 bit bus, and you call the
write with ulong, 4 bytes will be written.
Then again, I'd hope to have DCS somehow as a separate library, which would
then use DBI/DSI/whatnot to actually send the data.
I'm not quite sure how easy that is because of the differences between
the busses.
Is DBI limited to 8-bit data transfers for commands ? Pixels can be
transferred 16-bit at a time, commands might as well. While DCS only
specifies 8-bit command/data, DBI panels that are not DCS compliant can
use 16-bit command/data (the R61505 panel, albeit a SYS-80 panel, does
so).
I have to say I don't remember much about DBI =). Looking at OMAP's
driver, which was made for omap2 and hasn't been much updated since, I
see that there are 4 modes, 8/9/12/16 bits. I think that defines how
many of the parallel data lines are used.
SYS-80 also has an 18-bits mode, where bits 0 and 9 are always ignored when
transferring instructions and data other than pixels (for pixels the 18-bits
bus width can be used to transfer RGB666 in a single clock cycle).
See page 87 of
http://read.pudn.com/downloads91/sourcecode/others/348230/e61505_103a.pdf.
However, I don't think that matters for the panel driver when it wants
to send data. The panel driver should just call dbi_write(buf, buf_len),
and the dbi driver would send the data in the buffer according to the
bus width.
According to the DCS specification, commands and parameters are transferred
using 8-bit data. Non-DCS panels can however use wider commands and
parameters
(all commands and parameters are 16-bits wide for the R61505 for instance).
We can add an API to switch the DBI bus width on the fly. For Renesas
hardware
this would just require shifting bits around to output the 8-bit or 16-bit
commands on the right data lines (the R61505 uses D17-D9 in 8-bit mode, while
the DCS specification mentions D7-D0) based on how the panel is connected and
on which lines the panel expects data.
As commands can be expressed on either 8 or 16 bits I would use a 16 type for
them.
I won't put my head on the block, but I don't think DBI has any
restriction on the size of the command. A command just means a data
transfer while keeping the D/CX line low, and data when the line is
high. Similar transfers for n bytes can be done in both modes.
For parameters, we can either express everything as u8 * in the DBI bus
operations, or use a union similar to i2c_smbus_data
union i2c_smbus_data {
__u8 byte;
__u16 word;
__u8 block[I2C_SMBUS_BLOCK_MAX + 2]; /* block[0] is used for length */
/* and one more for user-space compatibility */
};
There's no DBI_BLOCK_MAX, so at least identical union won't work. I
think it's simplest to have u8 * function as a base, and then a few
helpers to write the most common datatypes.
So we could have on the lowest level something like:
dbi_write_command(u8 *buf, size_t size);
dbi_write_data(u8 *buf, size_t size);
And possible helpers:
dbi_write_data(u8 *cmd_buf, size_t cmd_size, u8 *data_buf, size_t
data_size);
dbi_write_dcs(u8 cmd, u8 *data, size_t size);
And variations:
dbi_write_dcs_0(u8 cmd);
dbi_write_dcs_1(u8 cmd, u8 data);
etc. So a simple helper to send 16 bits would be:
dbi_write_data(u16 data)
{
// or are the bytes the other way around...
u8 buf[2] = { data 0xff, (data 8) 0xff };
return dbi_write_data(buf, 2);
}
Helper functions would be available to perform 8-bit, 16-bit or n*8 bits
transfers.
Would that work for your use cases ?
Also note that some chips need to change the bus width on the fly. The
chip used on N800 wants configuration to be done with 8-bits, and pixel
transfers with 16-bits. Who knows why...
On which data lines is configuration performed ? D7-D0 ?
I guess so, but does it matter? All the bus driver needs to know is how
to send 8/16/.. bit data. On OMAP we just write the data to a 32 bit
register, and the HW takes the lowest n bits. Do the bits represent the
data lines directly on Renesans?
The omap driver actually only implements 8 and 16 bit modes, not the 9
and 12 bit modes. I'm not sure what kind of shifting is needed for
those.
We might just need to provide fake timings. Video mode timings are at the
core of display support in all drivers so we can't just get rid of them.
The h/v front/back porch and sync won't be used by display drivers for
DBI/DSI panels anyway.
Right. But we should probably think if we can, at the panel level, easily
separate conventional panels and
Re: [Workshop-2011] V4L2 API ambiguities: workshop presentation
Hi, On 08/17/2012 02:57 PM, Laurent Pinchart wrote: Snip Regarding ENUM_FRAMESIZES: it makes sense to add an aspect ratio here for use with sensors. But for video receivers ENUM_FRAMESIZES isn't applicable. Do we have sensors with non-square pixels ? Short answer: not that I know of. Long answer: that depends on the optics (so the sensor pixels may be square, but the optics could make them non-square from a proper mapping to a real world picture pov). As I've done too much with weird old webcams I actually now webcams which do this, the vicam cameras to be precise. The 3 com HomeConnect (04c1:009) has a sensor with a native resolution of 512x244, yeah widescreen baby! But it stems from an area where widescreen was unheard of in computer graphics, so it actually has optics which force that cool widescreen resolution back into a 4x3 field of view. So for a proper square pixels image form that camera its image needs to be scaled from 512x244 to 512x384 (*). But with that one exception proving the rule (Dutch expression), I think all sensors have square pixels. Regards, Hans *) Really? Yes really! -- 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 v2] smiapp: Use devm_* functions in smiapp-core.c file
Hi Sachin, On Fri, Aug 17, 2012 at 10:19:02AM +0530, Sachin Kamat wrote: devm_* functions are device managed functions and make code a bit smaller and cleaner. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- Changes since v1: Used devm_kzalloc for sensor-nvm. Used devm_clk_get and devm_regulator_get functions. This patch is based on Mauro's re-organized tree (media_tree staging/for_v3.7) and is compile tested. Thanks for the updated patch! I've applied this and the other patch you sent ([media] smiapp: Remove unused function) to my tree. Cheers, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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
Re: [RFC 3/5] video: panel: Add MIPI DBI bus support
Hi Tomi,
On Friday 17 August 2012 16:06:30 Tomi Valkeinen wrote:
On Fri, 2012-08-17 at 14:33 +0200, Laurent Pinchart wrote:
But first, the data type should be byte, not unsigned long. How would
you write 8 bits or 16 bits with your API?
u8 and u16 both fit in an unsigned long :-) Please see below.
Ah, I see, so the driver would just discard 24 bits or 16 bits from the
ulong.
That's right.
I somehow thought that if you have 8 bit bus, and you call the write with
ulong, 4 bytes will be written.
Then again, I'd hope to have DCS somehow as a separate library, which
would then use DBI/DSI/whatnot to actually send the data.
I'm not quite sure how easy that is because of the differences between
the busses.
Is DBI limited to 8-bit data transfers for commands ? Pixels can be
transferred 16-bit at a time, commands might as well. While DCS only
specifies 8-bit command/data, DBI panels that are not DCS compliant
can use 16-bit command/data (the R61505 panel, albeit a SYS-80 panel,
does so).
I have to say I don't remember much about DBI =). Looking at OMAP's
driver, which was made for omap2 and hasn't been much updated since, I
see that there are 4 modes, 8/9/12/16 bits. I think that defines how
many of the parallel data lines are used.
SYS-80 also has an 18-bits mode, where bits 0 and 9 are always ignored
when transferring instructions and data other than pixels (for pixels the
18-bits bus width can be used to transfer RGB666 in a single clock cycle).
See page 87 of
http://read.pudn.com/downloads91/sourcecode/others/348230/e61505_103a.pdf.
However, I don't think that matters for the panel driver when it wants
to send data. The panel driver should just call dbi_write(buf, buf_len),
and the dbi driver would send the data in the buffer according to the
bus width.
According to the DCS specification, commands and parameters are
transferred using 8-bit data. Non-DCS panels can however use wider
commands and parameters (all commands and parameters are 16-bits wide for
the R61505 for instance).
We can add an API to switch the DBI bus width on the fly. For Renesas
hardware this would just require shifting bits around to output the
8-bit or 16-bit commands on the right data lines (the R61505 uses D17-D9
in 8-bit mode, while the DCS specification mentions D7-D0) based on how
the panel is connected and on which lines the panel expects data.
As commands can be expressed on either 8 or 16 bits I would use a 16 type
for them.
I won't put my head on the block, but I don't think DBI has any
restriction on the size of the command. A command just means a data
transfer while keeping the D/CX line low, and data when the line is
high. Similar transfers for n bytes can be done in both modes.
Right. I'll see if the API could be simplified by having a single write
callback function with a data/command parameter.
For parameters, we can either express everything as u8 * in the DBI bus
operations, or use a union similar to i2c_smbus_data
union i2c_smbus_data {
__u8 byte;
__u16 word;
__u8 block[I2C_SMBUS_BLOCK_MAX + 2]; /* block[0] is used for
length */
/* and one more for user-space
compatibility */
};
There's no DBI_BLOCK_MAX, so at least identical union won't work. I
think it's simplest to have u8 * function as a base, and then a few
helpers to write the most common datatypes.
OK, that sounds good to me.
So we could have on the lowest level something like:
dbi_write_command(u8 *buf, size_t size);
dbi_write_data(u8 *buf, size_t size);
And possible helpers:
dbi_write_data(u8 *cmd_buf, size_t cmd_size, u8 *data_buf, size_t
data_size);
dbi_write_dcs(u8 cmd, u8 *data, size_t size);
And variations:
dbi_write_dcs_0(u8 cmd);
dbi_write_dcs_1(u8 cmd, u8 data);
etc. So a simple helper to send 16 bits would be:
dbi_write_data(u16 data)
{
// or are the bytes the other way around...
u8 buf[2] = { data 0xff, (data 8) 0xff };
return dbi_write_data(buf, 2);
}
Helper functions would be available to perform 8-bit, 16-bit or n*8 bits
transfers.
Would that work for your use cases ?
Also note that some chips need to change the bus width on the fly. The
chip used on N800 wants configuration to be done with 8-bits, and pixel
transfers with 16-bits. Who knows why...
On which data lines is configuration performed ? D7-D0 ?
I guess so, but does it matter? All the bus driver needs to know is how
to send 8/16/.. bit data. On OMAP we just write the data to a 32 bit
register, and the HW takes the lowest n bits. Do the bits represent the
data lines directly on Renesans?
Yes they do. For a SYS-80 panel configured in 18-bits mode, I'll have to write
((data 0xff00) 2) | ((data 0x00ff) 1)
(d15:8 -
Re: (still) NULL pointer crashes with nuvoton_cir driver
(Adding Mauro to CC has he is the maintainer)
On Thu, Aug 16, 2012 at 10:09:32AM +0200, Matthijs Kooijman wrote:
Hi folks,
I'm currently compiling a 3.5 kernel with just the rdev initialization
moved up to see if this will fix my problem at all, but I'd like your
view on this in the meantime as well.
Ok, this seems to fix my problem:
--- a/drivers/media/rc/nuvoton-cir.c
+++ b/drivers/media/rc/nuvoton-cir.c
@@ -1066,6 +1066,7 @@
/* tx bits */
rdev-tx_resolution = XYZ;
#endif
+ nvt-rdev = rdev;
This makes sense to me. Note however that there are more drivers with
a similar problem (e.g., fintek-cir.c).
ret = -EBUSY; /* now claim resources */ @@ -1090,7 +1091,6
@@ goto failure5;
device_init_wakeup(pdev-dev, true);
- nvt-rdev = rdev;
nvt_pr(KERN_NOTICE, driver has been successfully loaded\n);
if (debug) {
cir_dump_regs(nvt);
I'm still not sure if the rc_register_device shouldn't also be moved up. It
seems this doesn't trigger a problem right now, but if there is a problem, I
suspect its trigger window is a lot smaller than with the rdev initialization
problem...
I'm not sure as well, I'm not very familiar with this code. However,
it looks like the IRQ request should actually be one of the last
things to do here.
Cheers,
--
Luis
--
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 v2] smiapp: Use devm_* functions in smiapp-core.c file
On 17 August 2012 19:14, Sakari Ailus sakari.ai...@iki.fi wrote: Hi Sachin, On Fri, Aug 17, 2012 at 10:19:02AM +0530, Sachin Kamat wrote: devm_* functions are device managed functions and make code a bit smaller and cleaner. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- Changes since v1: Used devm_kzalloc for sensor-nvm. Used devm_clk_get and devm_regulator_get functions. This patch is based on Mauro's re-organized tree (media_tree staging/for_v3.7) and is compile tested. Thanks for the updated patch! I've applied this and the other patch you sent ([media] smiapp: Remove unused function) to my tree. Thanks Sakari. Cheers, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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-Trivial 1/2] [media] s5p-fimc: Replace asm/* headers with linux/*
On 17 August 2012 13:51, Sylwester Nawrocki s.nawro...@samsung.com wrote: Hi Sachin, On 08/17/2012 08:28 AM, Sachin Kamat wrote: Silences the following warning: WARNING: Use #include linux/sizes.h instead of asm/sizes.h Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Added both to my tree. Thanks Sylwester. Thanks, Sylwester -- 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] dvb_frontend: Multistream support
16.08.2012, 21:11, Antti Palosaari cr...@iki.fi: - /* ISDB-T specifics */ - u32 isdbs_ts_id; - - /* DVB-T2 specifics */ - u32 dvbt2_plp_id; + /* Multistream specifics */ + u32 stream_id; u32 == 32 bit long unsigned number. See next comment. - c-isdbs_ts_id = 0; - c-dvbt2_plp_id = 0; + c-stream_id = -1; unsigned number cannot be -1. It can be only 0 or bigger. Due to that this is wrong. so maybe better declare in as int ? depend from standard valid stream id (for DVB is 0-255) and any another value (-1) disable stream filtering in demod. -- 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] dvb_frontend: Multistream support
16.08.2012, 21:11, Antti Palosaari cr...@iki.fi: @Mauro, should we rename also DTV_ISDBS_TS_ID to DTV_ISDBS_TS_ID_LEGACY to remind users ? Maybe leave DTV_ISDBS_TS_ID and convert DTV_DVBT2_PLP_ID to DTV_DVB_STREAM_ID ? and dvbt2_plp_id convert to dvb_stream_id. Because DVB and ISDB different standards and look like stream id for ISDB is 16 bit, for DVB-S2/T2 8 bit. -- 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] dvb_frontend: Multistream support
Em 17-08-2012 14:52, CrazyCat escreveu: 16.08.2012, 21:11, Antti Palosaari cr...@iki.fi: @Mauro, should we rename also DTV_ISDBS_TS_ID to DTV_ISDBS_TS_ID_LEGACY to remind users ? Maybe leave DTV_ISDBS_TS_ID and convert DTV_DVBT2_PLP_ID to DTV_DVB_STREAM_ID ? and dvbt2_plp_id convert to dvb_stream_id. Because DVB and ISDB different standards and look like stream id for ISDB is 16 bit, for DVB-S2/T2 8 bit. Well, Frequency range in satellite standards are in kHz, while the frequencies on the other ones are in Hz. So, I don't think that the number of bits should limit it. In a matter of fact, even on DVB-T/T2, DVB-S/S2, ... there are some fields that gained more bits. So, I don't see any issue on using DTV_DVB_STREAM_ID on all of them, even if the number of bits are different. Of course, the API documentation should be clear about the field differences. Regards, Mauro. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb_frontend: Multistream support
On 08/17/2012 08:21 PM, CrazyCat wrote: 16.08.2012, 21:11, Antti Palosaari cr...@iki.fi: - /* ISDB-T specifics */ - u32 isdbs_ts_id; - - /* DVB-T2 specifics */ - u32 dvbt2_plp_id; + /* Multistream specifics */ + u32 stream_id; u32 == 32 bit long unsigned number. See next comment. - c-isdbs_ts_id = 0; - c-dvbt2_plp_id = 0; + c-stream_id = -1; unsigned number cannot be -1. It can be only 0 or bigger. Due to that this is wrong. so maybe better declare in as int ? depend from standard valid stream id (for DVB is 0-255) and any another value (-1) disable stream filtering in demod. I agree that. Actually I was thinking same. For DVB-T2 valid values are 0-255, I haven't looked others but surely int maximum should enough for all. regards Antti -- http://palosaari.fi/ -- 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] dvb_frontend: Multistream support
Em 17-08-2012 14:21, CrazyCat escreveu: 16.08.2012, 21:11, Antti Palosaari cr...@iki.fi: - /* ISDB-T specifics */ - u32 isdbs_ts_id; - - /* DVB-T2 specifics */ - u32 dvbt2_plp_id; + /* Multistream specifics */ + u32 stream_id; u32 == 32 bit long unsigned number. See next comment. - c-isdbs_ts_id = 0; - c-dvbt2_plp_id = 0; + c-stream_id = -1; unsigned number cannot be -1. It can be only 0 or bigger. Due to that this is wrong. so maybe better declare in as int ? depend from standard valid stream id (for DVB is 0-255) and any another value (-1) disable stream filtering in demod. It should be noticed that DVBv5 will pass it as u32 in any case. So, maybe it is better to use UINT_MAX as the no-filter value: /home/v4l/v4l/patchwork/include/linux/kernel.h:#define UINT_MAX (~0U) Some care is needed when doing that, to avoid 32bits/64bits compat conflicts. Also, this define doesn't exist in userspace. so, maybe using something like: #define NO_STREAM_ID_FILTER (~0U) Would work properly, as, even on 64bits system with 32bits userspace, this should work or, if we want to be pedantic: #define NO_STREAM_ID_FILTER ((u32)(~0U)) -- 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 -- 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
Strong pairing cam doesn't work with CT-3650 driver (ttusb2)
Hi, Have anyone out there tested the CT-3650 USB driver in the Linux kernel with a strong pairing cam. According to some web-forums, the hardware should support that given using the vendor provided DVB WinXXX software. drivers/media/dvb/dvb-usb/ttusb2.c Any clues how to debug or what can be wrong? When inserting the CAM, VDR says that a CAM is present, but then after a while no CAM is present. Log: ttusb2: tt3650_ci_slot_reset 0 ttusb2: tt3650_ci_read_attribute_mem - 0 0x00 ttusb2: tt3650_ci_read_attribute_mem 0002 - 0 0x00 TUPLE type:0x0 length:0 dvb_ca adapter 0: Invalid PC card inserted :( dvb_ca_en50221_io_open dvb_ca_en50221_thread_wakeup dvb_ca_en50221_io_do_ioctl dvb_ca_en50221_io_do_ioctl dvb_ca_en50221_slot_shutdown ttusb2: tt3650_ci_set_video_port 0 0 Slot 0 shutdown dvb_ca_en50221_thread_wakeup dvb_ca_en50221_io_poll ttusb2: tt3650_ci_slot_reset 0 dvb_ca_en50221_io_do_ioctl dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll ttusb2: tt3650_ci_read_attribute_mem - 0 0x1d ttusb2: tt3650_ci_read_attribute_mem 0002 - 0 0x04 TUPLE type:0x1d length:4 ttusb2: tt3650_ci_read_attribute_mem 0004 - 0 0x00 0x00: 0x00 . ttusb2: tt3650_ci_read_attribute_mem 0006 - 0 0xdb 0x01: 0xdb . ttusb2: tt3650_ci_read_attribute_mem 0008 - 0 0x08 0x02: 0x08 . ttusb2: tt3650_ci_read_attribute_mem 000a - 0 0xff 0x03: 0xff . dvb_ca adapter 0: Invalid PC card inserted :( dvb_ca_en50221_io_do_ioctl --HPS -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: 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:Fri Aug 17 19:00:26 CEST 2012 git hash:9b78c5a3007e10a172d4e83bea18509fdff2e8e3 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: ERRORS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-rc2-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-rc2-i686: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification 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: Strong pairing cam doesn't work with CT-3650 driver (ttusb2)
On 08/17/2012 10:35 PM, Hans Petter Selasky wrote: Hi, Have anyone out there tested the CT-3650 USB driver in the Linux kernel with a strong pairing cam. Likely that means CI+ with some pairing features enabled. According to some web-forums, the hardware should support that given using the vendor provided DVB WinXXX software. drivers/media/dvb/dvb-usb/ttusb2.c Any clues how to debug or what can be wrong? Take USB traffic capture from working Windows setup and analyze what is done differently. When inserting the CAM, VDR says that a CAM is present, but then after a while no CAM is present. Log: ttusb2: tt3650_ci_slot_reset 0 ttusb2: tt3650_ci_read_attribute_mem - 0 0x00 ttusb2: tt3650_ci_read_attribute_mem 0002 - 0 0x00 TUPLE type:0x0 length:0 dvb_ca adapter 0: Invalid PC card inserted :( dvb_ca_en50221_io_open dvb_ca_en50221_thread_wakeup dvb_ca_en50221_io_do_ioctl dvb_ca_en50221_io_do_ioctl dvb_ca_en50221_slot_shutdown ttusb2: tt3650_ci_set_video_port 0 0 Slot 0 shutdown dvb_ca_en50221_thread_wakeup dvb_ca_en50221_io_poll ttusb2: tt3650_ci_slot_reset 0 dvb_ca_en50221_io_do_ioctl dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll dvb_ca_en50221_io_poll ttusb2: tt3650_ci_read_attribute_mem - 0 0x1d ttusb2: tt3650_ci_read_attribute_mem 0002 - 0 0x04 TUPLE type:0x1d length:4 ttusb2: tt3650_ci_read_attribute_mem 0004 - 0 0x00 0x00: 0x00 . ttusb2: tt3650_ci_read_attribute_mem 0006 - 0 0xdb 0x01: 0xdb . ttusb2: tt3650_ci_read_attribute_mem 0008 - 0 0x08 0x02: 0x08 . ttusb2: tt3650_ci_read_attribute_mem 000a - 0 0xff 0x03: 0xff . dvb_ca adapter 0: Invalid PC card inserted :( dvb_ca_en50221_io_do_ioctl regards Antti -- http://palosaari.fi/ -- 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
DRM/V4L2 buffer sharing (was: Re: Patches submitted via linux-media ML that are at patchwork.linuxtv.org)
Hi Laurent, On 08/15/2012 11:09 PM, Laurent Pinchart wrote: On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote: On 08/15/2012 12:06 AM, Laurent Pinchart wrote: On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote: On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote: This one requires more testing: May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API http://patchwork.linuxtv.org/patch/11268 Sylwester Nawrocki s.nawro...@samsung.com Hmm, this is not valid any more. Tomasz just posted a new patch series that adds DMABUF importer and exporter feature altogether. [PATCHv8 00/26] Integration of videobuf2 with DMABUF I guess we need someone else to submit test patches for other H/W than just Samsung SoCs. I'm not sure if we've got enough resources to port this to other hardware. We have been using these features internally for some time already. It's been 2 kernel releases and I can see only Ack tags from Laurent on Tomasz's patch series, hence it seems there is no wide interest in DMABUF support in V4L2 and this patch series is probably going to stay in a fridge for another few kernel releases. What would be required to push it to v3.7 ? Mauro requested more test coverage on that, which is understood since this is a fairly important API enhancement and the V4L2 video overlay API replacement. We need DMABUF support added at some webcam driver and a DRM driver with prime support (or some V4L2 output driver), I guess it would be best to have that in a PC environment. It looks like i915/radeon/nouveau drivers already have prime support. uvcvideo has recently been moved to videobuf2, using vb2_vmalloc. I can easily test that, except that I have no idea how to export buffers on the i915 side when X is running. Have you looked into that ? All right. Yes, I'm also not sure yet how to do it. I tried it on a laptop with i915 driver, but in the running system drmModeGetResources() just fails with EPERM. I've CCed dri-devel, so hopefully someone can shed some light on this. The DRM driver could be an exporter of buffers that would be passed to the webcam driver. And except the kernel patches we would need a test application, similar to that one: http://git.infradead.org/users/kmpark/public-apps/blob/a7e755629a74a7ac13788 2032a0f7b2480fa1490:/v4l2-drm-example/dmabuf-sharing.c I haven't been closely following the DMABUF APIs development, I think Tomasz could provide more details on that. It's likely I'll get around and prepare a test case as outlined above in coming days. Anyway, it would be appreciated if someone else could give this patch series a try. I've previously tested the patches on Renesas hardware, exporting buffers on the FBDEV side and importing them on the V4L2 side. We thus have test results for two different platforms, albeit all ARM-based. I guess ARM is where those APIs will be used mostly, still it would be helpful to have easier reproducible test environment. -- 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: cron job: media_tree daily build: ERRORS
Hi Hans, On 08/17/2012 09:54 PM, Hans Verkuil wrote: This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Fri Aug 17 19:00:26 CEST 2012 git hash:9b78c5a3007e10a172d4e83bea18509fdff2e8e3 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: ERRORS linux-git-arm-eabi-exynos: ERRORS make[4]: *** No rule to make target `drivers/media/platform/sh_mobile_csi2.c', needed by `drivers/media/platform/sh_mobile_csi2.o'. Stop. This orphaned file doesn't belong to Exynos platform, some error in kernel config ? :) make[4]: *** Waiting for unfinished jobs make[3]: *** [drivers/media/platform] Error 2 make[3]: *** Waiting for unfinished jobs make[2]: *** [drivers/media/] Error 2 make[1]: *** [sub-make] Error 2 make: *** [all] Error 2 Fri Aug 17 19:01:37 CEST 2012 Regards, 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: DRM/V4L2 buffer sharing
Em 17-08-2012 18:01, Sylwester Nawrocki escreveu: Hi Laurent, On 08/15/2012 11:09 PM, Laurent Pinchart wrote: On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote: On 08/15/2012 12:06 AM, Laurent Pinchart wrote: On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote: On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote: This one requires more testing: May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API http://patchwork.linuxtv.org/patch/11268 Sylwester Nawrocki s.nawro...@samsung.com Hmm, this is not valid any more. Tomasz just posted a new patch series that adds DMABUF importer and exporter feature altogether. [PATCHv8 00/26] Integration of videobuf2 with DMABUF I guess we need someone else to submit test patches for other H/W than just Samsung SoCs. I'm not sure if we've got enough resources to port this to other hardware. We have been using these features internally for some time already. It's been 2 kernel releases and I can see only Ack tags from Laurent on Tomasz's patch series, hence it seems there is no wide interest in DMABUF support in V4L2 and this patch series is probably going to stay in a fridge for another few kernel releases. What would be required to push it to v3.7 ? Mauro requested more test coverage on that, which is understood since this is a fairly important API enhancement and the V4L2 video overlay API replacement. We need DMABUF support added at some webcam driver and a DRM driver with prime support (or some V4L2 output driver), I guess it would be best to have that in a PC environment. It looks like i915/radeon/nouveau drivers already have prime support. uvcvideo has recently been moved to videobuf2, using vb2_vmalloc. I can easily test that, except that I have no idea how to export buffers on the i915 side when X is running. Have you looked into that ? All right. Yes, I'm also not sure yet how to do it. I tried it on a laptop with i915 driver, but in the running system drmModeGetResources() just fails with EPERM. I've CCed dri-devel, so hopefully someone can shed some light on this. Likely, you need to run with root permission to use it, or to write an Xorg driver. It is probably easier to get the V4L driver there, that uses the VIDIOC_OVERLAY stuff, and make it work via DMABUF: http://cgit.freedesktop.org/xorg/driver/xf86-video-v4l/ In order to test it, xawtv has already the code needed to talk with the v4l plugin. What the plugin does is to export the video board as a XV extension, accessible via xawtv. It currently talks with the display card also via XV, but I believe it won't be hard to port it to work with DMABUF. As the interface between xawtv and the v4l plugin is just Xv, changing the code there from VIDIOC_OVERLAY to DMABUF should be trivial. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
Скъпа моя, Приветствия към вас, скъпа моя възлюбен, аз съм г-жа Кристи Уолтън голяма гражданин на Съединените американски щати. Аз ви нося предложение на стойност $ 9,000,000,000.00 (девет милиарда Съединените членка долара), които възнамерявам да се използват за благотворителност. Моля да ми отговори обратно, ако се интересувате, така че мога да ви предостави повече подробности. Email: christy101wal...@yahoo.co.jp Бог да ви благослови. Г-жа Кристи Уолтън.
Re: DRM/V4L2 buffer sharing
Hi Mauro, On Friday 17 August 2012 19:03:47 Mauro Carvalho Chehab wrote: Em 17-08-2012 18:01, Sylwester Nawrocki escreveu: On 08/15/2012 11:09 PM, Laurent Pinchart wrote: On Wednesday 15 August 2012 18:13:19 Sylwester Nawrocki wrote: On 08/15/2012 12:06 AM, Laurent Pinchart wrote: On Tuesday 14 August 2012 18:37:23 Sylwester Nawrocki wrote: On 08/14/2012 03:04 PM, Mauro Carvalho Chehab wrote: This one requires more testing: May,15 2012: [GIT,PULL,FOR,3.5] DMABUF importer feature in V4L2 API http://patchwork.linuxtv.org/patch/11268 Sylwester Nawrocki s.nawro...@samsung.com Hmm, this is not valid any more. Tomasz just posted a new patch series that adds DMABUF importer and exporter feature altogether. [PATCHv8 00/26] Integration of videobuf2 with DMABUF I guess we need someone else to submit test patches for other H/W than just Samsung SoCs. I'm not sure if we've got enough resources to port this to other hardware. We have been using these features internally for some time already. It's been 2 kernel releases and I can see only Ack tags from Laurent on Tomasz's patch series, hence it seems there is no wide interest in DMABUF support in V4L2 and this patch series is probably going to stay in a fridge for another few kernel releases. What would be required to push it to v3.7 ? Mauro requested more test coverage on that, which is understood since this is a fairly important API enhancement and the V4L2 video overlay API replacement. We need DMABUF support added at some webcam driver and a DRM driver with prime support (or some V4L2 output driver), I guess it would be best to have that in a PC environment. It looks like i915/radeon/nouveau drivers already have prime support. uvcvideo has recently been moved to videobuf2, using vb2_vmalloc. I can easily test that, except that I have no idea how to export buffers on the i915 side when X is running. Have you looked into that ? All right. Yes, I'm also not sure yet how to do it. I tried it on a laptop with i915 driver, but in the running system drmModeGetResources() just fails with EPERM. I've CCed dri-devel, so hopefully someone can shed some light on this. Likely, you need to run with root permission to use it, or to write an Xorg driver. It is probably easier to get the V4L driver there, that uses the VIDIOC_OVERLAY stuff, and make it work via DMABUF: http://cgit.freedesktop.org/xorg/driver/xf86-video-v4l/ That won't really help for our test cases. I want to capture from a UVC device using DMABUF import directly to the i915 DRM device using DRM export. In order to do so I will need to get hold of GEM objects that I can use to display the data, possibly through the OpenGL API. I'm looking for help on that last point, I can easily handle the UVC capture code myself. In order to test it, xawtv has already the code needed to talk with the v4l plugin. What the plugin does is to export the video board as a XV extension, accessible via xawtv. It currently talks with the display card also via XV, but I believe it won't be hard to port it to work with DMABUF. As the interface between xawtv and the v4l plugin is just Xv, changing the code there from VIDIOC_OVERLAY to DMABUF should be trivial. -- 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: [PATCH 1/1] driver-core: Shut up dev_dbg_reatelimited() without DEBUG
On 08/17/2012 09:04 AM, Hiroshi Doyu wrote:
dev_dbg_reatelimited() without DEBUG printed 217078 callbacks
suppressed. This shouldn't print anything without DEBUG.
Signed-off-by: Hiroshi Doyu hd...@nvidia.com
Reported-by: Antti Palosaari cr...@iki.fi
---
include/linux/device.h |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index eb945e1..d4dc26e 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -962,9 +962,13 @@ do {
\
dev_level_ratelimited(dev_notice, dev, fmt, ##__VA_ARGS__)
#define dev_info_ratelimited(dev, fmt, ...) \
dev_level_ratelimited(dev_info, dev, fmt, ##__VA_ARGS__)
+#if defined(DEBUG)
#define dev_dbg_ratelimited(dev, fmt, ...)\
dev_level_ratelimited(dev_dbg, dev, fmt, ##__VA_ARGS__)
-
+#else
+#define dev_dbg_ratelimited(dev, fmt, ...) \
+ no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
+#endif
/*
* Stupid hackaround for existing uses of non-printk uses dev_info
*
NACK. I don't think that's correct behavior. After that patch it kills
all output of dev_dbg_ratelimited(). If I use dynamic debugs and order
debugs, I expect to see debugs as earlier.
I did test module in order to demonstrate problem. Here it is:
http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/dev_dbg_ratelimited
There is also file named: test_results.txt
It contains 4 test cases:
1) without that patch without module dynamic debug
2) without that patch module dynamic debug ordered
3) with that patch without module dynamic debug
4) with that patch module dynamic debug ordered
regards
Antti
--
http://palosaari.fi/
--
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
dvico fusion hdtv dual express 2 support
Hi, I accidentally purchased a dvico fusionhtdtv dual express2 rather than just a plain dual express and I've since found out the express 2 is not supported. Cheeky to ask, but I was just wondering if anyone happened to be working on support for this in ubuntu 10.04? I'm trying to decide if I should ebay this card or or not... thanks for your time Kristin. -- 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 0/5] Generic panel framework
Hi Tomi, On Friday 17 August 2012 14:42:31 Tomi Valkeinen wrote: On Fri, 2012-08-17 at 13:10 +0200, Laurent Pinchart wrote: What kind of directory structure do you have in mind ? Panels are already isolated in drivers/video/panel/ so we could already ditch the panel- prefix in drivers. The same directory also contains files for the framework and buses. But perhaps there's no need for additional directories if the amount of non-panel files is small. And you can easily see from the name that they are not panel drivers (e.g. mipi_dbi_bus.c). I don't expect the directory to contain many non-panel files, so let's keep it as-is for now. mipi-dbi-bus might not belong to include/video/panel/ though, as it can be used for non-panel devices (at least in theory). The future mipi-dsi-bus certainly will. Would you also create include/video/panel/ ? Perhaps that would be good. Well, having all the files prefixed with panel- is not bad as such, but just feel extra. --- Should we aim for DT only solution from the start? DT is the direction we are going, and I feel the older platform data stuff would be deprecated soon. Don't forget about non-ARM architectures :-/ We need panel drivers for SH as well, which doesn't use DT. I don't think that would be a big issue, a DT- compliant solution should be easy to use through board code and platform data as well. I didn't forget about them as I didn't even think about them ;). I somehow had the impression that other architectures would also use DT, sooner or later. I could be mistaken, though. And true, it's not a big issue to support both DT and non-DT versions, but I've been porting omap stuff for DT and keeping the old platform data stuff also there, and it just feels burdensome. For very simple panels it's easy, but when you've passing lots of parameters the code starts to get longer. This one would be rather impossible with the upper layer handling the enabling of the video stream. Thus I see that the panel driver needs to control the sequences, and the Sharp panel driver's enable would look something like: regulator_enable(...); sleep(); dpi_enable_video(); sleep(); gpip_set(..); I have to admit I have no better solution to propose at the moment, even if I don't really like making the panel control the video stream. When several devices will be present in the chain all of them might have similar annoying requirements, and my feeling is that the resulting code will be quite messy. At the end of the day the only way to really find out is to write an implementation. If we have a chain of devices, and each device uses the bus interface from the previous device in the chain, there shouldn't be a problem. In that model each device can handle the task however is best for it. I think the problems come from the divided control we'll have. I mean, if the panel driver would decide itself what to send to its output, and it would provide the data (think of an i2c device), this would be very simple. And it actually is for things like configuration data etc, but not so for video stream. Would you be able to send incremental patches on top of v2 to implement the solution you have in mind ? It would be neat if you could also implement mipi- dsi-bus for the OMAP DSS and test the code with a real device :-) It could cause some locking issues, though. First the panel's remove could take a lock, but the remove sequence would cause the display driver to call disable on the panel, which could again try to take the same lock... We have two possible ways of calling panel operations, either directly (panel-bus-ops-enable(...)) or indirectly (panel_enable(...)). The former is what V4L2 currently does with subdevs, and requires display drivers to hold a reference to the panel. The later can do without a direct reference only if we use a global lock, which is something I would like to Wouldn't panel_enable() just do the same panel-bus-ops-enable() anyway, and both require a panel reference? I don't see the difference. Indeed, you're right. I'm not sure what I was thinking about. avoid. A panel-wide lock wouldn't work, as the access function would need to take the lock on a panel instance that can be removed at any time. Can't this be handled with some kind of get/put refcounting? If there's a ref, it can't be removed. Trouble will come when the display driver will hold a reference to the panel, and the panel will hold a reference to the display driver (for instance because the display driver provides the DBI/DSI bus, or because it provides a clock used by the panel). Generally about locks, if we define that panel ops may only be called exclusively, does it simplify things? I think we can make such requirements, as there should be only one display framework that handles the panel. Then we don't need locking for things like
