RE: [PATCH v10 5/8] davinci vpbe: platform specific additions
Sergei,
On Thu, Dec 23, 2010 at 23:19:30, Sergei Shtylyov wrote:
Hello.
Manjunath Hadli wrote:
This patch implements the overall device creation for the Video
display driver
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
[...]
diff --git a/arch/arm/mach-davinci/dm644x.c
b/arch/arm/mach-davinci/dm644x.c index 9a2376b..eb87867 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -370,6 +370,7 @@ static struct platform_device dm644x_mdio_device = {
* soc description mux mode mode muxdbg
* reg offset mask mode
*/
+
Stray newline?
[...]
+static struct resource dm644x_venc_resources[] = {
+ /* venc registers io space */
+ {
+ .start = 0x01C72400,
+ .end= 0x01C72400 + 0x17f,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
[...]
+static struct resource dm644x_v4l2_disp_resources[] = {
+ {
+ .start = IRQ_VENCINT,
+ .end= IRQ_VENCINT,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = 0x01C724B8,
+ .end= 0x01C724B8 + 0x3,
+ .flags = IORESOURCE_MEM,
+ },
+};
Still intersects with dm644x_venc_resources[]. Is it intended?
Yes. We need one VENC register in the display ISR to check the field status.
I have reduced the access of the full range to only one reg.
static int __init dm644x_init_devices(void) {
if (!cpu_is_davinci_dm644x())
return 0;
- /* Add ccdc clock aliases */
- clk_add_alias(master, dm644x_ccdc_dev.name, vpss_master, NULL);
- clk_add_alias(slave, dm644x_ccdc_dev.name, vpss_slave, NULL);
platform_device_register(dm644x_edma_device);
-
Should've left this newline alone...
WBR, Sergei
--
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 v11 5/8] davinci vpbe: platform specific additions
This patch implements the overall device creation for the Video
display driver
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Muralidharan Karicheri m-kariche...@ti.com
Acked-by: Hans Verkuil hverk...@xs4all.nl
---
arch/arm/mach-davinci/dm644x.c | 167 +--
arch/arm/mach-davinci/include/mach/dm644x.h |4 +
2 files changed, 163 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 9a2376b..c2b42f4 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -618,6 +618,7 @@ static struct resource vpfe_resources[] = {
};
static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+
static struct resource dm644x_ccdc_resource[] = {
/* CCDC Base address */
{
@@ -654,6 +655,139 @@ void dm644x_set_vpfe_config(struct vpfe_config *cfg)
vpfe_capture_dev.dev.platform_data = cfg;
}
+static struct resource dm644x_osd_resources[] = {
+ {
+ .start = 0x01C72600,
+ .end= 0x01C72600 + 0x1ff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 dm644x_osd_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device dm644x_osd_dev = {
+ .name = VPBE_OSD_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_osd_resources),
+ .resource = dm644x_osd_resources,
+ .dev = {
+ .dma_mask = dm644x_osd_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = DM644X_VPBE,
+ },
+};
+
+static struct resource dm644x_venc_resources[] = {
+ /* venc registers io space */
+ {
+ .start = 0x01C72400,
+ .end= 0x01C72400 + 0x17f,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static u64 dm644x_venc_dma_mask = DMA_BIT_MASK(32);
+
+#define VPSS_CLKCTL 0x01C40044
+
+static void __iomem *vpss_clkctl_reg;
+
+/* TBD. Check what VENC_CLOCK_SEL settings for HDTV and EDTV */
+static int dm644x_venc_setup_clock(enum vpbe_enc_timings_type type, __u64 mode)
+{
+ int ret = 0;
+
+ if (NULL == vpss_clkctl_reg)
+ return -EINVAL;
+ switch (type) {
+ case VPBE_ENC_STD:
+ __raw_writel(0x18, vpss_clkctl_reg);
+ break;
+ case VPBE_ENC_DV_PRESET:
+ switch ((unsigned int)mode) {
+ case V4L2_DV_480P59_94:
+ case V4L2_DV_576P50:
+__raw_writel(0x19, vpss_clkctl_reg);
+ break;
+ case V4L2_DV_720P60:
+ case V4L2_DV_1080I60:
+ case V4L2_DV_1080P30:
+ /*
+* For HD, use external clock source since
+* HD requires higher clock rate
+*/
+ __raw_writel(0xa, vpss_clkctl_reg);
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ break;
+ default:
+ ret = -EINVAL;
+ }
+ return ret;
+}
+
+static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
+
+static struct resource dm644x_v4l2_disp_resources[] = {
+ {
+ .start = IRQ_VENCINT,
+ .end= IRQ_VENCINT,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = 0x01C724B8,
+ .end= 0x01C724B8 + 0x3,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device vpbe_v4l2_display = {
+ .name = vpbe-v4l2,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources),
+ .resource = dm644x_v4l2_disp_resources,
+ .dev = {
+ .dma_mask = vpbe_display_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
+struct venc_platform_data dm644x_venc_pdata = {
+ .venc_type = DM644X_VPBE,
+ .setup_clock= dm644x_venc_setup_clock,
+};
+
+static struct platform_device dm644x_venc_dev = {
+ .name = VPBE_VENC_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_venc_resources),
+ .resource = dm644x_venc_resources,
+ .dev = {
+ .dma_mask = dm644x_venc_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = dm644x_venc_pdata,
+ },
+};
+
+static u64 dm644x_vpbe_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device dm644x_vpbe_dev = {
+ .name = vpbe_controller,
+ .id = -1,
+ .dev = {
+ .dma_mask = dm644x_vpbe_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
Re: [RFC/PATCH] v4l: Add S5P MIPI-CSI2 interface subdev driver
On Thursday, December 23, 2010 20:26:15 Sylwester Nawrocki wrote: Add the v4l2 subdev/platform device driver for S5P SoC MIPI-CSI2 slave devices. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- Hello, this patch adds a v4l2 subdev/platform device driver for S5P SoC MIPI-CSI2 slave devices.On S5PVXXX SoC there might be up two MIPI-CSI channels. This driver creates for each channel a subdev instance which is intended to interwork with the s5pc-fimc host driver. I am going to post the patches for the s5p fimc driver in near future so it can be seen how the subdevs are used. We are looking forward to use the media controller framework with S5P SoC for camera devices control, since the SoC architecture is relatively complex and flexible in configuration. There are up to 4 camera host interfaces with scaler, rotator and color format converter, up to 2 MIPI-CSI2 interfaces and there are also available datapaths to and from up to 2 LCD controllers. Regards, -- Sylwester Nawrocki Samsung Poland RD Center --- drivers/media/video/Kconfig |8 + drivers/media/video/Makefile|1 + drivers/media/video/s5p-mipi_csis.c | 592 +++ 3 files changed, 601 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/s5p-mipi_csis.c diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index da08267..04441aa 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -732,6 +732,13 @@ config VIDEO_VIA_CAMERA Chrome9 chipsets. Currently only tested on OLPC xo-1.5 systems with ov7670 sensors. +config VIDEO_S5P_MIPI_CSIS + bool S5P MIPI-CSI2 slave iterface support Typo: 'interface' + depends on VIDEO_V4L2 + ---help--- + This is video4linux driver for MIPI CSI2 interfaces + in Samsung S5P SoCs. + config SOC_CAMERA tristate SoC camera support depends on VIDEO_V4L2 HAS_DMA I2C @@ -1000,6 +1007,7 @@ config VIDEO_SAMSUNG_S5P_FIMC depends on VIDEO_DEV VIDEO_V4L2 PLAT_S5P select VIDEOBUF_DMA_CONTIG select V4L2_MEM2MEM_DEV + select VIDEO_SAMSUNG_MIPI_CSIS help This is a v4l2 driver for the S5P camera interface (video postprocessor) diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 482f14b..8cc093f 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -164,6 +164,7 @@ obj-$(CONFIG_VIDEO_PXA27x)+= pxa_camera.o obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2) += sh_mobile_csi2.o obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)+= sh_mobile_ceu_camera.o obj-$(CONFIG_VIDEO_OMAP1)+= omap1_camera.o +obj-$(CONFIG_VIDEO_S5P_MIPI_CSIS)+= s5p-mipi_csis.o obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc/ obj-$(CONFIG_ARCH_DAVINCI) += davinci/ diff --git a/drivers/media/video/s5p-mipi_csis.c b/drivers/media/video/s5p-mipi_csis.c new file mode 100644 index 000..823f49f --- /dev/null +++ b/drivers/media/video/s5p-mipi_csis.c @@ -0,0 +1,592 @@ +/* + * Samsung S5P SoC series MIPI-CSI2 slave interface driver + * + * Copyright (c) 2010 Samsung Electronics Co., Ltd + * Contact: Sylwester Nawrocki, s.nawro...@samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/module.h +#include linux/kernel.h +#include linux/errno.h +#include linux/clk.h +#include linux/irq.h +#include linux/interrupt.h +#include linux/device.h +#include linux/platform_device.h +#include linux/slab.h +#include linux/io.h +#include linux/delay.h +#include linux/memory.h +#include linux/regulator/machine.h +#include linux/regulator/consumer.h +#include plat/csis.h + +#include linux/videodev2.h +#include media/v4l2-subdev.h + +static int debug; +module_param(debug, int, 0644); +MODULE_PARM_DESC(debug, Enable module debug trace. Set to 1 to enable.); + +#define MODULE_NAME s5p-mipi-csis + +/* Register map definition */ + +/* CSI global control. */ +#define S5P_CSIS_CTRL0x00 +#define S5P_CSIS_CTRL_DPDN_DEFAULT (0 31) +#define S5P_CSIS_CTRL_DPDN_SWAP (1 31) +#define S5P_CSIS_CTRL_ALIGN_32BIT(1 20) +#define S5P_CSIS_CTRL_UPDATE_SHADOW (1 16) +#define S5P_CSIS_CTRL_WCLK_EXTCLK(1 8) +#define S5P_CSIS_CTRL_RESET (1 4) +#define S5P_CSIS_CTRL_ENABLE (1 0) + +/* D-PHY control. */ +#define S5P_CSIS_DPHYCTRL0x04 +#define S5P_CSIS_DPHYCTRL_HSS_MASK (0x1F 27) +#define S5P_CSIS_DPHYCTRL_ENABLE (0x1F 0) + +#define S5P_CSIS_CONFIG 0x08 +#define S5P_CSIS_CFG_FMT_YCBCR422_8BIT (0x1E 2) +#define
Re: RFC: V4L2 driver for Qualcomm MSM camera.
Good to hear from Qualcomm! I've made some comments below: On Thursday, December 23, 2010 20:38:04 Shuzhen Wang wrote: Hello, This is the architecture overview we put together for Qualcomm MSM camera support in linux-media tree. Your comments are very much appreciated! Introduction This is the video4linux driver for Qualcomm MSM (Mobile Station Modem) camera. The driver supports video and camera functionality on Qualcomm MSM SoC. It supports camera sensors provided by OEMs with parallel/MIPI interfaces, and operates in continuous streaming, snapshot, or video recording modes. Hardware description MSM camera hardware contains the following components: 1. One or more camera sensors controlled via I2C bus, and data outputs on AXI or MIPI bus. 2. Video Front End (VFE) core is an image signal processing hardware pipeline that takes the sensor output, does the necessary processing, and outputs to a buffer for V4L2 application. VFE is clocked by PCLK (pixel clock) from the sensor. Software description The driver encapsulates the low-level hardware management and aligns the interface to V4L2 driver framework. There is also a user space camera service daemon which handles events from driver and changes settings accordingly. During boot-up, the sensor is probed for and if the probe succeeds /dev/video0 and /dev/msm_camera/config0 device nodes are created. The /dev/video0 node is used for video buffer allocation in the kernel and for receiving V4L2 ioctls for controlling the camera hardware (VFE, sensors). The /dev/msm_camera/config0 node is used for sending commands and other statistics available from the hardware to the camera service daemon. Note that if more than one camera sensor is detected, there will be /dev/video1 and /dev/msm_camera/config1 device nodes created as well. Does config control the sensor or the main msm subsystem? Or both? Design == For MSM camera IC, significant portion of image processing and optimization codes are proprietary, so they cannot sit in kernel space. This plays an important role when making design decisions. Our design is to have a light-weighted kernel driver, and put the proprietary code in a user space daemon. The daemon polls on events from /dev/msm_camera/config0 device in the form of v4l2_event. The events could either be asynchronous (generated by the hardware), or synchronous (control command from the application). Based on the events it receives, the daemon will send appropriate control commands to the hardware. +-+++ | Application || Service Daemon | +-+++ User Space .. +--+ Kernel Space |V4L2 | +--+ +-+ ++ +---+ | VFE/ISP | | Sensor | | Flash | +-+ ++ +---+ Just to repeat what I have discussed with Qualcomm before (so that everyone knows): I have no problem with proprietary code as long as: 1) the hardware and driver APIs are clearly documented allowing someone else to make their own algorithms. 2) the initial state of the hardware as set up by the driver is good enough to capture video in normal lighting conditions. In other words: the daemon should not be needed for testing the driver. I compare this with cheap webcams that often need software white balancing to get a decent picture. They still work without that, but the picture simply doesn't look very good. We also discussed the daemon in the past. The idea was that it should be called from libv4l2. Is this still the plan? Power Management None at this point. SMP/multi-core == Mutex is used for synchronization of threads accessing the driver simultaneously. Between hardware interrupt handler and threads, we use spinlock to make sure locking is done properly. Take a look at the new core-assisted locking scheme implemented for 2.6.37. This might simplify your driver. Just FYI. Security None. Interface = The driver uses V4L2 API for user kernel interaction. Refer to http://v4l2spec.bytesex.org/spec-single/v4l2.html. That's really, really old. This is much more up to date: http://linuxtv.org/downloads/v4l-dvb-apis/ And the very latest build every day is always available here: http://www.xs4all.nl/~hverkuil/spec/media.html Between camera service daemon and the driver, we have customized IOCTL commands associated with /dev/msm_camera/config0 node, that controls MSM camera hardware. The list of IOCTLs are (declarations can be found in include/media/msm_camera.h): MSM_CAM_IOCTL_GET_SENSOR_INFO Get the basic information such as name, flash
Re: [RFC/PATCH v7 01/12] media: Media device node support
Hi Greg,
Thank you for the review.
On Thursday 23 December 2010 04:32:53 Greg KH wrote:
On Mon, Dec 20, 2010 at 12:36:24PM +0100, Laurent Pinchart wrote:
The media_devnode structure provides support for registering and
unregistering character devices using a dynamic major number. Reference
counting is handled internally, making device drivers easier to write
without having to solve the open/disconnect race condition issue over
and over again.
What race condition are you referring to?
In a nutshell, the race between device disconnection, which results in the
device instance being delete (if not in use of course), and open() calls from
userspace. The problem has been solved in V4L a couple of releases ago after
suffering from this race for a too long time. As V4L devices (and now media
devices) need to create both a struct device and a struct cdev instance,
careful locking is needed.
+config MEDIA_CONTROLLER
+ bool Media Controller API (EXPERIMENTAL)
+ depends on EXPERIMENTAL
+ ---help---
+ Enable the media controller API used to query media devices internal
+ topology and configure it dynamically.
+
+ This API is mostly used by camera interfaces in embedded platforms.
That's nice, but why should I enable this? Or will drivers enable it
automatically?
Drivers depending on the media controller API will enable this, yes. The
option will probably removed later when the API won't be deemed as
experimental anymore.
+#define MEDIA_NUM_DEVICES 256
Why this limit?
Because I'm using a bitmap to store the used minor numbers, and I thus need a
limit. I could get rid of it of it by using a linked list, but that will not
be efficient (you could argue that the list will hold a few entries only most
of the time, but in that case a limit of 256 minors wouldn't be a problem
:-)).
+#define MEDIA_NAME media
Are you sure this is a good name for a camera?
It's not just camera. Media devices are... well, media devices. Basically
anything that can handle audio and/or video streams. The media controller API
can be used by plain audio devices.
+static dev_t media_dev_t;
Only one major number? Is it always dynamic?
Yes, one major and (for now) 256 minors. Is there a problem with it being
dynamic ?
+
+/*
+ * Active devices
+ */
+static DEFINE_MUTEX(media_devnode_lock);
+static DECLARE_BITMAP(media_devnode_nums, MEDIA_NUM_DEVICES);
+
+/* Called when the last user of the media device exits. */
+static void media_devnode_release(struct device *cd)
+{
+ struct media_devnode *mdev = to_media_devnode(cd);
+
+ mutex_lock(media_devnode_lock);
+
+ /* Delete the cdev on this minor as well */
+ cdev_del(mdev-cdev);
+
+ /* Mark device node number as free */
+ clear_bit(mdev-minor, media_devnode_nums);
+
+ mutex_unlock(media_devnode_lock);
+
+ /* Release media_devnode and perform other cleanups as needed. */
+ if (mdev-release)
+ mdev-release(mdev);
+}
You forgot to free the device structure here as well, right?
That will be done by the release callback. The media_devnode structure is
embedded in the media_device structure, which will be embedded in driver-
specific structures.
+static ssize_t media_read(struct file *filp, char __user *buf,
+ size_t sz, loff_t *off)
+{
+ struct media_devnode *mdev = media_devnode_data(filp);
+
+ if (!mdev-fops-read)
+ return -EINVAL;
+ if (!media_devnode_is_registered(mdev))
+ return -EIO;
How could this happen?
This can happen when a USB device is disconnected for instance.
And are you sure -EIO is correct?
-ENXIO is probably better (I always confuse that with -ENODEV).
+ return mdev-fops-read(filp, buf, sz, off);
+}
+
+static ssize_t media_write(struct file *filp, const char __user *buf,
+ size_t sz, loff_t *off)
+{
+ struct media_devnode *mdev = media_devnode_data(filp);
+
+ if (!mdev-fops-write)
+ return -EINVAL;
+ if (!media_devnode_is_registered(mdev))
+ return -EIO;
Same as above, and same comment in other places (poll, ioctl.)
OK.
+/* Override for the open function */
+static int media_open(struct inode *inode, struct file *filp)
+{
+ struct media_devnode *mdev;
+ int ret;
+
+ /* Check if the media device is available. This needs to be done with
+* the media_devnode_lock held to prevent an open/unregister race:
+* without the lock, the device could be unregistered and freed between
+* the media_devnode_is_registered() and get_device() calls, leading to
+* a crash.
+*/
+ mutex_lock(media_devnode_lock);
+ mdev = container_of(inode-i_cdev, struct media_devnode, cdev);
By virtue of having the reference to the module held by the vfs, this
shouldn't ever go away, even if the lock is not held.
inode-i_cdev is set to NULL by
Re: [RFC/PATCH v7 02/12] media: Media device
Hi Greg, Thanks for the review. On Thursday 23 December 2010 04:33:46 Greg KH wrote: On Mon, Dec 20, 2010 at 12:36:25PM +0100, Laurent Pinchart wrote: The media_device structure abstracts functions common to all kind of media devices (v4l2, dvb, alsa, ...). It manages media entities and offers a userspace API to discover and configure the media device internal topology. As you create sysfs files, please also create Documentation/ABI/ entries for those sysfs files at the same time. Sorry for having forgotten that. I will fix it. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma_declare_coherent_memory: push ioremap() up to caller
On Fri, Dec 24, 2010 at 12:20:32AM +0100, Janusz Krzysztofik wrote: The patch tries to implement a solution suggested by Russell King, http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/035264.html. It is expected to solve video buffer allocation issues for at least a few soc_camera I/O memory less host interface drivers, designed around the videobuf_dma_contig layer, which allocates video buffers using dma_alloc_coherent(). Created against linux-2.6.37-rc5. Tested on ARM OMAP1 based Amstrad Delta with a WIP OMAP1 camera patch, patterned upon two mach-mx3 machine types which already try to use the dma_declare_coherent_memory() method for reserving a region of system RAM preallocated with another dma_alloc_coherent(). Compile tested for all modified files except arch/sh/drivers/pci/fixups-dreamcast.c. Another note: with the pair of patches I've sent to the linux-arm-kernel list earlier today changing the DMA coherent allocator to steal memory from the system at boot. This means there's less need to pre-allocate DMA memory - if there's sufficient contiguous space in the DMA region to satisfy the allocation, then the allocation will succeed. It's also independent of the maximum page size from the kernel's memory allocators too. So I suspect that mach-mx3 (and others) no longer need to do their own pre-allocation anymore if both of these patches go in. -- 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
Removal of V4L1 drivers
Hi Hans, Mauro, The se401, vicam, ibmcam and konicawc drivers are the only V4L1 drivers left in 2.6.37. The others are either converted or moved to staging (stradis and cpia), ready to be removed. Hans, what is the status of those four drivers? How likely is it that they will be converted to V4L2? If we can't convert them to V4L2 for 2.6.38, then we can at least remove the V4L1_COMPAT code throughout the v4l drivers and move those four drivers to staging. For 2.6.39 we either remove them or when they are converted to V4L2 they are moved out of staging again (probably to gspca). As an illustration I have removed the V4L1_COMPAT mode in this branch: http://git.linuxtv.org/hverkuil/media_tree.git?a=shortlog;h=refs/heads/v4l1 There are two drivers that need more work: stk-webcam has some controls under sysfs that are enabled when CONFIG_VIDEO_V4L1_COMPAT is set. These controls should be rewritten as V4L2 controls. Hans, didn't you have hardware to test this driver? I should be able to make a patch that you can test. The other driver is the zoran driver which has a bunch of zoran-specific ioctls under CONFIG_VIDEO_V4L1_COMPAT. I think I can just delete the lot since they are all replaced by V4L2 counterparts AFAIK. But it would be good if someone else can also take a look at that. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dma_declare_coherent_memory: push ioremap() up to caller
Friday 24 December 2010 14:02:00 Russell King - ARM Linux wrote: On Fri, Dec 24, 2010 at 12:20:32AM +0100, Janusz Krzysztofik wrote: The patch tries to implement a solution suggested by Russell King, http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December /035264.html. It is expected to solve video buffer allocation issues for at least a few soc_camera I/O memory less host interface drivers, designed around the videobuf_dma_contig layer, which allocates video buffers using dma_alloc_coherent(). Created against linux-2.6.37-rc5. Tested on ARM OMAP1 based Amstrad Delta with a WIP OMAP1 camera patch, patterned upon two mach-mx3 machine types which already try to use the dma_declare_coherent_memory() method for reserving a region of system RAM preallocated with another dma_alloc_coherent(). Compile tested for all modified files except arch/sh/drivers/pci/fixups-dreamcast.c. Another note: with the pair of patches I've sent to the linux-arm-kernel list earlier today changing the DMA coherent allocator to steal memory from the system at boot. This means there's less need to pre-allocate DMA memory - if there's sufficient contiguous space in the DMA region to satisfy the allocation, then the allocation will succeed. It's also independent of the maximum page size from the kernel's memory allocators too. So I suspect that mach-mx3 (and others) no longer need to do their own pre-allocation anymore if both of these patches go in. Then, my rationale will no longer be valid. So, either drop my patch if you think you have finally come out with a better solution which doesn't touch any system-wide API, or suggest a new justification for use in the commit log if you think still the patch solves something important. Thanks, Janusz -- 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: nasty bug at qv4l2
Hi, On 12/22/2010 12:30 PM, Mauro Carvalho Chehab wrote: Hans V/Hans G, There's a nasty bug at qv4l2 or at libv4l: it is not properly updating all info, if you change the video device. On my tests with uvcvideo (video0) and a gspca camera (pac7302, video1), it was showing the supported formats for the uvcvideo camera when I changed from video0 to video1. The net result is that the image were handled with the wrong decoder (instead of using fourcc V4L2_PIX_FMT_PJPG, it were using BGR3), producing a wrong decoding. Could you please take a look on it? I'm pretty sure this is not a libv4l issue (other apps which allows witching the source work fine), but rather a qv4l2 problem, esp. as it uses libv4lconvert directly rather then going through libv4l (iirc). Hans V, can you take a look at this? 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: nasty bug at qv4l2
On Friday, December 24, 2010 15:19:26 Hans de Goede wrote: Hi, On 12/22/2010 12:30 PM, Mauro Carvalho Chehab wrote: Hans V/Hans G, There's a nasty bug at qv4l2 or at libv4l: it is not properly updating all info, if you change the video device. On my tests with uvcvideo (video0) and a gspca camera (pac7302, video1), it was showing the supported formats for the uvcvideo camera when I changed from video0 to video1. The net result is that the image were handled with the wrong decoder (instead of using fourcc V4L2_PIX_FMT_PJPG, it were using BGR3), producing a wrong decoding. Could you please take a look on it? I'm pretty sure this is not a libv4l issue (other apps which allows witching the source work fine), but rather a qv4l2 problem, esp. as it uses libv4lconvert directly rather then going through libv4l (iirc). And I'm pretty sure it isn't a qv4l2 issue :-) For the record: qv4l2 can open a device node either in 'raw' mode bypassing libv4l and using v4lconvert to convert unsupported pixformats, or in 'wrapped' mode where libv4l is used for all device node accesses. Hans V, can you take a look at this? Not until I am back to Oslo at the beginning of January as all my webcams are there. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: nasty bug at qv4l2
Hi, On 12/24/2010 03:20 PM, Hans Verkuil wrote: On Friday, December 24, 2010 15:19:26 Hans de Goede wrote: Hi, On 12/22/2010 12:30 PM, Mauro Carvalho Chehab wrote: Hans V/Hans G, There's a nasty bug at qv4l2 or at libv4l: it is not properly updating all info, if you change the video device. On my tests with uvcvideo (video0) and a gspca camera (pac7302, video1), it was showing the supported formats for the uvcvideo camera when I changed from video0 to video1. The net result is that the image were handled with the wrong decoder (instead of using fourcc V4L2_PIX_FMT_PJPG, it were using BGR3), producing a wrong decoding. Could you please take a look on it? I'm pretty sure this is not a libv4l issue (other apps which allows witching the source work fine), but rather a qv4l2 problem, esp. as it uses libv4lconvert directly rather then going through libv4l (iirc). And I'm pretty sure it isn't a qv4l2 issue :-) For the record: qv4l2 can open a device node either in 'raw' mode bypassing libv4l and using v4lconvert to convert unsupported pixformats, or in 'wrapped' mode where libv4l is used for all device node accesses. Interesting, how does it switch between the modes? Mauro were you using wrapped mode or raw mode when you saw this ? 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: Removal of V4L1 drivers
Hi, On 12/24/2010 02:42 PM, Hans Verkuil wrote: Hi Hans, Mauro, The se401, vicam, ibmcam and konicawc drivers are the only V4L1 drivers left in 2.6.37. The others are either converted or moved to staging (stradis and cpia), ready to be removed. Hans, what is the status of those four drivers? se401: I have hardware I have taken a look at the driver, converting it is a bit of a pain because it uses a really ugly written statefull decompressor inside the kernel code. The cameras have an uncompressed mode too. I can start doing a conversion to / rewrite as gspca subdriver supporting only the uncompressed mode for now: vicam: Devin Heitmueller (added to the CC) has one such a camera, which he still needs to get into my hands, once I have it I can convert the driver. ibmcam and konicawc: Both drivers were converted by me recently and the new gspca subdrivers for these have been pulled by Mauro for 2.6.37 . snip There are two drivers that need more work: stk-webcam has some controls under sysfs that are enabled when CONFIG_VIDEO_V4L1_COMPAT is set. These controls should be rewritten as V4L2 controls. Hans, didn't you have hardware to test this driver? No I don't have any Syntek DC1125 based webcams. snip 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: [PATCH] dma_declare_coherent_memory: push ioremap() up to caller
On Fri, Dec 24, 2010 at 02:55:25PM +0100, Janusz Krzysztofik wrote: Friday 24 December 2010 14:02:00 Russell King - ARM Linux wrote: On Fri, Dec 24, 2010 at 12:20:32AM +0100, Janusz Krzysztofik wrote: The patch tries to implement a solution suggested by Russell King, http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December /035264.html. It is expected to solve video buffer allocation issues for at least a few soc_camera I/O memory less host interface drivers, designed around the videobuf_dma_contig layer, which allocates video buffers using dma_alloc_coherent(). Created against linux-2.6.37-rc5. Tested on ARM OMAP1 based Amstrad Delta with a WIP OMAP1 camera patch, patterned upon two mach-mx3 machine types which already try to use the dma_declare_coherent_memory() method for reserving a region of system RAM preallocated with another dma_alloc_coherent(). Compile tested for all modified files except arch/sh/drivers/pci/fixups-dreamcast.c. Another note: with the pair of patches I've sent to the linux-arm-kernel list earlier today changing the DMA coherent allocator to steal memory from the system at boot. This means there's less need to pre-allocate DMA memory - if there's sufficient contiguous space in the DMA region to satisfy the allocation, then the allocation will succeed. It's also independent of the maximum page size from the kernel's memory allocators too. So I suspect that mach-mx3 (and others) no longer need to do their own pre-allocation anymore if both of these patches go in. Then, my rationale will no longer be valid. So, either drop my patch if you think you have finally come out with a better solution which doesn't touch any system-wide API, or suggest a new justification for use in the commit log if you think still the patch solves something important. No. It's not clear whether my pair of patches are both going to make it into the kernel, or even what timeframe they're going to make it in. Irrespective of that, we do need a solution to this problem so that this stuff starts working again. In any case, your patch makes complete sense through and through: 1. if other architecture/machine wants to reserve a chunk of DMA-able memory for a specific device (eg, because of a restriction on the number of DMA address bits available) and it's completely DMA coherent, it shouldn't have to go through the pains of having that memory unconditionally ioremap'd. 2. What if the memory being provided from some source where you already have the mapping setup in a specific way for a reason? For example, say I have an ARM design, and all peripherals are in a single 256MB memory region, which includes a chunk of SRAM set aside for DMA purposes. Let's say I can map that really efficiently by a few page table entries, which means relatively little TLB usage for accessing this region. With the current API, it becomes difficult to pass that mapping through the dma_declare_coherent_memory() because the physical address goes through ioremap(), which obfuscates what's going on. However, if I could pass the bus and virtual address, then there's no ambiguity over what I want to do. What if I want to declare memory to the DMA coherent allocator with attributes different from what ioremap() gives me, maybe with write combining properties (because it happens to be safe for the specific device) ? Passing the virtual address allows the API to become much more flexible. Not only that, it allows it to be used on ARM, rather than becoming (as it currently stands) prohibited on ARM. I believe that putting ioremap() inside this API was the wrong thing to do, and moving it outside makes the API much more flexible and usable. It's something I still fully support. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Dec 24 19:00:29 CET 2010 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS 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: nasty bug at qv4l2
On Friday, December 24, 2010 15:41:10 Hans de Goede wrote: Hi, On 12/24/2010 03:20 PM, Hans Verkuil wrote: On Friday, December 24, 2010 15:19:26 Hans de Goede wrote: Hi, On 12/22/2010 12:30 PM, Mauro Carvalho Chehab wrote: Hans V/Hans G, There's a nasty bug at qv4l2 or at libv4l: it is not properly updating all info, if you change the video device. On my tests with uvcvideo (video0) and a gspca camera (pac7302, video1), it was showing the supported formats for the uvcvideo camera when I changed from video0 to video1. The net result is that the image were handled with the wrong decoder (instead of using fourcc V4L2_PIX_FMT_PJPG, it were using BGR3), producing a wrong decoding. Could you please take a look on it? I'm pretty sure this is not a libv4l issue (other apps which allows witching the source work fine), but rather a qv4l2 problem, esp. as it uses libv4lconvert directly rather then going through libv4l (iirc). And I'm pretty sure it isn't a qv4l2 issue :-) For the record: qv4l2 can open a device node either in 'raw' mode bypassing libv4l and using v4lconvert to convert unsupported pixformats, or in 'wrapped' mode where libv4l is used for all device node accesses. Interesting, how does it switch between the modes? In the File menu there is an entry Open device (uses libv4l) and Open raw device (opens the device node directly). Depending on how the device is opened, all calls to the device node either go through libv4l or are direct system calls. Mauro were you using wrapped mode or raw mode when you saw this ? The button on the toolbar will always use libv4l. But if you add the device node on the command line (e.g. qv4l2 /dev/video0), then it will open the device node in raw mode. That's rather inconsistent and it should also use libv4l. I've just fixed this: 'qv4l2 /dev/video0' will now also use libv4l. If you want to test a device node bypassing libv4l, then you have to open the device node using Open raw device in the File menu. I wonder if Mauro got confused by the different behavior as well. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Removal of V4L1 drivers
On Friday, December 24, 2010 15:47:57 Hans de Goede wrote: Hi, On 12/24/2010 02:42 PM, Hans Verkuil wrote: Hi Hans, Mauro, The se401, vicam, ibmcam and konicawc drivers are the only V4L1 drivers left in 2.6.37. The others are either converted or moved to staging (stradis and cpia), ready to be removed. Hans, what is the status of those four drivers? se401: I have hardware I have taken a look at the driver, converting it is a bit of a pain because it uses a really ugly written statefull decompressor inside the kernel code. The cameras have an uncompressed mode too. I can start doing a conversion to / rewrite as gspca subdriver supporting only the uncompressed mode for now: vicam: Devin Heitmueller (added to the CC) has one such a camera, which he still needs to get into my hands, once I have it I can convert the driver. I think these two should be moved to staging for 2.6.38. And either removed or converted for 2.6.39. ibmcam and konicawc: Both drivers were converted by me recently and the new gspca subdrivers for these have been pulled by Mauro for 2.6.37 . So these two can be removed in 2.6.38, right? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cx88-dvb.c: DVB net latency using Hauppauge HVR4000
will your patch useful for dvb sat tv ? We are from School On Internet Asia (SOI Asia) project that uses satellite communication to deliver educational content. We used Hauppauge HVR 4000 to carry IP traffic over ULE. However, there is an issue with high latency jitter. My boss, Husni, identified the problem and provided a patch for this problem. We have tested this patch since kernel 2.6.30 on our partner sites and it hasn't cause any issue. The default buffer size of 32 TS frames on cx88 causes the high latency, so our deployment changes that to 6 TS frames. This patch made the buffer size tunable, while keeping the default buffer size of 32 TS frames unchanged. Sorry, I have to use attachment for the patch. I couldn't figure out how to copy and paste the patch without converting the tab to spaces in thunderbird. -- 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] Adds the Lego Bionicle to existing sq905c
This patch adds the Vendor:Product number of the Lego Bionicle camera to
the existing gspca/sq905c.c and also a line for the camera in gspca.txt.
The camera works out of the box with these small changes. So this is
just in time for Christmas. Think of the children.
Signed-off-by: Theodore Kilgore kilg...@auburn.edu
-
diff --git a/Documentation/video4linux/gspca.txt
b/Documentation/video4linux/gspca.txt
index 6a562ee..261776e 100644
--- a/Documentation/video4linux/gspca.txt
+++ b/Documentation/video4linux/gspca.txt
@@ -366,6 +366,7 @@ t61317a1:0128 TASCORP JPEG Webcam,
NGS Cyclops
vc032x 17ef:4802 Lenovo Vc0323+MI1310_SOC
pac207 2001:f115 D-Link DSB-C120
sq905c 2770:9050 Disney pix micro (CIF)
+sq905c 2770:9051 Lego Bionicle
sq905c 2770:9052 Disney pix micro 2 (VGA)
sq905c 2770:905c All 11 known cameras with this ID
sq905 2770:9120 All 24 known cameras with this ID
diff --git a/drivers/media/video/gspca/sq905c.c
b/drivers/media/video/gspca/sq905c.c
index c2e88b5..8ba1995 100644
--- a/drivers/media/video/gspca/sq905c.c
+++ b/drivers/media/video/gspca/sq905c.c
@@ -301,6 +301,7 @@ static int sd_start(struct gspca_dev *gspca_dev)
static const __devinitdata struct usb_device_id device_table[] = {
{USB_DEVICE(0x2770, 0x905c)},
{USB_DEVICE(0x2770, 0x9050)},
+ {USB_DEVICE(0x2770, 0x9051)},
{USB_DEVICE(0x2770, 0x9052)},
{USB_DEVICE(0x2770, 0x913d)},
{}
--
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: Removal of V4L1 drivers
Hi, On 12/24/2010 07:58 PM, Hans Verkuil wrote: On Friday, December 24, 2010 15:47:57 Hans de Goede wrote: Hi, On 12/24/2010 02:42 PM, Hans Verkuil wrote: Hi Hans, Mauro, The se401, vicam, ibmcam and konicawc drivers are the only V4L1 drivers left in 2.6.37. The others are either converted or moved to staging (stradis and cpia), ready to be removed. Hans, what is the status of those four drivers? se401: I have hardware I have taken a look at the driver, converting it is a bit of a pain because it uses a really ugly written statefull decompressor inside the kernel code. The cameras have an uncompressed mode too. I can start doing a conversion to / rewrite as gspca subdriver supporting only the uncompressed mode for now: vicam: Devin Heitmueller (added to the CC) has one such a camera, which he still needs to get into my hands, once I have it I can convert the driver. I think these two should be moved to staging for 2.6.38. And either removed or converted for 2.6.39. Ok. ibmcam and konicawc: Both drivers were converted by me recently and the new gspca subdrivers for these have been pulled by Mauro for 2.6.37 . So these two can be removed in 2.6.38, right? Right. 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: [PATCH] Adds the Lego Bionicle to existing sq905c
Mauro,
Will you pick up this patch directly or should I put it in my tree ?
Regards,
Hans
On 12/24/2010 09:06 PM, Theodore Kilgore wrote:
This patch adds the Vendor:Product number of the Lego Bionicle camera to
the existing gspca/sq905c.c and also a line for the camera in gspca.txt.
The camera works out of the box with these small changes. So this is
just in time for Christmas. Think of the children.
Signed-off-by: Theodore Kilgorekilg...@auburn.edu
-
diff --git a/Documentation/video4linux/gspca.txt
b/Documentation/video4linux/gspca.txt
index 6a562ee..261776e 100644
--- a/Documentation/video4linux/gspca.txt
+++ b/Documentation/video4linux/gspca.txt
@@ -366,6 +366,7 @@ t61317a1:0128 TASCORP JPEG Webcam,
NGS Cyclops
vc032x17ef:4802 Lenovo Vc0323+MI1310_SOC
pac2072001:f115 D-Link DSB-C120
sq905c2770:9050 Disney pix micro (CIF)
+sq905c 2770:9051 Lego Bionicle
sq905c2770:9052 Disney pix micro 2 (VGA)
sq905c2770:905c All 11 known cameras with this ID
sq905 2770:9120 All 24 known cameras with this ID
diff --git a/drivers/media/video/gspca/sq905c.c
b/drivers/media/video/gspca/sq905c.c
index c2e88b5..8ba1995 100644
--- a/drivers/media/video/gspca/sq905c.c
+++ b/drivers/media/video/gspca/sq905c.c
@@ -301,6 +301,7 @@ static int sd_start(struct gspca_dev *gspca_dev)
static const __devinitdata struct usb_device_id device_table[] = {
{USB_DEVICE(0x2770, 0x905c)},
{USB_DEVICE(0x2770, 0x9050)},
+ {USB_DEVICE(0x2770, 0x9051)},
{USB_DEVICE(0x2770, 0x9052)},
{USB_DEVICE(0x2770, 0x913d)},
{}
--
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
opinions about non-page-aligned buffers?
Hi all, The request has come up on OMAP4 to support non-page-aligned v4l2 buffers. (This is in context of v4l2 display, but the same reasons would apply for a camera.) For most common resolutions, this would help us get much better memory utilization for a range of memory (or rather address space) used for YUV buffers. However it would require a small change in the client application, since most (all) v4l2 apps that I have seen are assuming the offsets they are given to mmap are page aligned. I am curious if anyone has any suggestions about how to enable this. Ideally it would be some sort of opt-in feature to avoid breaking apps that are not aware the the offsets to mmap may not be page aligned. BR, -R -- 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] dma_declare_coherent_memory: push ioremap() up to caller
Friday 24 December 2010 16:41:20 Russell King - ARM Linux napisał(a): On Fri, Dec 24, 2010 at 02:55:25PM +0100, Janusz Krzysztofik wrote: Friday 24 December 2010 14:02:00 Russell King - ARM Linux wrote: On Fri, Dec 24, 2010 at 12:20:32AM +0100, Janusz Krzysztofik wrote: The patch tries to implement a solution suggested by Russell King, http://lists.infradead.org/pipermail/linux-arm-kernel/2010-Dece mber /035264.html. It is expected to solve video buffer allocation issues for at least a few soc_camera I/O memory less host interface drivers, designed around the videobuf_dma_contig layer, which allocates video buffers using dma_alloc_coherent(). Created against linux-2.6.37-rc5. Tested on ARM OMAP1 based Amstrad Delta with a WIP OMAP1 camera patch, patterned upon two mach-mx3 machine types which already try to use the dma_declare_coherent_memory() method for reserving a region of system RAM preallocated with another dma_alloc_coherent(). Compile tested for all modified files except arch/sh/drivers/pci/fixups-dreamcast.c. Another note: with the pair of patches I've sent to the linux-arm-kernel list earlier today changing the DMA coherent allocator to steal memory from the system at boot. This means there's less need to pre-allocate DMA memory - if there's sufficient contiguous space in the DMA region to satisfy the allocation, then the allocation will succeed. It's also independent of the maximum page size from the kernel's memory allocators too. So I suspect that mach-mx3 (and others) no longer need to do their own pre-allocation anymore if both of these patches go in. Then, my rationale will no longer be valid. So, either drop my patch if you think you have finally come out with a better solution which doesn't touch any system-wide API, or suggest a new justification for use in the commit log if you think still the patch solves something important. No. It's not clear whether my pair of patches are both going to make it into the kernel, or even what timeframe they're going to make it in. Irrespective of that, we do need a solution to this problem so that this stuff starts working again. In any case, your patch makes complete sense through and through: 1. if other architecture/machine wants to reserve a chunk of DMA-able memory for a specific device (eg, because of a restriction on the number of DMA address bits available) and it's completely DMA coherent, it shouldn't have to go through the pains of having that memory unconditionally ioremap'd. 2. What if the memory being provided from some source where you already have the mapping setup in a specific way for a reason? For example, say I have an ARM design, and all peripherals are in a single 256MB memory region, which includes a chunk of SRAM set aside for DMA purposes. Let's say I can map that really efficiently by a few page table entries, which means relatively little TLB usage for accessing this region. With the current API, it becomes difficult to pass that mapping through the dma_declare_coherent_memory() because the physical address goes through ioremap(), which obfuscates what's going on. However, if I could pass the bus and virtual address, then there's no ambiguity over what I want to do. What if I want to declare memory to the DMA coherent allocator with attributes different from what ioremap() gives me, maybe with write combining properties (because it happens to be safe for the specific device) ? Passing the virtual address allows the API to become much more flexible. Not only that, it allows it to be used on ARM, rather than becoming (as it currently stands) prohibited on ARM. I believe that putting ioremap() inside this API was the wrong thing to do, and moving it outside makes the API much more flexible and usable. It's something I still fully support. Thanks, this is what I was missing, having my point of view rather my machine centric, with not much wider experience. I'll quote your argumentation in next iteration of this patch if required. Thanks, Janusz -- 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: opinions about non-page-aligned buffers?
On Friday, December 24, 2010 22:29:37 Rob Clark wrote: Hi all, The request has come up on OMAP4 to support non-page-aligned v4l2 buffers. (This is in context of v4l2 display, but the same reasons would apply for a camera.) For most common resolutions, this would help us get much better memory utilization for a range of memory (or rather address space) used for YUV buffers. Can you explain this in more detail? I don't really see how non-page aligned buffers would lead to 'much better' memory usage. I would expect that the best savings you could achieve would be PAGE_SIZE-1 per buffer. Regards, Hans However it would require a small change in the client application, since most (all) v4l2 apps that I have seen are assuming the offsets they are given to mmap are page aligned. I am curious if anyone has any suggestions about how to enable this. Ideally it would be some sort of opt-in feature to avoid breaking apps that are not aware the the offsets to mmap may not be page aligned. BR, -R -- 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 -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: opinions about non-page-aligned buffers?
On Fri, Dec 24, 2010 at 5:32 PM, Hans Verkuil hverk...@xs4all.nl wrote: On Friday, December 24, 2010 22:29:37 Rob Clark wrote: Hi all, The request has come up on OMAP4 to support non-page-aligned v4l2 buffers. (This is in context of v4l2 display, but the same reasons would apply for a camera.) For most common resolutions, this would help us get much better memory utilization for a range of memory (or rather address space) used for YUV buffers. Can you explain this in more detail? I don't really see how non-page aligned buffers would lead to 'much better' memory usage. I would expect that the best savings you could achieve would be PAGE_SIZE-1 per buffer. Due to how the buffers are mapped, the savings is actually quite substantial. What actually happens is the region of memory that the buffers are allocated from has a stride of 16kb or 32kb. (For NV12, Y has a 16kb stride, and UV is disjoint is a 32kb stride.) To keep things somewhat sane for userspace, the Y followed by UV gets mmap'd into consecutive 4kb pages. So we are actually loosing 1.5 * (4kb - width) per buffer by forcing page alignment. With non page-aligned buffers we can pack buffers next to each other, ie. so one buffer may exist within the stride of another buffer. BR, -R Regards, Hans However it would require a small change in the client application, since most (all) v4l2 apps that I have seen are assuming the offsets they are given to mmap are page aligned. I am curious if anyone has any suggestions about how to enable this. Ideally it would be some sort of opt-in feature to avoid breaking apps that are not aware the the offsets to mmap may not be page aligned. BR, -R -- 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 -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
