VIDIOC_ENUM_FMT bug query
Is there any further action I can take to discover whether a webcam can support a format? or to help develop a patch? the Sandberg Nightcam2 specification lists 1280 x 960 up to 15 frames per second but $ v4l2-ctl --list-formats-ext lists no such format as available regards Jonathan Chetwynd http://www.sandberg.it/product/NightCam-2 $ v4l2-ctl --list-formats-ext ioctl: VIDIOC_ENUM_FMT Index : 0 Type: Video Capture Pixel Format: 'S920' Name: S920 Size: Discrete 160x120 Size: Discrete 320x240 Size: Discrete 640x480 Index : 1 Type: Video Capture Pixel Format: 'BA81' Name: BA81 Size: Discrete 160x120 Size: Discrete 320x240 Size: Discrete 640x480 Index : 2 Type: Video Capture Pixel Format: 'JPEG' (compressed) Name: JPEG Size: Discrete 160x120 Size: Discrete 320x240 Size: Discrete 640x480 -- 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: VIDIOC_ENUM_FMT bug query
dmesg: gspca_sn9c20x: OV7660 sensor detected regards Jonathan On 13/03/13 09:29, jonathan chetwynd wrote: Is there any further action I can take to discover whether a webcam can support a format? or to help develop a patch? the Sandberg Nightcam2 specification lists 1280 x 960 up to 15 frames per second but $ v4l2-ctl --list-formats-ext lists no such format as available regards Jonathan Chetwynd http://www.sandberg.it/product/NightCam-2 $ v4l2-ctl --list-formats-ext ioctl: VIDIOC_ENUM_FMT Index : 0 Type: Video Capture Pixel Format: 'S920' Name: S920 Size: Discrete 160x120 Size: Discrete 320x240 Size: Discrete 640x480 Index : 1 Type: Video Capture Pixel Format: 'BA81' Name: BA81 Size: Discrete 160x120 Size: Discrete 320x240 Size: Discrete 640x480 Index : 2 Type: Video Capture Pixel Format: 'JPEG' (compressed) Name: JPEG Size: Discrete 160x120 Size: Discrete 320x240 Size: Discrete 640x480 -- Jonathan Chetwynd http://www.gnote.org Eyetracking in HTML5 -- 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] drm/exynos: change the method for getting the interrupt resource of FIMD
Replaces the platform_get_resource() for IORESOURCE_IRQ with
platform_get_resource_byname().
Both in exynos4 and exynos5, FIMD IP has 3 interrupts in the order: fifo,
vsync, and lcd_sys.
But The FIMD driver expects the vsync interrupt to be mentioned as the
1st parameter in the FIMD DT node. So to meet this expectation of the
driver, the FIMD DT node was forced to be made by keeping vsync as the
1st paramter.
For example in exynos4, the FIMD DT node has interrupt numbers
mentioned as 11, 1 11, 0 11, 2 keeping vsync as the 1st paramter.
This patch fixes the above mentioned hack of re-ordering of the
FIMD interrupt numbers by getting interrupt resource of FIMD by using
platform_get_resource_byname().
Signed-off-by: Vikas Sajjan vikas.saj...@linaro.org
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 1ea173a..cd79d38 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -945,7 +945,7 @@ static int fimd_probe(struct platform_device *pdev)
return -ENXIO;
}
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, vsync);
if (!res) {
dev_err(dev, irq request failed.\n);
return -ENXIO;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] dma-mapping: enable no mmu support in dma_common_mmap
Hello,
On 3/6/2013 12:40 AM, Scott Jiang wrote:
No MMU systems also make use of this function to do mmap.
Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com
---
drivers/base/dma-mapping.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 0ce39a3..ae655b2 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -245,7 +245,6 @@ int dma_common_mmap(struct device *dev, struct
vm_area_struct *vma,
void *cpu_addr, dma_addr_t dma_addr, size_t size)
{
int ret = -ENXIO;
-#ifdef CONFIG_MMU
unsigned long user_count = (vma-vm_end - vma-vm_start) PAGE_SHIFT;
unsigned long count = PAGE_ALIGN(size) PAGE_SHIFT;
unsigned long pfn = page_to_pfn(virt_to_page(cpu_addr));
@@ -262,7 +261,6 @@ int dma_common_mmap(struct device *dev, struct
vm_area_struct *vma,
user_count PAGE_SHIFT,
vma-vm_page_prot);
}
-#endif /* CONFIG_MMU */
return ret;
}
I really have no experience with NO-MMU kernels, could you explain a bit
more how this
is useful for handling mmap on such systems? How remap_pfn_range() is
handled on no-mmu
systems?
I've thought that mmap on no-mmu systems is silently replaced by a call to
get_unmapped_area(), but it looks that there is still a call to mmap
function.
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
cron job: media_tree daily build: WARNINGS
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: Wed Mar 13 19:00:21 CET 2013 git branch: test git hash: 457ba4ce4f435d0b4dd82a0acc6c796e541a2ea7 gcc version:i686-linux-gcc (GCC) 4.7.2 host hardware: x86_64 host os:3.8.03-marune linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: WARNINGS linux-git-arm-omap: WARNINGS linux-git-blackfin: WARNINGS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: WARNINGS linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: OK linux-3.9-rc1-i686: OK linux-2.6.31.14-x86_64: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 01/12] media: s5p-fimc: modify existing mdev to use common pipeline
Hi Shaik,
On 03/11/2013 07:41 AM, Shaik Ameer Basha wrote:
Hi Sylwester,
Thanks for the review.
Actually I know this is the important patch in this series and I
wanted us to have
enough time to discuss on this patch. That's why I posted this patch
series in hurry.
Sure, I'm glad it was posted early.
I will remove this patch from the exynos5-mdev series and will send this as a
separate patch from next time.
OK.
please find my review comments inline..
On Mon, Mar 11, 2013 at 3:30 AM, Sylwester Nawrocki
sylvester.nawro...@gmail.com wrote:
On 03/06/2013 12:53 PM, Shaik Ameer Basha wrote:
This patch modifies the current fimc_pipeline to exynos_pipeline,
I think we could leave it as fimc_pipeline, exynos_pipeline seems
too generic to me.
no issues, if we are going to strict to this common pipeline implementation
definitely we can retain fimc_pipeline or we can use some other name which
is not too generic.
...
static int fimc_capture_hw_init(struct fimc_dev *fimc)
{
struct fimc_ctx *ctx = fimc-vid_cap.ctx;
- struct fimc_pipeline *p =fimc-pipeline;
+ struct exynos_pipeline *p =fimc-pipeline;
struct fimc_sensor_info *sensor;
unsigned long flags;
+ struct v4l2_subdev *sd;
int ret = 0;
- if (p-subdevs[IDX_SENSOR] == NULL || ctx == NULL)
+ sd = exynos_pipeline_get_subdev(fimc-pipeline_ops,
+ get_subdev_sensor, p);
Hmm, it feels it is going wrong path this way. I would keep changes
to the s5p-fimc driver as small as possible. And the modules that
are shared across the exynos4 and exynos5 driver should use generic
media graph walking routines where possible.
The only problem here is, the fimc_subdev_index enum is specific to
fimc-mdevice.
and why should we expose one particular media-device driver specific
enums to other drivers.
OK, I missed the point this enum is in a public header that would be
reused by other media drivers.
My Idea was to remove all media device specific structures, macros
from fimc, fimc-lite, mipi-csis and fimc-is drivers.
Of course we cannot remove them all, as video node drivers need be
able to control the pipeline. And I'm not very enthusiastic about
creating more dependencies between exynos4 and exynos5 drivers.
But I guess a common video pipeline object definition cannot be
avoided as FIMC-LITE is reused by exynos4 and exynos5 subsystems.
+ if (sd == NULL || ctx == NULL)
return -ENXIO;
if (ctx-s_frame.fmt == NULL)
return -EINVAL;
- sensor = v4l2_get_subdev_hostdata(p-subdevs[IDX_SENSOR]);
+ sensor = v4l2_get_subdev_hostdata(sd);
spin_lock_irqsave(fimc-slock, flags);
fimc_prepare_dma_offset(ctx,ctx-d_frame);
...
@@ -486,9 +491,12 @@ static struct vb2_ops fimc_capture_qops = {
int fimc_capture_ctrls_create(struct fimc_dev *fimc)
{
struct fimc_vid_cap *vid_cap =fimc-vid_cap;
- struct v4l2_subdev *sensor = fimc-pipeline.subdevs[IDX_SENSOR];
+ struct v4l2_subdev *sensor;
int ret;
+ sensor = exynos_pipeline_get_subdev(fimc-pipeline_ops,
+
get_subdev_sensor,fimc-pipeline);
+
if (WARN_ON(vid_cap-ctx == NULL))
return -ENXIO;
if (vid_cap-ctx-ctrls.ready)
@@ -513,7 +521,7 @@ static int fimc_capture_open(struct file *file)
dbg(pid: %d, state: 0x%lx, task_pid_nr(current), fimc-state);
- fimc_md_graph_lock(fimc);
+ exynos_pipeline_graph_lock(fimc-pipeline_ops,fimc-pipeline);
Hmm, this look pretty scary to me. But I suspect this change is not
needed at all. The graph lock is _not_ the pipeline lock. It protects
all media entities registered to the media device, and links between
them. Not only entities linked into specific video processing pipeline
at a moment.
Sorry, here the function name doesn't suits its implementation.
Actually exynos_pipeline_graph_lock() does what exactly
fimc_md_graph_lock() does.
I thought of having one common function across all the drivers to use
graph lock/unlock functionality.
I'm not convinced we need something like this at the exynos drivers
level. We could add something to the v4l2 core, e.g. functions taking
struct media_entity as an argument. No need for adding extra levels
of indirection.
-/* Called with the media graph mutex held */
-static struct v4l2_subdev *__find_remote_sensor(struct media_entity *me)
-{
- struct media_pad *pad =me-pads[0];
- struct v4l2_subdev *sd;
-
- while (pad-flags MEDIA_PAD_FL_SINK) {
- /* source pad */
- pad = media_entity_remote_source(pad);
- if (pad == NULL ||
- media_entity_type(pad-entity) !=
MEDIA_ENT_T_V4L2_SUBDEV)
- break;
-
- sd = media_entity_to_v4l2_subdev(pad-entity);
-
- if (sd-grp_id == GRP_ID_FIMC_IS_SENSOR)
- return sd;
-
[no subject]
bin7T9q2OarMG.bin Description: iso-8859-1
