Re: [RFC] vtunerc - virtual DVB device driver
Em 22-06-2011 16:18, Rémi Denis-Courmont escreveu: > Le mercredi 22 juin 2011 15:17:27 Mauro Carvalho Chehab, vous avez écrit : >>> My very little opinion is that waving GPL is way to the hell. Nobody told >>> me why similar technologies, in different kernel parts are acceptable, >>> but not here. >> >> If you want to do the networking code at userspace, why do you need a >> kernel driver after all? > > Are you seriously asking why people write tunneling drivers in user-space? Or > why they want to use the kernel-space socket API and protocol stack? > >> The proper solution is to write an userspace >> library for that, and either enclose such library inside the applications, >> or use LD_PRELOAD to bind the library to handle the open/close/ioctl glibc >> calls. libv4l does that. As it proofed to be a good library, now almost >> all V4L applications are using it. > > No. Set aside the problem of licensing, the correct way is to reuse existing > code, which means the layer-3/4 stacks and the socket API in net/*. That > avoids duplicating efforts (and bugs) and allows socket API apps to run > unchanged and without brittle hacks like LD_PRELOAD. > > And indeed, that's what the Linux ecosystem does, thanks to the tuntap > network > device driver. Rémi, Using the Kernel network layer is the right thing to do, but you don't need to add a new driver for it: it is already there. All that userspace needs to do is to use glibc socket's support. It could make sense to have some sort of virtualization driver that would allow passing DVB API calls via, for example, the network socket API, to allow accessing a physical DVB driver (or a remote machine DVB driver)from a VM machine. That was my original understanding. Instead, the proposal is wrapper, that will be a sort of kernelspace implementation for "LD_PRELOAD" that just returns the DVB commands back to some other application in userspace. The real code to transmit DVB commands will be in userspace. Technically speaking, this is a hack. If I would code something like that, I would write it as a library with some functions like: connect_to_dvb() get_dvb_properties() get_frontend_parameters() set_frontend_parameters() get_dvb_ts() And write a few patches for the userspace applications I would care. If I wanted to provide transparent access to it, I would simply implement a LD_PRELOAD schema, in order to help the new library deployment. With such approach, at the initial stages (the worse case, e. g. using LD_PRELOAD), it will be equivalent to have a kernel wrapper code, but, at long term, it will allow important optimizations, like avoiding the need of copying data from/to the wrapper, supporting the extra delays introducing by the network and allowing the applications to implement themselves the dialog windows to control the network properties. Thanks, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] V4L: add media bus configuration subdev operations
Hi Hans
Thanks for the review, agree to all, except one:
On Wed, 22 Jun 2011, Hans Verkuil wrote:
> On Wednesday, June 22, 2011 23:26:29 Guennadi Liakhovetski wrote:
[snip]
> > +static inline unsigned long v4l2_mbus_config_compatible(struct
> > v4l2_mbus_config *cfg,
> > + unsigned long flags)
>
> This function is too big to be a static inline. I would also go for a bool
> return type.
> And cfg should be a const pointer.
return is not just a bool, it's a mask of common flags.
> > + switch (cfg->type) {
> > + case V4L2_MBUS_PARALLEL:
> > + hsync = common_flags & (V4L2_MBUS_HSYNC_ACTIVE_HIGH |
> > + V4L2_MBUS_HSYNC_ACTIVE_LOW);
> > + vsync = common_flags & (V4L2_MBUS_VSYNC_ACTIVE_HIGH |
> > + V4L2_MBUS_VSYNC_ACTIVE_LOW);
> > + pclk = common_flags & (V4L2_MBUS_PCLK_SAMPLE_RISING |
> > + V4L2_MBUS_PCLK_SAMPLE_FALLING);
> > + data = common_flags & (V4L2_MBUS_DATA_ACTIVE_HIGH |
> > + V4L2_MBUS_DATA_ACTIVE_LOW);
> > + mode = common_flags & (V4L2_MBUS_MASTER | V4L2_MBUS_SLAVE);
> > + return (!hsync || !vsync || !pclk || !data || !mode) ?
> > + 0 : common_flags;
> > + case V4L2_MBUS_CSI2:
> > + mipi_lanes = common_flags & V4L2_MBUS_CSI2_LANES;
> > + mipi_clock = common_flags & (V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK
> > |
> > +V4L2_MBUS_CSI2_CONTINUOUS_CLOCK);
> > + return (!mipi_lanes || !mipi_clock) ? 0 : common_flags;
> > + case V4L2_MBUS_BT656:
> > + /* TODO: implement me */
>
> Isn't this identical to MBUS_PARALLEL, except that it can ignore the
> hsync/vsync
> signals? So this case can go in between the 'vsync =' and 'pclk =' lines
> above.
> (hsync and vsync should be initialized to true of course).
Well, maybe. We could do that or leave it unimplemented until someone
really uses it.
> > @@ -294,6 +298,8 @@ struct v4l2_subdev_video_ops {
> > struct v4l2_mbus_framefmt *fmt);
> > int (*s_mbus_fmt)(struct v4l2_subdev *sd,
> > struct v4l2_mbus_framefmt *fmt);
> > + int (*g_mbus_config)(struct v4l2_subdev *sd, struct v4l2_mbus_config
> > *cfg);
> > + int (*s_mbus_config)(struct v4l2_subdev *sd, struct v4l2_mbus_config
> > *cfg);
>
> cfg can be a const pointer.
In s_... you mean, not in g_...
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/8] marvell-cam: Separate out the Marvell camera core
[Sorry, I'm just now recovering from one of those total-loss-of-inbox-control episodes...] On Fri, 17 Jun 2011 11:11:33 +0800 Kassey Lee wrote: > the problem is: > when we stop CCIC, and then switch to another format. > at this stage, actually, CCIC DMA is not stopped until the > transferring frame is done. this will cause system hang if we start > CCIC again with another format. OK, I've never encountered that. The use case I'm coding for (OLPC) doesn't involve a whole lot of format changes; generally they pick a format for their record activity based on what works best on the display side and stick with it. > from your logic, when stop DMA, you are test the EOF/SOF, so I > wonder why you want to do this ? > and is your test will stop CCIC and start CCIC frequently ? I wanted a way to know whether DMA was active or not; the idea was that an SOF indicates that things are starting, EOF says that it's done. Are you saying that there can be DMA active in the period after an EOF when the subsequent SOF has not been received? Thanks, jon -- 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] V4L: add media bus configuration subdev operations
On Wednesday, June 22, 2011 23:26:29 Guennadi Liakhovetski wrote:
> Add media bus configuration types and two subdev operations to get
> supported mediabus configurations and to set a specific configuration.
> Subdevs can support several configurations, e.g., they can send video data
> on 1 or several lanes, can be configured to use a specific CSI-2 channel,
> in such cases subdevice drivers return bitmasks with all respective bits
> set. When a set-configuration operation is called, it has to specify a
> non-ambiguous configuration.
>
> Signed-off-by: Stanimir Varbanov
> Signed-off-by: Guennadi Liakhovetski
> ---
>
> v2:
>
> 1. Removed parallel bus width flags. As Laurent correctly pointed out, bus
> width can be configured based on the mediabus format.
>
> 2. Removed the clock parameter for now. Passing timing information between
> the subdevices and the host / bridge driver is indeed necessary, but it is
> not yet quite clear, what is the best way to do this. This requires more
> thinking and can be added as an extra field to struct v4l2_mbus_config
> later. The argument, that "struct clk" is still platform specific is
> correct, but I am too tempted by the possibilities, the clkdev offers us
> to give up this idea immediatrely. Maybe drivers, that need such a clock,
> could use a platform callback to create a clock instance for them, or get
> a clock object from the platform with platform data. However, there are
> also opinions, that the clkdev API is completely unsuitable for this
> purpose. I'd commit this without any timing first, and consider
> possibilities as a second step.
>
> include/media/v4l2-mediabus.h | 89
> +
> include/media/v4l2-subdev.h |6 +++
> 2 files changed, 95 insertions(+), 0 deletions(-)
Some small stuff:
> diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
> index 971c7fa..e0ffba0 100644
> --- a/include/media/v4l2-mediabus.h
> +++ b/include/media/v4l2-mediabus.h
> @@ -13,6 +13,95 @@
>
> #include
>
> +/* Parallel flags */
> +/* Can the client run in master or in slave mode */
> +#define V4L2_MBUS_MASTER (1 << 0)
> +#define V4L2_MBUS_SLAVE (1 << 1)
> +/* Which signal polarities it supports */
> +#define V4L2_MBUS_HSYNC_ACTIVE_HIGH (1 << 2)
> +#define V4L2_MBUS_HSYNC_ACTIVE_LOW (1 << 3)
> +#define V4L2_MBUS_VSYNC_ACTIVE_HIGH (1 << 4)
> +#define V4L2_MBUS_VSYNC_ACTIVE_LOW (1 << 5)
> +#define V4L2_MBUS_PCLK_SAMPLE_RISING (1 << 6)
> +#define V4L2_MBUS_PCLK_SAMPLE_FALLING(1 << 7)
> +#define V4L2_MBUS_DATA_ACTIVE_HIGH (1 << 8)
> +#define V4L2_MBUS_DATA_ACTIVE_LOW(1 << 9)
> +
> +/* Serial flags */
> +/* How many lanes the client can use */
> +#define V4L2_MBUS_CSI2_1_LANE(1 << 0)
> +#define V4L2_MBUS_CSI2_2_LANE(1 << 1)
> +#define V4L2_MBUS_CSI2_3_LANE(1 << 2)
> +#define V4L2_MBUS_CSI2_4_LANE(1 << 3)
> +/* On which channels it can send video data */
> +#define V4L2_MBUS_CSI2_CHANNEL_0 (1 << 4)
> +#define V4L2_MBUS_CSI2_CHANNEL_1 (1 << 5)
> +#define V4L2_MBUS_CSI2_CHANNEL_2 (1 << 6)
> +#define V4L2_MBUS_CSI2_CHANNEL_3 (1 << 7)
> +/* Does it support only continuous or also non-continuous clock mode */
> +#define V4L2_MBUS_CSI2_CONTINUOUS_CLOCK (1 << 8)
> +#define V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK (1 << 9)
> +
> +#define V4L2_MBUS_CSI2_LANES (V4L2_MBUS_CSI2_1_LANE |
> V4L2_MBUS_CSI2_2_LANE | \
> + V4L2_MBUS_CSI2_3_LANE |
> V4L2_MBUS_CSI2_4_LANE)
> +#define V4L2_MBUS_CSI2_CHANNELS (V4L2_MBUS_CSI2_CHANNEL_0 |
> V4L2_MBUS_CSI2_CHANNEL_1 | \
> + V4L2_MBUS_CSI2_CHANNEL_2 |
> V4L2_MBUS_CSI2_CHANNEL_3)
> +
> +/**
> + * v4l2_mbus_type - media bus type
> + * @V4L2_MBUS_PARALLEL: parallel interface with hsync and vsync
> + * @V4L2_MBUS_BT656: parallel interface with embedded synchronisation
> + * @V4L2_MBUS_CSI2: MIPI CSI-2 serial interface
> + */
> +enum v4l2_mbus_type {
> + V4L2_MBUS_PARALLEL,
> + V4L2_MBUS_BT656,
> + V4L2_MBUS_CSI2,
> +};
> +
> +/**
> + * v4l2_mbus_config - media bus configuration
> + * @type:in: interface type
> + * @flags: in / out: configuration flags, depending on @type
> + */
> +struct v4l2_mbus_config {
> + enum v4l2_mbus_type type;
> + unsigned long flags;
Flags should be unsigned int. unsigned long is 64 bits on a 64-bit system,
which is unnecessary.
> +};
> +
> +static inline unsigned long v4l2_mbus_config_compatible(struct
> v4l2_mbus_config *cfg,
> + unsigned long flags)
This function is too big to be a static inline. I would also go for a bool
return type.
And cfg should be a const pointer.
> +
[PATCH v2] V4L: add media bus configuration subdev operations
Add media bus configuration types and two subdev operations to get
supported mediabus configurations and to set a specific configuration.
Subdevs can support several configurations, e.g., they can send video data
on 1 or several lanes, can be configured to use a specific CSI-2 channel,
in such cases subdevice drivers return bitmasks with all respective bits
set. When a set-configuration operation is called, it has to specify a
non-ambiguous configuration.
Signed-off-by: Stanimir Varbanov
Signed-off-by: Guennadi Liakhovetski
---
v2:
1. Removed parallel bus width flags. As Laurent correctly pointed out, bus
width can be configured based on the mediabus format.
2. Removed the clock parameter for now. Passing timing information between
the subdevices and the host / bridge driver is indeed necessary, but it is
not yet quite clear, what is the best way to do this. This requires more
thinking and can be added as an extra field to struct v4l2_mbus_config
later. The argument, that "struct clk" is still platform specific is
correct, but I am too tempted by the possibilities, the clkdev offers us
to give up this idea immediatrely. Maybe drivers, that need such a clock,
could use a platform callback to create a clock instance for them, or get
a clock object from the platform with platform data. However, there are
also opinions, that the clkdev API is completely unsuitable for this
purpose. I'd commit this without any timing first, and consider
possibilities as a second step.
include/media/v4l2-mediabus.h | 89 +
include/media/v4l2-subdev.h |6 +++
2 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index 971c7fa..e0ffba0 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -13,6 +13,95 @@
#include
+/* Parallel flags */
+/* Can the client run in master or in slave mode */
+#define V4L2_MBUS_MASTER (1 << 0)
+#define V4L2_MBUS_SLAVE(1 << 1)
+/* Which signal polarities it supports */
+#define V4L2_MBUS_HSYNC_ACTIVE_HIGH(1 << 2)
+#define V4L2_MBUS_HSYNC_ACTIVE_LOW (1 << 3)
+#define V4L2_MBUS_VSYNC_ACTIVE_HIGH(1 << 4)
+#define V4L2_MBUS_VSYNC_ACTIVE_LOW (1 << 5)
+#define V4L2_MBUS_PCLK_SAMPLE_RISING (1 << 6)
+#define V4L2_MBUS_PCLK_SAMPLE_FALLING (1 << 7)
+#define V4L2_MBUS_DATA_ACTIVE_HIGH (1 << 8)
+#define V4L2_MBUS_DATA_ACTIVE_LOW (1 << 9)
+
+/* Serial flags */
+/* How many lanes the client can use */
+#define V4L2_MBUS_CSI2_1_LANE (1 << 0)
+#define V4L2_MBUS_CSI2_2_LANE (1 << 1)
+#define V4L2_MBUS_CSI2_3_LANE (1 << 2)
+#define V4L2_MBUS_CSI2_4_LANE (1 << 3)
+/* On which channels it can send video data */
+#define V4L2_MBUS_CSI2_CHANNEL_0 (1 << 4)
+#define V4L2_MBUS_CSI2_CHANNEL_1 (1 << 5)
+#define V4L2_MBUS_CSI2_CHANNEL_2 (1 << 6)
+#define V4L2_MBUS_CSI2_CHANNEL_3 (1 << 7)
+/* Does it support only continuous or also non-continuous clock mode */
+#define V4L2_MBUS_CSI2_CONTINUOUS_CLOCK(1 << 8)
+#define V4L2_MBUS_CSI2_NONCONTINUOUS_CLOCK (1 << 9)
+
+#define V4L2_MBUS_CSI2_LANES (V4L2_MBUS_CSI2_1_LANE |
V4L2_MBUS_CSI2_2_LANE | \
+V4L2_MBUS_CSI2_3_LANE |
V4L2_MBUS_CSI2_4_LANE)
+#define V4L2_MBUS_CSI2_CHANNELS(V4L2_MBUS_CSI2_CHANNEL_0 |
V4L2_MBUS_CSI2_CHANNEL_1 | \
+V4L2_MBUS_CSI2_CHANNEL_2 |
V4L2_MBUS_CSI2_CHANNEL_3)
+
+/**
+ * v4l2_mbus_type - media bus type
+ * @V4L2_MBUS_PARALLEL:parallel interface with hsync and vsync
+ * @V4L2_MBUS_BT656: parallel interface with embedded synchronisation
+ * @V4L2_MBUS_CSI2:MIPI CSI-2 serial interface
+ */
+enum v4l2_mbus_type {
+ V4L2_MBUS_PARALLEL,
+ V4L2_MBUS_BT656,
+ V4L2_MBUS_CSI2,
+};
+
+/**
+ * v4l2_mbus_config - media bus configuration
+ * @type: in: interface type
+ * @flags: in / out: configuration flags, depending on @type
+ */
+struct v4l2_mbus_config {
+ enum v4l2_mbus_type type;
+ unsigned long flags;
+};
+
+static inline unsigned long v4l2_mbus_config_compatible(struct
v4l2_mbus_config *cfg,
+ unsigned long flags)
+{
+ unsigned long common_flags, hsync, vsync, pclk, data, mode;
+ unsigned long mipi_lanes, mipi_clock;
+
+ common_flags = cfg->flags & flags;
+
+ switch (cfg->type) {
+ case V4L2_MBUS_PARALLEL:
+ hsync = common_flags & (V4L2_MBUS_HSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_HSYNC_ACTIVE_LOW);
+ vsync = common_flags & (V4L2_MBUS_VSYNC_ACTIVE_HIGH |
+ V4L2_MBUS_VSYNC_ACTI
Re: KAIOMY ISDB-T Hybrid USB Dongle Receiver
Ok Mauro, Do you think I would capable to add the USB ID at cx231xx driver in order to make it work? Where from can I gownload the cx231xx in order I can try to introduce the line (I guess...) in the file of ths e cx231xx driver and after that to compile it with "make" and them do "make install" to incorporate it in my kernel (2.6.38-8-generic). Is it correct this proceeding I said? I am not sure how to do this things... I think that I must have the kernel source of 2.6.38-8-generic version in the /usr/src/linux-2.6.38-8-generic directory, is it correct? Can you indi cate a site or tutorial that I could do the insersion of the USB ID (1554:5019) in the cx231xx driver and compile it and to add it in the module in Ubuntu 11.04? By the way Mauro, couldn't I write in Portuguese to you? Ok, just in case I send the message only for you, not to linux-media list. Thanks in advance Antonio Carlos >> I bought a KAIOMY ISDB-T Hybrid USB Dongle Receiver to use with my >> Dell Inspiron 15 Laptop under Ubuntu 11.04 Linux. But I connect it in >> the USB port and it doesn't recognises it. The kernel version I am >> using is the 2.6.38-8-generic. I opened the menuconfig of the kernel >> and I could saw that all modules in the especific section "Device >> Drivers --> Multimedia support --> DVB/ATSC Adapters" are all set to >> . I was thinking that the driver v2l already was buit in this >> modules. But when I connected the device in the USB port I got the >> following autputs to the lsusb and dmesg commands in the console: >> >> Without the device connected >> >> nogueira@nogueira-Inspiron-1545:~$ lsusb >> Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 003 Device 005: ID 413c:8160 Dell Computer Corp. >> Bus 003 Device 004: ID 413c:8162 Dell Computer Corp. >> Bus 003 Device 003: ID 413c:8161 Dell Computer Corp. >> Bus 003 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub >> (part of BCM2046 Bluetooth) >> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 002 Device 002: ID 04e8:1f05 Samsung Electronics Co., Ltd >> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 001 Device 004: ID 0c45:63ee Microdia >> Bus 001 Device 003: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 >> multicard reader >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> nogueira@nogueira-Inspiron-1545:~$ >> >> >> With the device connected >> >> nogueira@nogueira-Inspiron-1545:~$ lsusb >> Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 003 Device 005: ID 413c:8160 Dell Computer Corp. >> Bus 003 Device 004: ID 413c:8162 Dell Computer Corp. >> Bus 003 Device 003: ID 413c:8161 Dell Computer Corp. >> Bus 003 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub >> (part of BCM2046 Bluetooth) >> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub >> Bus 002 Device 014: ID 1554:5019 Prolink Microsystems Corp. >> Bus 002 Device 002: ID 04e8:1f05 Samsung Electronics Co., Ltd >> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> Bus 001 Device 004: ID 0c45:63ee Microdia >> Bus 001 Device 003: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 >> multicard reader >> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >> nogueira@nogueira-Inspiron-1545:~$ >> >> I guess that the device pointed is Device 014, Prolink Microsystems Corp. > > Hmm... This device seems to be, in reality, a Prolink device. It is probably > close to the current Prolink/Pixelview ISDB-T devices already supported. > > The first devices from this manufacturer were using dib0700/dib8000. Newer > devices were using cx231xx chipsets. > > I have a few Prolink devices here, but I don't think that any of them have > this USB ID (1554:5019). I'll need to double-check though. I'm seeking for > some > spare time to add support for a mew more devices. > > Anyway, I'm not sure what's the chipset used inside your device. If the device > is hybrid, it probably has a cx231xx chipset. If so, probably, all that it is > needed is to add the USB ID at cx231xx driver in order to make it work, of > course assuming that they didn't make any other hange like using a different > tuner on it. > > Abraços, > 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
[GIT PULL for v3.0] OMAP_VOUT bug fixes and code cleanup
The following changes since commit af0d6a0a3a30946f7df69c764791f1b0643f7cd6: Linus Torvalds (1): Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/.../tip/linux-2.6-tip are available in the git repository at: git://arago-project.org/git/people/vaibhav/ti-psp-omap-video.git for-linux-media Amber Jain (2): V4L2: omap_vout: Remove GFP_DMA allocation as ZONE_DMA is not configured on OMAP OMAP2: V4L2: Remove GFP_DMA allocation as ZONE_DMA is not configured on OMAP Archit Taneja (3): OMAP_VOUT: CLEANUP: Move generic functions and macros to common files OMAP_VOUT: CLEANUP: Make rotation related helper functions more descriptive OMAP_VOUT: Create separate file for VRFB related API's Vaibhav Hiremath (2): OMAP_VOUT: Change hardcoded device node number to -1 omap_vout: Added check in reqbuf & mmap for buf_size allocation Vladimir Pantelic (1): OMAP_VOUTLIB: Fix wrong resizer calculation drivers/media/video/omap/Kconfig |7 +- drivers/media/video/omap/Makefile |1 + drivers/media/video/omap/omap_vout.c | 602 ++--- drivers/media/video/omap/omap_vout_vrfb.c | 390 +++ drivers/media/video/omap/omap_vout_vrfb.h | 40 ++ drivers/media/video/omap/omap_voutdef.h | 78 drivers/media/video/omap/omap_voutlib.c | 52 +++- drivers/media/video/omap/omap_voutlib.h | 12 +- drivers/media/video/omap24xxcam.c |4 +- 9 files changed, 684 insertions(+), 502 deletions(-) create mode 100644 drivers/media/video/omap/omap_vout_vrfb.c create mode 100644 drivers/imedia/video/omap/omap_vout_vrfb.h These patches include bug fixes and code cleanup. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC, PATCH] USB: EHCI: Allow users to override 80% max periodic bandwidth
On Wed, 22 Jun 2011, Kirill Smelkov wrote: > There are cases, when 80% max isochronous bandwidth is too limiting. > > For example I have two USB video capture cards which stream uncompressed > video, and to stream full NTSC + PAL videos we'd need > > NTSC 640x480 YUV422 @30fps ~17.6 MB/s > PAL 720x576 YUV422 @25fps ~19.7 MB/s > > isoc bandwidth. > > Now, due to limited alt settings in capture devices NTSC one ends up > streaming with max_pkt_size=2688 and PAL with max_pkt_size=2892, both > with interval=1. In terms of microframe time allocation this gives > > NTSC~53us > PAL ~57us > > and together > > ~110us > 100us == 80% of 125us uframe time. > > So those two devices can't work together simultaneously because the'd > over allocate isochronous bandwidth. > > 80% seemed a bit arbitrary to me, and I've tried to raise it to 90% and > both devices started to work together, so I though sometimes it would be > a good idea for users to override hardcoded default of max 80% isoc > bandwidth. > > After all, isn't it a user who should decide how to load the bus? If I > can live with 10% or even 5% bulk bandwidth that should be ok. I'm a USB > newcomer, but that 80% seems to be chosen pretty arbitrary to me, just > to serve as a reasonable default. This seems like the sort of feature somebody might reasonably want to use -- if they know exactly what they're doing. > NOTE: for two streams with max_pkt_size=3072 (worst case) both time > allocation would be 60us+60us=120us which is 96% periodic bandwidth > leaving 4% for bulk and control. I think this should work too. At 480 Mb/s, each microframe holds 7500 bytes (less if you count bit-stuffing). 4% of that is 300 bytes, which is not enough for a 512-byte bulk packet. I think you'd run into trouble trying to do any serious bulk transfers on such a tight schedule. > Signed-off-by: Kirill Smelkov > Cc: Alan Stern > --- > drivers/usb/host/ehci-hcd.c | 16 > drivers/usb/host/ehci-sched.c | 17 +++-- > 2 files changed, 23 insertions(+), 10 deletions(-) > > diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c > index c606b02..1d36e72 100644 > --- a/drivers/usb/host/ehci-hcd.c > +++ b/drivers/usb/host/ehci-hcd.c > @@ -112,6 +112,14 @@ static unsigned int hird; > module_param(hird, int, S_IRUGO); > MODULE_PARM_DESC(hird, "host initiated resume duration, +1 for each 75us\n"); > > +/* > + * max periodic time per microframe > + * (be careful, USB 2.0 requires it to be 100us = 80% of 125us) > + */ > +static unsigned int uframe_periodic_max = 100; > +module_param(uframe_periodic_max, uint, S_IRUGO); > +MODULE_PARM_DESC(uframe_periodic_max, "maximum allowed periodic part of a > microframe, us"); > + This probably should be a sysfs attribute rather than a module parameter, so that it can be applied to individual buses separately. > #define INTR_MASK (STS_IAA | STS_FATAL | STS_PCD | STS_ERR | STS_INT) > > /*-*/ > @@ -571,6 +579,14 @@ static int ehci_init(struct usb_hcd *hcd) > hcc_params = ehci_readl(ehci, &ehci->caps->hcc_params); > > /* > + * tell user, if using non-standard (80% == 100 usec/uframe) bandwidth > + */ > + if (uframe_periodic_max != 100) > + ehci_info(ehci, "using non-standard max periodic bandwith " > + "(%u%% == %u usec/uframe)", > + 100*uframe_periodic_max/125, > uframe_periodic_max); > + > + /* Check for invalid values. This should never be less than 100 or greater than 125. >* hw default: 1K periodic list heads, one per frame. >* periodic_size can shrink by USBCMD update if hcc_params allows. >*/ > diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c > index d12426f..fb374f2 100644 > --- a/drivers/usb/host/ehci-sched.c > +++ b/drivers/usb/host/ehci-sched.c > @@ -172,7 +172,7 @@ periodic_usecs (struct ehci_hcd *ehci, unsigned frame, > unsigned uframe) > } > } > #ifdef DEBUG > - if (usecs > 100) > + if (usecs > uframe_periodic_max) These changes all seem right. Alan Stern -- 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] vtunerc - virtual DVB device driver
Le mercredi 22 juin 2011 15:17:27 Mauro Carvalho Chehab, vous avez écrit : > > My very little opinion is that waving GPL is way to the hell. Nobody told > > me why similar technologies, in different kernel parts are acceptable, > > but not here. > > If you want to do the networking code at userspace, why do you need a > kernel driver after all? Are you seriously asking why people write tunneling drivers in user-space? Or why they want to use the kernel-space socket API and protocol stack? > The proper solution is to write an userspace > library for that, and either enclose such library inside the applications, > or use LD_PRELOAD to bind the library to handle the open/close/ioctl glibc > calls. libv4l does that. As it proofed to be a good library, now almost > all V4L applications are using it. No. Set aside the problem of licensing, the correct way is to reuse existing code, which means the layer-3/4 stacks and the socket API in net/*. That avoids duplicating efforts (and bugs) and allows socket API apps to run unchanged and without brittle hacks like LD_PRELOAD. And indeed, that's what the Linux ecosystem does, thanks to the tuntap network device driver. -- Rémi Denis-Courmont http://www.remlab.net/ http://fi.linkedin.com/in/remidenis -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Wed Jun 22 19:00:42 CEST 2011 git hash:7023c7dbc3944f42aa1d6910a6098c5f9e23d3f1 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: OK linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS 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-2.6.31.12-x86_64: ERRORS 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 spec-git: ERRORS 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 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
[ANNOUNCE] Media subsystem workshop 2011 - Prague - Oct 24-26
Media subsystem workshop 2011 - Prague - Oct 24-26 Since 2007, we're doing annual mini-summits for the media subsystem, in order to plan the new features that will be introduced there. Last year, during the Kernel Summit 2010, it was decided that the Kernel Summit 2011 format will be modified, in order to strength the interaction between the several sub-system mini-summits and the main Kernel Summit. If this idea works well, the next Kernel Summits will also follow the same format. So, some mini-summits were proposed to happen together with the Kernel Summit 2011. Among a few others, the Media subsystem was accepted to be held with this year's Kernel Summit. So, we'd like to announce that the Media subsystem workshop 2011 will happen together with the Kernel Summit 2011. The Media subsystem workshop is on early planning stages, but the idea is that we'll have an entire day to do the media discussions. We'll also planning to have workshop presentations inside the Kernel Summit 2011 with the workshop and Kernel Summit attendants present, where workshop results will be presented. So, I'd like to invite V4L, DVB and RC developers to submit proposals for the themes to be discussed. Please email me if you're interested on being invited for the event. Hoping to see you soon there! Mauro PS.: I'll be maintaining the information about the event updated at: http://linuxtv.org/events.php -- 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: KAIOMY ISDB-T Hybrid USB Dongle Receiver
Hi Antônio, Em 22-06-2011 15:13, nogueira13 escreveu: > I bought a KAIOMY ISDB-T Hybrid USB Dongle Receiver to use with my > Dell Inspiron 15 Laptop under Ubuntu 11.04 Linux. But I connect it in > the USB port and it doesn't recognises it. The kernel version I am > using is the 2.6.38-8-generic. I opened the menuconfig of the kernel > and I could saw that all modules in the especific section "Device > Drivers --> Multimedia support --> DVB/ATSC Adapters" are all set to > . I was thinking that the driver v2l already was buit in this > modules. But when I connected the device in the USB port I got the > following autputs to the lsusb and dmesg commands in the console: > > Without the device connected > > nogueira@nogueira-Inspiron-1545:~$ lsusb > Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 003 Device 005: ID 413c:8160 Dell Computer Corp. > Bus 003 Device 004: ID 413c:8162 Dell Computer Corp. > Bus 003 Device 003: ID 413c:8161 Dell Computer Corp. > Bus 003 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub > (part of BCM2046 Bluetooth) > Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 002 Device 002: ID 04e8:1f05 Samsung Electronics Co., Ltd > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 001 Device 004: ID 0c45:63ee Microdia > Bus 001 Device 003: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 > multicard reader > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > nogueira@nogueira-Inspiron-1545:~$ > > > With the device connected > > nogueira@nogueira-Inspiron-1545:~$ lsusb > Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 003 Device 005: ID 413c:8160 Dell Computer Corp. > Bus 003 Device 004: ID 413c:8162 Dell Computer Corp. > Bus 003 Device 003: ID 413c:8161 Dell Computer Corp. > Bus 003 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub > (part of BCM2046 Bluetooth) > Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub > Bus 002 Device 014: ID 1554:5019 Prolink Microsystems Corp. > Bus 002 Device 002: ID 04e8:1f05 Samsung Electronics Co., Ltd > Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Bus 001 Device 004: ID 0c45:63ee Microdia > Bus 001 Device 003: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 > multicard reader > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > nogueira@nogueira-Inspiron-1545:~$ > > I guess that the device pointed is Device 014, Prolink Microsystems Corp. Hmm... This device seems to be, in reality, a Prolink device. It is probably close to the current Prolink/Pixelview ISDB-T devices already supported. The first devices from this manufacturer were using dib0700/dib8000. Newer devices were using cx231xx chipsets. I have a few Prolink devices here, but I don't think that any of them have this USB ID (1554:5019). I'll need to double-check though. I'm seeking for some spare time to add support for a mew more devices. Anyway, I'm not sure what's the chipset used inside your device. If the device is hybrid, it probably has a cx231xx chipset. If so, probably, all that it is needed is to add the USB ID at cx231xx driver in order to make it work, of course assuming that they didn't make any other hange like using a different tuner on it. Abraços, 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
KAIOMY ISDB-T Hybrid USB Dongle Receiver
I bought a KAIOMY ISDB-T Hybrid USB Dongle Receiver to use with my Dell Inspiron 15 Laptop under Ubuntu 11.04 Linux. But I connect it in the USB port and it doesn't recognises it. The kernel version I am using is the 2.6.38-8-generic. I opened the menuconfig of the kernel and I could saw that all modules in the especific section "Device Drivers --> Multimedia support --> DVB/ATSC Adapters" are all set to . I was thinking that the driver v2l already was buit in this modules. But when I connected the device in the USB port I got the following autputs to the lsusb and dmesg commands in the console: Without the device connected nogueira@nogueira-Inspiron-1545:~$ lsusb Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 005: ID 413c:8160 Dell Computer Corp. Bus 003 Device 004: ID 413c:8162 Dell Computer Corp. Bus 003 Device 003: ID 413c:8161 Dell Computer Corp. Bus 003 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth) Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 002: ID 04e8:1f05 Samsung Electronics Co., Ltd Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 004: ID 0c45:63ee Microdia Bus 001 Device 003: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 multicard reader Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub nogueira@nogueira-Inspiron-1545:~$ With the device connected nogueira@nogueira-Inspiron-1545:~$ lsusb Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 005: ID 413c:8160 Dell Computer Corp. Bus 003 Device 004: ID 413c:8162 Dell Computer Corp. Bus 003 Device 003: ID 413c:8161 Dell Computer Corp. Bus 003 Device 002: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub (part of BCM2046 Bluetooth) Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 014: ID 1554:5019 Prolink Microsystems Corp. Bus 002 Device 002: ID 04e8:1f05 Samsung Electronics Co., Ltd Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 004: ID 0c45:63ee Microdia Bus 001 Device 003: ID 0bda:0158 Realtek Semiconductor Corp. USB 2.0 multicard reader Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub nogueira@nogueira-Inspiron-1545:~$ I guess that the device pointed is Device 014, Prolink Microsystems Corp. Here the output of the last lines of "dmesg": [21677.320057] usb0: no IPv6 routers present [24094.384020] input: Navigator 905BT Mouse as /devices/pci:00/:00:1a.0/usb3/3-1/3-1.3/3-1.3:1.0/bluetooth/hci0/hci0:12/input15 [24094.384377] generic-bluetooth 0005:0458:00A7.0005: input,hidraw1: BLUETOOTH HID v1.00 Mouse [Navigator 905BT Mouse] on 00:26:5E:E0:61:18 [24622.528358] usb 2-3: USB disconnect, address 11 [24622.528559] rndis_host 2-3:1.0: usb0: unregister 'rndis_host' usb-:00:1d.7-3, RNDIS device [24622.970104] usb 2-3: new high speed USB device using ehci_hcd and address 12 [24623.125469] scsi14 : usb-storage 2-3:1.0 [24624.121792] scsi 14:0:0:0: Direct-Access SAMSUNG GT-I5500 Card PQ: 0 ANSI: 2 [24624.123433] sd 14:0:0:0: Attached scsi generic sg4 type 0 [24624.128097] sd 14:0:0:0: [sdd] Attached SCSI removable disk [24633.138586] usb 2-3: USB disconnect, address 12 [24649.596828] wlan0: authenticate with 00:1a:3f:4b:50:8b (try 1) [24649.599160] wlan0: authenticated [24649.599226] wlan0: associate with 00:1a:3f:4b:50:8b (try 1) [24649.602074] wlan0: RX AssocResp from 00:1a:3f:4b:50:8b (capab=0x451 status=0 aid=4) [24649.602082] wlan0: associated [29210.660319] usb 2-3: new high speed USB device using ehci_hcd and address 13 I am not an expert in linux but I can't see anything that could indicate that it recognised it in dmesg. I would like if you may help me in order I could use this device in Linux (in windows 7 it is working properly...). I would like you send me the routine that I must to follow (step by step, please because I am not an expert as I already said). Hopping you help me I would like to tanks in advantage. Sincerely Antonio Carlos Ribeiro Nogueira -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 04/18] s5p-fimc: Limit number of available inputs to one
Camera sensors at FIMC input are no longer selected with S_INPUT ioctl.
They will be attached to required FIMC entity through pipeline
re-configuration at the media device level.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 43 ---
1 files changed, 6 insertions(+), 37 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index c7bb6f6..f42cda3 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -566,57 +566,26 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
}
static int fimc_cap_enum_input(struct file *file, void *priv,
-struct v4l2_input *i)
+ struct v4l2_input *i)
{
struct fimc_ctx *ctx = priv;
- struct s5p_platform_fimc *pldata = ctx->fimc_dev->pdata;
- struct s5p_fimc_isp_info *isp_info;
- if (i->index >= pldata->num_clients)
+ if (i->index != 0)
return -EINVAL;
- isp_info = &pldata->isp_info[i->index];
i->type = V4L2_INPUT_TYPE_CAMERA;
- strncpy(i->name, isp_info->board_info->type, 32);
return 0;
}
-static int fimc_cap_s_input(struct file *file, void *priv,
- unsigned int i)
+static int fimc_cap_s_input(struct file *file, void *priv, unsigned int i)
{
- struct fimc_ctx *ctx = priv;
- struct fimc_dev *fimc = ctx->fimc_dev;
- struct s5p_platform_fimc *pdata = fimc->pdata;
-
- if (fimc_capture_active(ctx->fimc_dev))
- return -EBUSY;
-
- if (i >= pdata->num_clients)
- return -EINVAL;
-
-
- if (fimc->vid_cap.sd) {
- int ret = v4l2_subdev_call(fimc->vid_cap.sd, core, s_power, 0);
- if (ret)
- err("s_power failed: %d", ret);
-
- clk_disable(fimc->clock[CLK_CAM]);
- }
-
- /* Release the attached sensor subdevice. */
- fimc_subdev_unregister(fimc);
-
- return fimc_isp_subdev_init(fimc, i);
+ return i == 0 ? i : -EINVAL;
}
-static int fimc_cap_g_input(struct file *file, void *priv,
- unsigned int *i)
+static int fimc_cap_g_input(struct file *file, void *priv, unsigned int *i)
{
- struct fimc_ctx *ctx = priv;
- struct fimc_vid_cap *cap = &ctx->fimc_dev->vid_cap;
-
- *i = cap->input_index;
+ *i = 0;
return 0;
}
--
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 v2 10/18] s5p-fimc: Add media operations in the capture entity driver
Add the link_setup handler for the camera capture video node.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 32 +++
drivers/media/video/s5p-fimc/fimc-core.h|2 +
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 887a3fc..f9beee8 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -654,6 +654,37 @@ static const struct v4l2_ioctl_ops fimc_capture_ioctl_ops
= {
.vidioc_g_input = fimc_cap_g_input,
};
+/* Media operations */
+static int fimc_link_setup(struct media_entity *entity,
+ const struct media_pad *local,
+ const struct media_pad *remote, u32 flags)
+{
+ struct video_device *vd = media_entity_to_video_device(entity);
+ struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(remote->entity);
+ struct fimc_dev *fimc = video_get_drvdata(vd);
+
+ if (WARN_ON(fimc == NULL))
+ return 0;
+
+ dbg("%s --> %s, flags: 0x%x. input: 0x%x",
+ local->entity->name, remote->entity->name, flags,
+ fimc->vid_cap.input);
+
+ if (flags & MEDIA_LNK_FL_ENABLED) {
+ if (fimc->vid_cap.input != 0)
+ return -EBUSY;
+ fimc->vid_cap.input = sd->grp_id;
+ return 0;
+ }
+
+ fimc->vid_cap.input = 0;
+ return 0;
+}
+
+static const struct media_entity_operations fimc_media_ops = {
+ .link_setup = fimc_link_setup,
+};
+
/* fimc->lock must be already initialized */
int fimc_register_capture_device(struct fimc_dev *fimc,
struct v4l2_device *v4l2_dev)
@@ -728,6 +759,7 @@ int fimc_register_capture_device(struct fimc_dev *fimc,
if (ret)
goto err_ent;
+ vfd->entity.ops = &fimc_media_ops;
vfd->ctrl_handler = &ctx->ctrl_handler;
ret = video_register_device(vfd, VFL_TYPE_GRABBER, -1);
if (ret) {
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index 6ccd446..d264f3f 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -305,6 +305,7 @@ struct fimc_m2m_device {
* @reqbufs_count: the number of buffers requested in REQBUFS ioctl
* @input_index: input (camera sensor) index
* @refcnt: driver's private reference counter
+ * @input: capture input type, grp_id of attached subdev
*/
struct fimc_vid_cap {
struct fimc_ctx *ctx;
@@ -322,6 +323,7 @@ struct fimc_vid_cap {
unsigned intreqbufs_count;
int input_index;
int refcnt;
+ u32 input;
};
/**
--
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 v2 01/18] s5p-fimc: Add media entity initialization
Add intialization of the media entities for video capture
and mem-to-mem video nodes.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 28 --
drivers/media/video/s5p-fimc/fimc-core.c| 27 +++--
drivers/media/video/s5p-fimc/fimc-core.h|4 +++
3 files changed, 37 insertions(+), 22 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 9432ea8..2748cca 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -842,9 +842,8 @@ int fimc_register_capture_device(struct fimc_dev *fimc)
fr->width = fr->f_width = fr->o_width = 640;
fr->height = fr->f_height = fr->o_height = 480;
- if (!v4l2_dev->name[0])
- snprintf(v4l2_dev->name, sizeof(v4l2_dev->name),
-"%s.capture", dev_name(&fimc->pdev->dev));
+ snprintf(v4l2_dev->name, sizeof(v4l2_dev->name),
+"%s.capture", dev_name(&fimc->pdev->dev));
ret = v4l2_device_register(NULL, v4l2_dev);
if (ret)
@@ -856,11 +855,11 @@ int fimc_register_capture_device(struct fimc_dev *fimc)
goto err_v4l2_reg;
}
- snprintf(vfd->name, sizeof(vfd->name), "%s:cap",
-dev_name(&fimc->pdev->dev));
+ strlcpy(vfd->name, v4l2_dev->name, sizeof(vfd->name));
vfd->fops = &fimc_capture_fops;
vfd->ioctl_ops = &fimc_capture_ioctl_ops;
+ vfd->v4l2_dev = v4l2_dev;
vfd->minor = -1;
vfd->release= video_device_release;
vfd->lock = &fimc->lock;
@@ -890,6 +889,11 @@ int fimc_register_capture_device(struct fimc_dev *fimc)
vb2_queue_init(q);
+ fimc->vid_cap.vd_pad.flags = MEDIA_PAD_FL_SINK;
+ ret = media_entity_init(&vfd->entity, 1, &fimc->vid_cap.vd_pad, 0);
+ if (ret)
+ goto err_ent;
+
ret = video_register_device(vfd, VFL_TYPE_GRABBER, -1);
if (ret) {
v4l2_err(v4l2_dev, "Failed to register video device\n");
@@ -899,10 +903,11 @@ int fimc_register_capture_device(struct fimc_dev *fimc)
v4l2_info(v4l2_dev,
"FIMC capture driver registered as /dev/video%d\n",
vfd->num);
-
return 0;
err_vd_reg:
+ media_entity_cleanup(&vfd->entity);
+err_ent:
video_device_release(vfd);
err_v4l2_reg:
v4l2_device_unregister(v4l2_dev);
@@ -914,10 +919,11 @@ err_info:
void fimc_unregister_capture_device(struct fimc_dev *fimc)
{
- struct fimc_vid_cap *capture = &fimc->vid_cap;
+ struct video_device *vfd = fimc->vid_cap.vfd;
- if (capture->vfd)
- video_unregister_device(capture->vfd);
-
- kfree(capture->ctx);
+ if (vfd) {
+ media_entity_cleanup(&vfd->entity);
+ video_unregister_device(vfd);
+ }
+ kfree(fimc->vid_cap.ctx);
}
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 119f170..af0d966 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -1504,10 +1504,8 @@ static int fimc_register_m2m_device(struct fimc_dev
*fimc)
pdev = fimc->pdev;
v4l2_dev = &fimc->m2m.v4l2_dev;
- /* set name if it is empty */
- if (!v4l2_dev->name[0])
- snprintf(v4l2_dev->name, sizeof(v4l2_dev->name),
-"%s.m2m", dev_name(&pdev->dev));
+ snprintf(v4l2_dev->name, sizeof(v4l2_dev->name),
+"%s.m2m", dev_name(&pdev->dev));
ret = v4l2_device_register(&pdev->dev, v4l2_dev);
if (ret)
@@ -1521,6 +1519,7 @@ static int fimc_register_m2m_device(struct fimc_dev *fimc)
vfd->fops = &fimc_m2m_fops;
vfd->ioctl_ops = &fimc_m2m_ioctl_ops;
+ vfd->v4l2_dev = v4l2_dev;
vfd->minor = -1;
vfd->release= video_device_release;
vfd->lock = &fimc->lock;
@@ -1538,17 +1537,22 @@ static int fimc_register_m2m_device(struct fimc_dev
*fimc)
goto err_m2m_r2;
}
+ ret = media_entity_init(&vfd->entity, 0, NULL, 0);
+ if (ret)
+ goto err_m2m_r3;
+
ret = video_register_device(vfd, VFL_TYPE_GRABBER, -1);
if (ret) {
v4l2_err(v4l2_dev,
"%s(): failed to register video device\n", __func__);
- goto err_m2m_r3;
+ goto err_m2m_r4;
}
v4l2_info(v4l2_dev,
"FIMC m2m driver registered as /dev/video%d\n", vfd->num);
return 0;
-
+err_m2m_r4:
+ media_entity_cleanup(&vfd->entity);
err_m2m_r3:
v4l2_m2m_release(fimc->m2m.m2m_dev);
err_m2m_r2:
@@ -1561,12 +1565,13 @@ err_m2m_r1:
void fimc_unregister_m2m_device(struct fimc_dev *fimc)
{
-
[PATCH v2 06/18] s5p-fimc: Remove v4l2_device from video capture and m2m driver
Currently there is a v4l2_device instance being registered per each
(capture and memory-to-memory) video node created per FIMC H/W instance.
This patch is a prerequisite for using the top level v4l2_device
instantiated by the media device driver.
To retain current debug trace semantic (so it's possible to distinguish
between the capture and m2m FIMC) the video_device is used in place
of v4l2_device where appropriate.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 43 ++--
drivers/media/video/s5p-fimc/fimc-core.c| 70 ++
drivers/media/video/s5p-fimc/fimc-core.h| 15 +++---
drivers/media/video/s5p-fimc/fimc-reg.c |7 ++-
4 files changed, 55 insertions(+), 80 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index cef8879..22a7bf6b 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -133,7 +133,6 @@ static int start_streaming(struct vb2_queue *q)
fimc->vid_cap.buf_index = 0;
set_bit(ST_CAPT_PEND, &fimc->state);
-
return 0;
}
@@ -180,7 +179,6 @@ static int buffer_prepare(struct vb2_buffer *vb)
{
struct vb2_queue *vq = vb->vb2_queue;
struct fimc_ctx *ctx = vq->drv_priv;
- struct v4l2_device *v4l2_dev = &ctx->fimc_dev->m2m.v4l2_dev;
int i;
if (!ctx->d_frame.fmt || vq->type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
@@ -190,7 +188,8 @@ static int buffer_prepare(struct vb2_buffer *vb)
unsigned long size = get_plane_size(&ctx->d_frame, i);
if (vb2_plane_size(vb, i) < size) {
- v4l2_err(v4l2_dev, "User buffer too small (%ld <
%ld)\n",
+ v4l2_err(ctx->fimc_dev->vid_cap.vfd,
+"User buffer too small (%ld < %ld)\n",
vb2_plane_size(vb, i), size);
return -EINVAL;
}
@@ -402,7 +401,8 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
pix = &f->fmt.pix_mp;
frame->fmt = find_format(f, FMT_FLAGS_M2M | FMT_FLAGS_CAM);
if (!frame->fmt) {
- err("fimc target format not found\n");
+ v4l2_err(fimc->vid_cap.vfd,
+"Not supported capture (FIMC target) color format\n");
return -EINVAL;
}
@@ -462,7 +462,7 @@ static int fimc_cap_streamon(struct file *file, void *priv,
return -EBUSY;
if (!(ctx->state & FIMC_DST_FMT)) {
- v4l2_err(&fimc->vid_cap.v4l2_dev, "Format is not set\n");
+ v4l2_err(fimc->vid_cap.vfd, "Format is not set\n");
return -EINVAL;
}
@@ -592,9 +592,8 @@ static int fimc_cap_s_crop(struct file *file, void *fh,
return ret;
if (!(ctx->state & FIMC_DST_FMT)) {
- v4l2_err(&fimc->vid_cap.v4l2_dev,
-"Capture color format not set\n");
- return -EINVAL; /* TODO: make sure this is the right value */
+ v4l2_err(fimc->vid_cap.vfd, "Capture format is not set\n");
+ return -EINVAL;
}
f = &ctx->s_frame;
@@ -603,7 +602,7 @@ static int fimc_cap_s_crop(struct file *file, void *fh,
ctx->d_frame.width, ctx->d_frame.height,
ctx->rotation);
if (ret) {
- v4l2_err(&fimc->vid_cap.v4l2_dev, "Out of the scaler range\n");
+ v4l2_err(fimc->vid_cap.vfd, "Out of the scaler range\n");
return ret;
}
@@ -647,16 +646,16 @@ static const struct v4l2_ioctl_ops fimc_capture_ioctl_ops
= {
};
/* fimc->lock must be already initialized */
-int fimc_register_capture_device(struct fimc_dev *fimc)
+int fimc_register_capture_device(struct fimc_dev *fimc,
+struct v4l2_device *v4l2_dev)
{
- struct v4l2_device *v4l2_dev = &fimc->vid_cap.v4l2_dev;
struct video_device *vfd;
struct fimc_vid_cap *vid_cap;
struct fimc_ctx *ctx;
struct v4l2_format f;
struct fimc_frame *fr;
struct vb2_queue *q;
- int ret;
+ int ret = -ENOMEM;
ctx = kzalloc(sizeof *ctx, GFP_KERNEL);
if (!ctx)
@@ -674,20 +673,14 @@ int fimc_register_capture_device(struct fimc_dev *fimc)
fr->width = fr->f_width = fr->o_width = 640;
fr->height = fr->f_height = fr->o_height = 480;
- snprintf(v4l2_dev->name, sizeof(v4l2_dev->name),
-"%s.capture", dev_name(&fimc->pdev->dev));
-
- ret = v4l2_device_register(NULL, v4l2_dev);
- if (ret)
- goto err_info;
-
vfd = video_device_alloc();
if (!vfd) {
v4l2_err(v4l2_dev, "Failed to allocate video device\n");
-
[PATCH 0/19] s5p-fimc driver conversion to media controller and control framework
Hello,
following is an updated patchset for s5p-fimc driver conversion to the media
controller API and control framework.
In this version the ioctl handlers for format setting at the video node and
the FIMC subdev has been reworked so they use common functions for capture
data format adjustment to the hardware capabilities. This prevent trouble
from any differences in handling ioctls at the subdev and the video node
when those are used simultaneously.
Except that I have killed a few bugs that jumped out when the driver was tried
to be used as a kernel module.
Additionally to allow the driver to be used in V4L2 video node compatibility
mode (when sensor subdev is configured by the host driver rather that directly
by the applications through /dev/v4l-subdev*) a sysfs entry is added.
All that needs to be done to disable sensors configuration from /dev/video*
node level, in order to use sub-device user space API, is to write correct
string to s5p-fimc-md platform device "subdev_conf_mode" sysfs entry, e.g.
echo sub-dev > /sys/devices/platform/s5p-fimc-md/subdev_conf_mode
or to revert:
echo vid-dev > /sys/devices/platform/s5p-fimc-md/subdev_conf_mode
The following procedure is adopted for format and crop/composition
configuration at the FIMC.{n} (capture) subdevs:
1) set format at sink pad (this will reset sink crop rectangle)
2) set crop rectangle at sink pad (optional)
3) set rotate control
4) set crop (composition) at source pad (optional). Here scaling constraints
are checked according to whether sink pad crop has been set or not and
whether 90/270 deg rotation is set.
5) set format at source pad
6) set format at corresponding video node
Rotation can also be changed while streaming, in this case when 90/270 deg
rotation is attempted to be set and scaling bounds are exceeded
(max. 64x downscaling) s_ctrl returns EINVAL.
I have tried this driver with v4l-compliance and it returned only 1 fail
on S/G_PRIORITY.
This patch set depends on my previous s5p-fimc bugfixes, available at:
http://git.infradead.org/users/kmpark/linux-2.6-samsung/shortlog/refs/heads/s5p-fimc
as well as the control framework updates from Hans Verkuil:
http://www.spinics.net/lists/linux-media/msg33552.html
(patch 1...6, 8, 11).
Full source tree can be found at:
http://git.infradead.org/users/kmpark/linux-2.6-samsung
branch: s5p-fimc-next
I have skipped patch one patch in this series comparing to first version:
s5p-fimc: Add support for runtime PM in the mem-to-mem driver
This patch is available in the above git repository.
I need to work a bit more on that one.
As usual, all comments and suggestions are welcome!
Sylwester Nawrocki (18):
s5p-fimc: Add media entity initialization
s5p-fimc: Remove registration of video nodes from probe()
s5p-fimc: Remove sclk_cam clock handling
s5p-fimc: Limit number of available inputs to one
s5p-fimc: Remove sensor management code from FIMC capture driver
s5p-fimc: Remove v4l2_device from video capture and m2m driver
s5p-fimc: Add the media device driver
s5p-fimc: Conversion to use struct v4l2_fh
s5p-fimc: Conversion to the control framework
s5p-fimc: Add media operations in the capture entity driver
s5p-fimc: Add PM helper function for streaming control
s5p-fimc: Correct color format enumeration
s5p-fimc: Convert to use media pipeline operations
s5p-fimc: Add subdev for the FIMC processing block
s5p-fimc: Add support for camera capture in JPEG format
s5p-fimc: Add v4l2_device notification support for single frame capture
s5p-fimc: Use consistent names for the buffer list functions
s5p-fimc: Add runtime PM support in the camera capture driver
drivers/media/video/Kconfig |2 +-
drivers/media/video/s5p-fimc/Makefile |2 +-
drivers/media/video/s5p-fimc/fimc-capture.c | 1387 ++-
drivers/media/video/s5p-fimc/fimc-core.c| 864 -
drivers/media/video/s5p-fimc/fimc-core.h| 204 +++--
drivers/media/video/s5p-fimc/fimc-mdevice.c | 822
drivers/media/video/s5p-fimc/fimc-mdevice.h | 118 +++
drivers/media/video/s5p-fimc/fimc-reg.c | 74 +-
drivers/media/video/s5p-fimc/regs-fimc.h|8 +-
include/media/s5p_fimc.h| 11 +
10 files changed, 2490 insertions(+), 1002 deletions(-)
create mode 100644 drivers/media/video/s5p-fimc/fimc-mdevice.c
create mode 100644 drivers/media/video/s5p-fimc/fimc-mdevice.h
--
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
[PATCH v2 05/18] s5p-fimc: Remove sensor management code from FIMC capture driver
The sensor subdevs need to be shared between all available FIMC instances.
Remove their registration from FIMC capture driver so they can then be
registered to the media device driver.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 139 +--
drivers/media/video/s5p-fimc/fimc-core.h|2 +-
2 files changed, 2 insertions(+), 139 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index f42cda3..cef8879 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -17,12 +17,9 @@
#include
#include
#include
-#include
#include
#include
#include
-#include
-#include
#include
#include
@@ -33,126 +30,6 @@
#include "fimc-core.h"
-static struct v4l2_subdev *fimc_subdev_register(struct fimc_dev *fimc,
- struct s5p_fimc_isp_info *isp_info)
-{
- struct i2c_adapter *i2c_adap;
- struct fimc_vid_cap *vid_cap = &fimc->vid_cap;
- struct v4l2_subdev *sd = NULL;
-
- i2c_adap = i2c_get_adapter(isp_info->i2c_bus_num);
- if (!i2c_adap)
- return ERR_PTR(-ENOMEM);
-
- sd = v4l2_i2c_new_subdev_board(&vid_cap->v4l2_dev, i2c_adap,
- isp_info->board_info, NULL);
- if (!sd) {
- v4l2_err(&vid_cap->v4l2_dev, "failed to acquire subdev\n");
- return NULL;
- }
-
- v4l2_info(&vid_cap->v4l2_dev, "subdevice %s registered successfuly\n",
- isp_info->board_info->type);
-
- return sd;
-}
-
-static void fimc_subdev_unregister(struct fimc_dev *fimc)
-{
- struct fimc_vid_cap *vid_cap = &fimc->vid_cap;
- struct i2c_client *client;
-
- if (vid_cap->input_index < 0)
- return; /* Subdevice already released or not registered. */
-
- if (vid_cap->sd) {
- v4l2_device_unregister_subdev(vid_cap->sd);
- client = v4l2_get_subdevdata(vid_cap->sd);
- i2c_unregister_device(client);
- i2c_put_adapter(client->adapter);
- vid_cap->sd = NULL;
- }
-
- vid_cap->input_index = -1;
-}
-
-/**
- * fimc_subdev_attach - attach v4l2_subdev to camera host interface
- *
- * @fimc: FIMC device information
- * @index: index to the array of available subdevices,
- *-1 for full array search or non negative value
- *to select specific subdevice
- */
-static int fimc_subdev_attach(struct fimc_dev *fimc, int index)
-{
- struct fimc_vid_cap *vid_cap = &fimc->vid_cap;
- struct s5p_platform_fimc *pdata = fimc->pdata;
- struct s5p_fimc_isp_info *isp_info;
- struct v4l2_subdev *sd;
- int i;
-
- for (i = 0; i < pdata->num_clients; ++i) {
- isp_info = &pdata->isp_info[i];
-
- if (index >= 0 && i != index)
- continue;
-
- sd = fimc_subdev_register(fimc, isp_info);
- if (!IS_ERR_OR_NULL(sd)) {
- vid_cap->sd = sd;
- vid_cap->input_index = i;
-
- return 0;
- }
- }
-
- vid_cap->input_index = -1;
- vid_cap->sd = NULL;
- v4l2_err(&vid_cap->v4l2_dev, "fimc%d: sensor attach failed\n",
-fimc->id);
- return -ENODEV;
-}
-
-static int fimc_isp_subdev_init(struct fimc_dev *fimc, unsigned int index)
-{
- struct s5p_fimc_isp_info *isp_info;
- struct s5p_platform_fimc *pdata = fimc->pdata;
- int ret;
-
- if (index >= pdata->num_clients)
- return -EINVAL;
-
- isp_info = &pdata->isp_info[index];
-
- if (isp_info->clk_frequency)
- clk_set_rate(fimc->clock[CLK_CAM], isp_info->clk_frequency);
-
- ret = clk_enable(fimc->clock[CLK_CAM]);
- if (ret)
- return ret;
-
- ret = fimc_subdev_attach(fimc, index);
- if (ret)
- return ret;
-
- ret = fimc_hw_set_camera_polarity(fimc, isp_info);
- if (ret)
- return ret;
-
- ret = v4l2_subdev_call(fimc->vid_cap.sd, core, s_power, 1);
- if (!ret)
- return ret;
-
- /* enabling power failed so unregister subdev */
- fimc_subdev_unregister(fimc);
-
- v4l2_err(&fimc->vid_cap.v4l2_dev, "ISP initialization failed: %d\n",
-ret);
-
- return ret;
-}
-
static int fimc_stop_capture(struct fimc_dev *fimc)
{
unsigned long flags;
@@ -399,15 +276,7 @@ static int fimc_capture_open(struct file *file)
if (ret)
return ret;
- if (++fimc->vid_cap.refcnt == 1) {
- ret = fimc_isp_subdev_init(fimc, 0);
- if (ret) {
- pm_runtime_put_sync(&fimc->pdev->dev);
- fimc->vid_cap.refcnt--;
-
[PATCH v2 12/18] s5p-fimc: Correct color format enumeration
Create separate VIDIOC_ENUM_FMT ioctl handlers for video capture
and mem-to-mem video node. This is needed as some formats are
valid only for the video capture and some only for the mem-to-mem
video node. Create single function for pixel format lookup out of
find_mbus_format() and find_format().
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 32 ++
drivers/media/video/s5p-fimc/fimc-core.c| 61 +--
drivers/media/video/s5p-fimc/fimc-core.h|5 +-
drivers/media/video/s5p-fimc/fimc-mdevice.c |2 +-
4 files changed, 55 insertions(+), 45 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index a7d579d..a2a13e6 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -380,6 +380,22 @@ static int fimc_vidioc_querycap_capture(struct file *file,
void *priv,
return 0;
}
+static int fimc_cap_enum_fmt_mplane(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
+{
+ struct fimc_fmt *fmt;
+
+ fmt = fimc_find_format(NULL, NULL, FMT_FLAGS_CAM | FMT_FLAGS_M2M,
+ f->index);
+ if (!fmt)
+ return -EINVAL;
+ strncpy(f->description, fmt->name, sizeof(f->description) - 1);
+ f->pixelformat = fmt->fourcc;
+ if (fmt->fourcc == V4L2_MBUS_FMT_JPEG_1X8)
+ f->flags |= V4L2_FMT_FLAG_COMPRESSED;
+ return 0;
+}
+
/* Synchronize formats of the camera interface input and attached sensor. */
static int sync_capture_fmt(struct fimc_ctx *ctx)
{
@@ -398,7 +414,7 @@ static int sync_capture_fmt(struct fimc_ctx *ctx)
}
dbg("w: %d, h: %d, code= %d", fmt->width, fmt->height, fmt->code);
- frame->fmt = find_mbus_format(fmt, FMT_FLAGS_CAM);
+ frame->fmt = fimc_find_format(NULL, &fmt->code, FMT_FLAGS_CAM, -1);
if (!frame->fmt) {
err("fimc source format not found\n");
return -EINVAL;
@@ -460,12 +476,10 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
frame = &ctx->d_frame;
pix = &f->fmt.pix_mp;
- frame->fmt = find_format(f, FMT_FLAGS_M2M | FMT_FLAGS_CAM);
- if (!frame->fmt) {
- v4l2_err(fimc->vid_cap.vfd,
-"Not supported capture (FIMC target) color format\n");
+ frame->fmt = fimc_find_format(&pix->pixelformat, NULL,
+ FMT_FLAGS_M2M | FMT_FLAGS_CAM, 0);
+ if (WARN(frame->fmt == NULL, "Pixel format lookup failed\n"))
return -EINVAL;
- }
for (i = 0; i < frame->fmt->colplanes; i++) {
frame->payload[i] =
@@ -645,7 +659,7 @@ static int fimc_cap_s_crop(struct file *file, void *fh,
struct v4l2_crop *cr)
static const struct v4l2_ioctl_ops fimc_capture_ioctl_ops = {
.vidioc_querycap= fimc_vidioc_querycap_capture,
- .vidioc_enum_fmt_vid_cap_mplane = fimc_vidioc_enum_fmt_mplane,
+ .vidioc_enum_fmt_vid_cap_mplane = fimc_cap_enum_fmt_mplane,
.vidioc_try_fmt_vid_cap_mplane = fimc_cap_try_fmt_mplane,
.vidioc_s_fmt_vid_cap_mplane= fimc_cap_s_fmt_mplane,
.vidioc_g_fmt_vid_cap_mplane= fimc_cap_g_fmt_mplane,
@@ -706,7 +720,6 @@ int fimc_register_capture_device(struct fimc_dev *fimc,
struct video_device *vfd;
struct fimc_vid_cap *vid_cap;
struct fimc_ctx *ctx;
- struct v4l2_format f;
struct fimc_frame *fr;
struct vb2_queue *q;
int ret = -ENOMEM;
@@ -721,9 +734,8 @@ int fimc_register_capture_device(struct fimc_dev *fimc,
ctx->state = FIMC_CTX_CAP;
/* Default format of the output frames */
- f.fmt.pix.pixelformat = V4L2_PIX_FMT_RGB32;
fr = &ctx->d_frame;
- fr->fmt = find_format(&f, FMT_FLAGS_M2M);
+ fr->fmt = fimc_find_format(NULL, NULL, FMT_FLAGS_CAM, 0);
fr->width = fr->f_width = fr->o_width = 640;
fr->height = fr->f_height = fr->o_height = 480;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 437d664..22bebd9 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -863,18 +863,17 @@ static int fimc_m2m_querycap(struct file *file, void *fh,
return 0;
}
-int fimc_vidioc_enum_fmt_mplane(struct file *file, void *priv,
- struct v4l2_fmtdesc *f)
+static int fimc_m2m_enum_fmt_mplane(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
{
struct fimc_fmt *fmt;
- if (f->index >= ARRAY_SIZE(fimc_formats))
+ fmt = fimc_find_format(NULL, NULL, FMT_FLAGS_M2M, f->index);
+ if (!fmt)
return -EINVAL;
- fmt = &fimc_formats[f->inde
[PATCH v2 09/18] s5p-fimc: Conversion to the control framework
The FIMC entity supports rotation, horizontal and vertical flip
in camera capture and memory-to-memory operation mode.
Due to atomic contexts used in mem-to-mem driver the control
values need to be cached in drivers internal data structure.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 60 +++---
drivers/media/video/s5p-fimc/fimc-core.c| 291 +++
drivers/media/video/s5p-fimc/fimc-core.h| 34 ++--
drivers/media/video/s5p-fimc/fimc-mdevice.c | 11 +-
drivers/media/video/s5p-fimc/fimc-reg.c | 32 +---
5 files changed, 186 insertions(+), 242 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 5ac8f15..887a3fc 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -28,6 +28,7 @@
#include
#include
+#include "fimc-mdevice.h"
#include "fimc-core.h"
static int fimc_stop_capture(struct fimc_dev *fimc)
@@ -260,6 +261,29 @@ static struct vb2_ops fimc_capture_qops = {
.stop_streaming = stop_streaming,
};
+/**
+ * fimc_capture_ctrls_create - initialize the control handler
+ *
+ * Initialize the capture video node control handler and populate it
+ * with FIMC specific controls. If the linked sensor subdevice does
+ * not expose a video node add its controls to the FIMC control
+ * handler. This function must be called with the graph mutex held.
+ */
+int fimc_capture_ctrls_create(struct fimc_dev *fimc)
+{
+ int ret;
+
+ if (WARN_ON(fimc->vid_cap.ctx == NULL))
+ return -ENXIO;
+ if (fimc->vid_cap.ctx->ctrls_rdy)
+ return 0;
+ ret = fimc_ctrls_create(fimc->vid_cap.ctx);
+ if (ret || subdev_has_devnode(fimc->pipeline.sensor))
+ return ret;
+ return v4l2_ctrl_add_handler(&fimc->vid_cap.ctx->ctrl_handler,
+ fimc->pipeline.sensor->ctrl_handler);
+}
+
static int fimc_capture_open(struct file *file)
{
struct fimc_dev *fimc = video_drvdata(file);
@@ -280,9 +304,10 @@ static int fimc_capture_open(struct file *file)
return ret;
}
- ++fimc->vid_cap.refcnt;
+ if (++fimc->vid_cap.refcnt == 1)
+ ret = fimc_capture_ctrls_create(fimc);
- return 0;
+ return ret;
}
static int fimc_capture_close(struct file *file)
@@ -293,11 +318,11 @@ static int fimc_capture_close(struct file *file)
if (--fimc->vid_cap.refcnt == 0) {
fimc_stop_capture(fimc);
+ fimc_ctrls_delete(fimc->vid_cap.ctx);
vb2_queue_release(&fimc->vid_cap.vbq);
}
pm_runtime_put_sync(&fimc->pdev->dev);
-
return v4l2_fh_release(file);
}
@@ -534,30 +559,6 @@ static int fimc_cap_dqbuf(struct file *file, void *priv,
return vb2_dqbuf(&fimc->vid_cap.vbq, buf, file->f_flags & O_NONBLOCK);
}
-static int fimc_cap_s_ctrl(struct file *file, void *priv,
- struct v4l2_control *ctrl)
-{
- struct fimc_dev *fimc = video_drvdata(file);
- struct fimc_ctx *ctx = fimc->vid_cap.ctx;
- int ret = -EINVAL;
-
- /* Allow any controls but 90/270 rotation while streaming */
- if (!fimc_capture_active(ctx->fimc_dev) ||
- ctrl->id != V4L2_CID_ROTATE ||
- (ctrl->value != 90 && ctrl->value != 270)) {
- ret = check_ctrl_val(ctx, ctrl);
- if (!ret) {
- ret = fimc_s_ctrl(ctx, ctrl);
- if (!ret)
- ctx->state |= FIMC_PARAMS;
- }
- }
- if (ret == -EINVAL)
- ret = v4l2_subdev_call(ctx->fimc_dev->vid_cap.sd,
- core, s_ctrl, ctrl);
- return ret;
-}
-
static int fimc_cap_cropcap(struct file *file, void *fh,
struct v4l2_cropcap *cr)
{
@@ -644,10 +645,6 @@ static const struct v4l2_ioctl_ops fimc_capture_ioctl_ops
= {
.vidioc_streamon= fimc_cap_streamon,
.vidioc_streamoff = fimc_cap_streamoff,
- .vidioc_queryctrl = fimc_vidioc_queryctrl,
- .vidioc_g_ctrl = fimc_vidioc_g_ctrl,
- .vidioc_s_ctrl = fimc_cap_s_ctrl,
-
.vidioc_g_crop = fimc_cap_g_crop,
.vidioc_s_crop = fimc_cap_s_crop,
.vidioc_cropcap = fimc_cap_cropcap,
@@ -731,6 +728,7 @@ int fimc_register_capture_device(struct fimc_dev *fimc,
if (ret)
goto err_ent;
+ vfd->ctrl_handler = &ctx->ctrl_handler;
ret = video_register_device(vfd, VFL_TYPE_GRABBER, -1);
if (ret) {
v4l2_err(v4l2_dev, "Failed to register video device\n");
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/
[PATCH v2 08/18] s5p-fimc: Conversion to use struct v4l2_fh
This is a prerequisite for the patch converting the driver to use
the control framework. As the capture driver does not use per file
handle contexts, two separate ioctl handlers are created for it
(vidioc_try_fmt_mplane, and vidioc_g_fmt_mplane) so there is no
handlers shared between the memory-to-memory and capture video node.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 114 +
drivers/media/video/s5p-fimc/fimc-core.c| 182 +++
drivers/media/video/s5p-fimc/fimc-core.h| 10 +-
3 files changed, 168 insertions(+), 138 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 22a7bf6b..5ac8f15 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -263,7 +263,10 @@ static struct vb2_ops fimc_capture_qops = {
static int fimc_capture_open(struct file *file)
{
struct fimc_dev *fimc = video_drvdata(file);
- int ret = 0;
+ int ret = v4l2_fh_open(file);
+
+ if (ret)
+ return ret;
dbg("pid: %d, state: 0x%lx", task_pid_nr(current), fimc->state);
@@ -272,11 +275,12 @@ static int fimc_capture_open(struct file *file)
return -EBUSY;
ret = pm_runtime_get_sync(&fimc->pdev->dev);
- if (ret)
+ if (ret < 0) {
+ v4l2_fh_release(file);
return ret;
+ }
++fimc->vid_cap.refcnt;
- file->private_data = fimc->vid_cap.ctx;
return 0;
}
@@ -294,22 +298,20 @@ static int fimc_capture_close(struct file *file)
pm_runtime_put_sync(&fimc->pdev->dev);
- return 0;
+ return v4l2_fh_release(file);
}
static unsigned int fimc_capture_poll(struct file *file,
struct poll_table_struct *wait)
{
- struct fimc_ctx *ctx = file->private_data;
- struct fimc_dev *fimc = ctx->fimc_dev;
+ struct fimc_dev *fimc = video_drvdata(file);
return vb2_poll(&fimc->vid_cap.vbq, file, wait);
}
static int fimc_capture_mmap(struct file *file, struct vm_area_struct *vma)
{
- struct fimc_ctx *ctx = file->private_data;
- struct fimc_dev *fimc = ctx->fimc_dev;
+ struct fimc_dev *fimc = video_drvdata(file);
return vb2_mmap(&fimc->vid_cap.vbq, vma);
}
@@ -327,8 +329,7 @@ static const struct v4l2_file_operations fimc_capture_fops
= {
static int fimc_vidioc_querycap_capture(struct file *file, void *priv,
struct v4l2_capability *cap)
{
- struct fimc_ctx *ctx = file->private_data;
- struct fimc_dev *fimc = ctx->fimc_dev;
+ struct fimc_dev *fimc = video_drvdata(file);
strncpy(cap->driver, fimc->pdev->name, sizeof(cap->driver) - 1);
strncpy(cap->card, fimc->pdev->name, sizeof(cap->card) - 1);
@@ -376,20 +377,41 @@ static int sync_capture_fmt(struct fimc_ctx *ctx)
return 0;
}
+static int fimc_cap_g_fmt_mplane(struct file *file, void *fh,
+struct v4l2_format *f)
+{
+ struct fimc_dev *fimc = video_drvdata(file);
+ struct fimc_ctx *ctx = fimc->vid_cap.ctx;
+
+ if (f->type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
+ return -EINVAL;
+
+ return fimc_fill_format(&ctx->d_frame, f);
+}
+
+static int fimc_cap_try_fmt_mplane(struct file *file, void *fh,
+ struct v4l2_format *f)
+{
+ struct fimc_dev *fimc = video_drvdata(file);
+ struct fimc_ctx *ctx = fimc->vid_cap.ctx;
+
+ return fimc_try_fmt_mplane(ctx, f);
+}
+
static int fimc_cap_s_fmt_mplane(struct file *file, void *priv,
struct v4l2_format *f)
{
- struct fimc_ctx *ctx = priv;
- struct fimc_dev *fimc = ctx->fimc_dev;
- struct fimc_frame *frame;
+ struct fimc_dev *fimc = video_drvdata(file);
+ struct fimc_ctx *ctx = fimc->vid_cap.ctx;
struct v4l2_pix_format_mplane *pix;
+ struct fimc_frame *frame;
int ret;
int i;
if (f->type != V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE)
return -EINVAL;
- ret = fimc_vidioc_try_fmt_mplane(file, priv, f);
+ ret = fimc_try_fmt_mplane(ctx, f);
if (ret)
return ret;
@@ -431,7 +453,7 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
static int fimc_cap_enum_input(struct file *file, void *priv,
struct v4l2_input *i)
{
- struct fimc_ctx *ctx = priv;
+ struct fimc_dev *fimc = video_drvdata(file);
if (i->index != 0)
return -EINVAL;
@@ -455,8 +477,8 @@ static int fimc_cap_g_input(struct file *file, void *priv,
unsigned int *i)
static int fimc_cap_streamon(struct file *file, void *priv,
enum v4l2_buf_type type)
{
- struct fi
[PATCH v2 03/18] s5p-fimc: Remove sclk_cam clock handling
The external sclk_cam clocks will be handled at the media device
driver level.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-core.c | 12 ++--
drivers/media/video/s5p-fimc/fimc-core.h |3 +--
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 22e848a..960c5f0 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -31,7 +31,7 @@
#include "fimc-core.h"
static char *fimc_clocks[MAX_FIMC_CLOCKS] = {
- "sclk_fimc", "fimc", "sclk_cam"
+ "sclk_fimc", "fimc"
};
static struct fimc_fmt fimc_formats[] = {
@@ -1608,7 +1608,6 @@ static int fimc_probe(struct platform_device *pdev)
struct samsung_fimc_driverdata *drv_data;
struct s5p_platform_fimc *pdata;
int ret = 0;
- int cap_input_index = -1;
dev_dbg(&pdev->dev, "%s():\n", __func__);
@@ -1661,14 +1660,6 @@ static int fimc_probe(struct platform_device *pdev)
goto err_req_region;
}
- fimc->num_clocks = MAX_FIMC_CLOCKS - 1;
-
- /* Check if a video capture node needs to be registered. */
- if (pdata && pdata->num_clients > 0) {
- cap_input_index = 0;
- fimc->num_clocks++;
- }
-
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
dev_err(&pdev->dev, "failed to get IRQ resource\n");
@@ -1677,6 +1668,7 @@ static int fimc_probe(struct platform_device *pdev)
}
fimc->irq = res->start;
+ fimc->num_clocks = MAX_FIMC_CLOCKS;
ret = fimc_clk_get(fimc);
if (ret)
goto err_regs_unmap;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index c088dac..f059216 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -34,7 +34,7 @@
/* Time to wait for next frame VSYNC interrupt while stopping operation. */
#define FIMC_SHUTDOWN_TIMEOUT ((100*HZ)/1000)
-#define MAX_FIMC_CLOCKS3
+#define MAX_FIMC_CLOCKS2
#define MODULE_NAME"s5p-fimc"
#define FIMC_MAX_DEVS 4
#define FIMC_MAX_OUT_BUFS 4
@@ -46,7 +46,6 @@
enum {
CLK_BUS,
CLK_GATE,
- CLK_CAM,
};
enum fimc_dev_flags {
--
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 v2 14/18] s5p-fimc: Add subdev for the FIMC processing block
This subdev interface exposes the internal scaler and color converter
functionality to user space. Resolution and media bus format can now
be configured explicitly by applications. Camera frame composition
onto the output buffer can be configured through set/get_crop at FIMC.{n}
source pad. Additionally crop, controls and composition may be
reconfigured while streaming.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 681 ---
drivers/media/video/s5p-fimc/fimc-core.c| 32 +-
drivers/media/video/s5p-fimc/fimc-core.h| 53 ++-
drivers/media/video/s5p-fimc/fimc-mdevice.c | 38 ++-
4 files changed, 705 insertions(+), 99 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 176fd9d..70590b0 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -68,6 +68,7 @@ static int fimc_start_capture(struct fimc_dev *fimc)
fimc_hw_set_effect(ctx);
fimc_hw_set_output_path(ctx);
fimc_hw_set_out_dma(ctx);
+ clear_bit(ST_CAPT_APPLY_CFG, &fimc->state);
}
spin_unlock_irqrestore(&fimc->slock, flags);
return ret;
@@ -127,6 +128,33 @@ int fimc_capture_resume(struct fimc_dev *fimc)
return 0;
}
+/**
+ * fimc_capture_config_update - apply the camera interface configuration
+ *
+ * To be called from within the interrupt handler with fimc.slock
+ * spinlock held. Camera pixel crop, rotation and image flip state will
+ * be updated in the H/W.
+ */
+int fimc_capture_config_update(struct fimc_ctx *ctx)
+{
+ struct fimc_dev *fimc = ctx->fimc_dev;
+ int ret;
+
+ spin_lock(&ctx->slock);
+ fimc_hw_set_camera_offset(fimc, &ctx->s_frame);
+ ret = fimc_set_scaler_info(ctx);
+ if (ret == 0) {
+ fimc_hw_set_prescaler(ctx);
+ fimc_hw_set_mainscaler(ctx);
+ fimc_hw_set_target_format(ctx);
+ fimc_hw_set_rotation(ctx);
+ fimc_prepare_dma_offset(ctx, &ctx->d_frame);
+ fimc_hw_set_out_dma(ctx);
+ }
+ spin_unlock(&ctx->slock);
+ return ret;
+}
+
static int start_streaming(struct vb2_queue *q)
{
struct fimc_ctx *ctx = q->drv_priv;
@@ -292,7 +320,7 @@ int fimc_capture_ctrls_create(struct fimc_dev *fimc)
if (fimc->vid_cap.ctx->ctrls_rdy)
return 0;
ret = fimc_ctrls_create(fimc->vid_cap.ctx);
- if (ret || subdev_has_devnode(fimc->pipeline.sensor))
+ if (ret || !fimc->vid_cap.vid_dev_compat)
return ret;
return v4l2_ctrl_add_handler(&fimc->vid_cap.ctx->ctrl_handler,
fimc->pipeline.sensor->ctrl_handler);
@@ -361,7 +389,6 @@ static int fimc_capture_mmap(struct file *file, struct
vm_area_struct *vma)
return vb2_mmap(&fimc->vid_cap.vbq, vma);
}
-/* video device file operations */
static const struct v4l2_file_operations fimc_capture_fops = {
.owner = THIS_MODULE,
.open = fimc_capture_open,
@@ -371,6 +398,136 @@ static const struct v4l2_file_operations
fimc_capture_fops = {
.mmap = fimc_capture_mmap,
};
+/*
+ * Format and crop negotiation helpers
+ */
+
+static struct fimc_fmt *fimc_capture_try_format(struct fimc_ctx *ctx,
+ u32 *width, u32 *height,
+ u32 *code, u32 *fourcc, int pad)
+{
+ bool rotation = ctx->rotation == 90 || ctx->rotation == 270;
+ struct fimc_dev *fimc = ctx->fimc_dev;
+ struct samsung_fimc_variant *var = fimc->variant;
+ struct fimc_pix_limit *pl = var->pix_limit;
+ struct fimc_frame *dst = &ctx->d_frame;
+ u32 depth, min_w, max_w, min_h, align_h = 4;
+ u32 mask = FMT_FLAGS_CAM;
+ struct fimc_fmt *ffmt;
+
+ /* Color conversion from/to JPEG is not supported */
+ if (pad == FIMC_SD_PAD_SOURCE &&
+ fimc_fmt_is_jpeg(ctx->s_frame.fmt->color))
+ *code = V4L2_MBUS_FMT_JPEG_1X8;
+ if (fourcc)
+ mask |= FMT_FLAGS_M2M;
+ ffmt = fimc_find_format(fourcc, code, mask, 0);
+ if (WARN_ON(!ffmt))
+ return NULL;
+ if (code)
+ *code = ffmt->mbus_code;
+ if (fourcc)
+ *fourcc = ffmt->fourcc;
+
+ if (pad == FIMC_SD_PAD_SINK) {
+ max_w = fimc_fmt_is_jpeg(ffmt->color) ?
+ pl->scaler_dis_w : pl->scaler_en_w;
+ /* Apply the camera input interface pixel constraints */
+ v4l_bound_align_image(width, 32, max_w, 4,
+ height, 32, FIMC_CAMIF_MAX_HEIGHT, 1,
+ 0);
+ return ffmt;
+ }
+ /* Can't scale or crop in transpar
[PATCH v2 16/18] s5p-fimc: Add v4l2_device notification support for single frame capture
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 47 +++
drivers/media/video/s5p-fimc/fimc-core.h|2 +
drivers/media/video/s5p-fimc/fimc-mdevice.c |1 +
include/media/s5p_fimc.h|9 +
4 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 7e45e85..06c85ae 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -1026,6 +1026,53 @@ static const struct media_entity_operations
fimc_media_ops = {
.link_setup = fimc_link_setup,
};
+/**
+ * fimc_sensor_notify - v4l2_device notification from a sensor subdev
+ * @sd: pointer to a subdev generating the notification
+ * @notification: the notification type, must be S5P_FIMC_TX_END_NOTIFY
+ * @arg: pointer to an u32 type integer that stores the frame payload value
+ *
+ * The End Of Frame notification sent by sensor subdev in its still capture
+ * mode. If there is only a single VSYNC generated by the sensor at the
+ * beginning of a frame transmission, FIMC does not issue the LastIrq
+ * (end of frame) interrupt. And this notification is used to complete the
+ * frame capture and returning a buffer to user-space. Subdev drivers should
+ * call this notification from their last 'End of frame capture' interrupt.
+ */
+void fimc_sensor_notify(struct v4l2_subdev *sd, unsigned int notification,
+ void *arg)
+{
+ struct fimc_sensor_info *sensor;
+ struct fimc_vid_buffer *buf;
+ struct fimc_md *fmd;
+ struct fimc_dev *fimc;
+ unsigned long flags;
+
+ if (sd == NULL)
+ return;
+
+ sensor = v4l2_get_subdev_hostdata(sd);
+ fmd = entity_to_fimc_mdev(&sd->entity);
+
+ spin_lock_irqsave(&fmd->slock, flags);
+ fimc = sensor ? sensor->host : NULL;
+
+ if (fimc && arg && notification == S5P_FIMC_TX_END_NOTIFY &&
+ test_bit(ST_CAPT_PEND, &fimc->state)) {
+ unsigned long irq_flags;
+ spin_lock_irqsave(&fimc->slock, irq_flags);
+ if (!list_empty(&fimc->vid_cap.active_buf_q)) {
+ buf = list_entry(fimc->vid_cap.active_buf_q.next,
+struct fimc_vid_buffer, list);
+ vb2_set_plane_payload(&buf->vb, 0, *((u32 *)arg));
+ }
+ fimc_capture_irq_handler(fimc, true);
+ fimc_deactivate_capture(fimc);
+ spin_unlock_irqrestore(&fimc->slock, irq_flags);
+ }
+ spin_unlock_irqrestore(&fmd->slock, flags);
+}
+
static int fimc_subdev_enum_mbus_code(struct v4l2_subdev *sd,
struct v4l2_subdev_fh *fh,
struct v4l2_subdev_mbus_code_enum *code)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index 6a0f613..781fb10 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -722,6 +722,8 @@ void fimc_unregister_capture_device(struct fimc_dev *fimc);
int fimc_capture_ctrls_create(struct fimc_dev *fimc);
int fimc_vid_cap_buf_queue(struct fimc_dev *fimc,
struct fimc_vid_buffer *fimc_vb);
+void fimc_sensor_notify(struct v4l2_subdev *sd, unsigned int notification,
+ void *arg);
int fimc_capture_suspend(struct fimc_dev *fimc);
int fimc_capture_resume(struct fimc_dev *fimc);
int fimc_capture_config_update(struct fimc_ctx *ctx);
diff --git a/drivers/media/video/s5p-fimc/fimc-mdevice.c
b/drivers/media/video/s5p-fimc/fimc-mdevice.c
index a932ee1..aea1790 100644
--- a/drivers/media/video/s5p-fimc/fimc-mdevice.c
+++ b/drivers/media/video/s5p-fimc/fimc-mdevice.c
@@ -728,6 +728,7 @@ static int __devinit fimc_md_probe(struct platform_device
*pdev)
v4l2_dev = &fmd->v4l2_dev;
v4l2_dev->mdev = &fmd->media_dev;
+ v4l2_dev->notify = fimc_sensor_notify;
snprintf(v4l2_dev->name, sizeof(v4l2_dev->name), "%s",
dev_name(&pdev->dev));
diff --git a/include/media/s5p_fimc.h b/include/media/s5p_fimc.h
index 086a7aa..2b58904 100644
--- a/include/media/s5p_fimc.h
+++ b/include/media/s5p_fimc.h
@@ -60,4 +60,13 @@ struct s5p_platform_fimc {
struct s5p_fimc_isp_info *isp_info;
int num_clients;
};
+
+/*
+ * v4l2_device notification id. This is only for internal use in the kernel.
+ * Sensor subdevs should issue S5P_FIMC_TX_END_NOTIFY notification in single
+ * frame capture mode when there is only one VSYNC pulse issued by the sensor
+ * at begining of the frame transmission.
+ */
+#define S5P_FIMC_TX_END_NOTIFY _IO('e', 0)
+
#endif /* S5P_FIMC_H_ */
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a mess
[PATCH v2 15/18] s5p-fimc: Add support for camera capture in JPEG format
Add support for transparent DMA transfer of JPEG data with MIPI-CSI2
USER1 format. In JPEG mode the color effect, scaling and cropping
is not supported. Same applies to image rotation and flip thus those
controls are marked as inactive when V4L2_PIX_FMT_JPEG pixelformat
is selected.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 17 ++-
drivers/media/video/s5p-fimc/fimc-core.c| 70 ++-
drivers/media/video/s5p-fimc/fimc-core.h|7 ++-
drivers/media/video/s5p-fimc/fimc-reg.c | 31
drivers/media/video/s5p-fimc/regs-fimc.h|8 +--
5 files changed, 81 insertions(+), 52 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 70590b0..7e45e85 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -65,7 +65,7 @@ static int fimc_start_capture(struct fimc_dev *fimc)
fimc_hw_set_mainscaler(ctx);
fimc_hw_set_target_format(ctx);
fimc_hw_set_rotation(ctx);
- fimc_hw_set_effect(ctx);
+ fimc_hw_set_effect(ctx, false);
fimc_hw_set_output_path(ctx);
fimc_hw_set_out_dma(ctx);
clear_bit(ST_CAPT_APPLY_CFG, &fimc->state);
@@ -693,6 +693,16 @@ static int fimc_cap_try_fmt_mplane(struct file *file, void
*fh,
return 0;
}
+static void fimc_capture_mark_jpeg_xfer(struct fimc_ctx *ctx, bool jpeg)
+{
+ ctx->scaler.enabled = !jpeg;
+ fimc_ctrls_activate(ctx, !jpeg);
+
+ if (jpeg)
+ set_bit(ST_CAPT_JPEG, &ctx->fimc_dev->state);
+ else
+ clear_bit(ST_CAPT_JPEG, &ctx->fimc_dev->state);
+}
static int fimc_cap_s_fmt_mplane(struct file *file, void *priv,
struct v4l2_format *f)
@@ -748,6 +758,9 @@ static int fimc_cap_s_fmt_mplane(struct file *file, void
*priv,
if (fimc->vid_cap.vid_dev_compat)
set_frame_crop(ff, 0, 0, mf->width, mf->height);
+ /* Switch to the transparent DMA transfer mode if required */
+ fimc_capture_mark_jpeg_xfer(ctx, fimc_fmt_is_jpeg(ff->fmt->color));
+
return ret;
}
@@ -1083,6 +1096,8 @@ static int fimc_subdev_set_fmt(struct v4l2_subdev *sd,
*mf = fmt->format;
return 0;
}
+ fimc_capture_mark_jpeg_xfer(ctx, fimc_fmt_is_jpeg(ffmt->color));
+
ff = fmt->pad == FIMC_SD_PAD_SINK ?
&ctx->s_frame : &ctx->d_frame;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index ed453b6..4d6aca5 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -160,22 +160,28 @@ static struct fimc_fmt fimc_formats[] = {
.memplanes = 2,
.colplanes = 2,
.flags = FMT_FLAGS_M2M,
+ }, {
+ .name = "JPEG encoded data",
+ .fourcc = V4L2_PIX_FMT_JPEG,
+ .color = S5P_FIMC_JPEG,
+ .depth = { 8 },
+ .memplanes = 1,
+ .colplanes = 1,
+ .mbus_code = V4L2_MBUS_FMT_JPEG_1X8,
+ .flags = FMT_FLAGS_CAM,
},
};
-int fimc_check_scaler_ratio(int sw, int sh, int dw, int dh, int rot)
+int fimc_check_scaler_ratio(struct fimc_ctx *ctx, int sw, int sh,
+ int dw, int dh, int rotation)
{
- int tx, ty;
+ if (rotation == 90 || rotation == 270)
+ swap(dw, dh);
- if (rot == 90 || rot == 270) {
- ty = dw;
- tx = dh;
- } else {
- tx = dw;
- ty = dh;
- }
+ if (!ctx->scaler.enabled)
+ return (sw == dw && sh == dh) ? 0 : -EINVAL;
- if ((sw >= SCALER_MAX_HRATIO * tx) || (sh >= SCALER_MAX_VRATIO * ty))
+ if ((sw >= SCALER_MAX_HRATIO * dw) || (sh >= SCALER_MAX_VRATIO * dh))
return -EINVAL;
return 0;
@@ -311,7 +317,7 @@ static int stop_streaming(struct vb2_queue *q)
return 0;
}
-void fimc_capture_irq_handler(struct fimc_dev *fimc)
+void fimc_capture_irq_handler(struct fimc_dev *fimc, bool rel_buf)
{
struct fimc_vid_cap *cap = &fimc->vid_cap;
struct fimc_vid_buffer *v_buf;
@@ -319,7 +325,7 @@ void fimc_capture_irq_handler(struct fimc_dev *fimc)
struct timespec ts;
if (!list_empty(&cap->active_buf_q) &&
- test_bit(ST_CAPT_RUN, &fimc->state)) {
+ test_bit(ST_CAPT_RUN, &fimc->state) && rel_buf) {
ktime_get_real_ts(&ts);
v_buf = active_queue_pop(cap);
@@ -354,7 +360,8 @@ void fimc_capture_irq_handler(struct fimc_dev *fimc)
}
if (cap->active_buf_cnt == 0)
[PATCH v2 18/18] s5p-fimc: Add runtime PM support in the camera capture driver
Add support for whole pipeline suspend/resume. Sensors must support
suspend/resume through s_power subdev operation.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 79 ---
drivers/media/video/s5p-fimc/fimc-core.c| 10 ++--
drivers/media/video/s5p-fimc/fimc-core.h|1 +
3 files changed, 64 insertions(+), 26 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 981e0a0..23a7f91 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -74,7 +74,7 @@ static int fimc_start_capture(struct fimc_dev *fimc)
return ret;
}
-static int fimc_stop_capture(struct fimc_dev *fimc)
+static int fimc_stop_capture(struct fimc_dev *fimc, bool suspend)
{
struct fimc_vid_cap *cap = &fimc->vid_cap;
struct fimc_vid_buffer *buf;
@@ -90,26 +90,28 @@ static int fimc_stop_capture(struct fimc_dev *fimc)
wait_event_timeout(fimc->irq_queue,
!test_bit(ST_CAPT_SHUT, &fimc->state),
- FIMC_SHUTDOWN_TIMEOUT);
+ (2*HZ/10)); /* 200 ms */
spin_lock_irqsave(&fimc->slock, flags);
- fimc->state &= ~(1 << ST_CAPT_RUN | 1 << ST_CAPT_PEND |
-1 << ST_CAPT_SHUT | 1 << ST_CAPT_STREAM |
-1 << ST_CAPT_ISP_STREAM);
+ fimc->state &= ~(1 << ST_CAPT_RUN | 1 << ST_CAPT_SHUT |
+1 << ST_CAPT_STREAM | 1 << ST_CAPT_ISP_STREAM);
+ if (!suspend)
+ fimc->state &= ~(1 << ST_CAPT_PEND | 1 << ST_CAPT_SUSPENDED);
- fimc->vid_cap.active_buf_cnt = 0;
-
- /* Release buffers that were enqueued in the driver by videobuf2. */
- while (!list_empty(&cap->pending_buf_q)) {
+ /* Release unused buffers */
+ while (!suspend && !list_empty(&cap->pending_buf_q)) {
buf = fimc_pending_queue_pop(cap);
vb2_buffer_done(&buf->vb, VB2_BUF_STATE_ERROR);
}
-
+ /* If suspending put unused buffers onto pending queue */
while (!list_empty(&cap->active_buf_q)) {
buf = fimc_active_queue_pop(cap);
- vb2_buffer_done(&buf->vb, VB2_BUF_STATE_ERROR);
+ if (suspend)
+ fimc_pending_queue_add(cap, buf);
+ else
+ vb2_buffer_done(&buf->vb, VB2_BUF_STATE_ERROR);
}
-
+ set_bit(ST_CAPT_SUSPENDED, &fimc->state);
spin_unlock_irqrestore(&fimc->slock, flags);
dbg("state: 0x%lx", fimc->state);
@@ -118,13 +120,39 @@ static int fimc_stop_capture(struct fimc_dev *fimc)
int fimc_capture_suspend(struct fimc_dev *fimc)
{
- /* TODO: */
- return -EBUSY;
+ bool suspend = fimc_capture_in_use(fimc);
+
+ int ret = fimc_stop_capture(fimc, suspend);
+ if (ret)
+ return ret;
+ return fimc_pipeline_shutdown(fimc);
}
+static void buffer_queue(struct vb2_buffer *vb);
+
int fimc_capture_resume(struct fimc_dev *fimc)
{
- /* TODO: */
+ struct fimc_vid_cap *vid_cap = &fimc->vid_cap;
+ struct fimc_vid_buffer *buf;
+ int i;
+
+ if (!test_and_clear_bit(ST_CAPT_SUSPENDED, &fimc->state))
+ return 0;
+
+ INIT_LIST_HEAD(&fimc->vid_cap.active_buf_q);
+ vid_cap->buf_index = 0;
+ fimc_pipeline_initialize(fimc, &fimc->vid_cap.vfd->entity,
+false);
+ fimc_start_capture(fimc);
+
+ clear_bit(ST_CAPT_SUSPENDED, &fimc->state);
+
+ for (i = 0; i < vid_cap->reqbufs_count; i++) {
+ if (list_empty(&vid_cap->pending_buf_q))
+ break;
+ buf = fimc_pending_queue_pop(vid_cap);
+ buffer_queue(&buf->vb);
+ }
return 0;
}
@@ -184,7 +212,7 @@ static int stop_streaming(struct vb2_queue *q)
if (!fimc_capture_active(fimc))
return -EINVAL;
- return fimc_stop_capture(fimc);
+ return fimc_stop_capture(fimc, false);
}
static unsigned int get_plane_size(struct fimc_frame *fr, unsigned int plane)
@@ -251,8 +279,9 @@ static void buffer_queue(struct vb2_buffer *vb)
spin_lock_irqsave(&fimc->slock, flags);
fimc_prepare_addr(ctx, &buf->vb, &ctx->d_frame, &buf->paddr);
- if (!test_bit(ST_CAPT_STREAM, &fimc->state)
-&& vid_cap->active_buf_cnt < FIMC_MAX_OUT_BUFS) {
+ if (!test_bit(ST_CAPT_SUSPENDED, &fimc->state) &&
+ !test_bit(ST_CAPT_STREAM, &fimc->state) &&
+ vid_cap->active_buf_cnt < FIMC_MAX_OUT_BUFS) {
/* Setup the buffer directly for processing. */
int buf_id = (vid_cap->reqbufs_count == 1) ? -1 :
vid_cap->buf_index;
@@ -340,6 +369,7 @@ static int fimc_capture_open(struct file *file)
if (fi
[PATCH v2 17/18] s5p-fimc: Use consistent names for the buffer list functions
Also correct and improve *_queue_add/pop functions description.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c |6 ++--
drivers/media/video/s5p-fimc/fimc-core.c|6 ++--
drivers/media/video/s5p-fimc/fimc-core.h| 38 +-
3 files changed, 31 insertions(+), 19 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 06c85ae..981e0a0 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -101,12 +101,12 @@ static int fimc_stop_capture(struct fimc_dev *fimc)
/* Release buffers that were enqueued in the driver by videobuf2. */
while (!list_empty(&cap->pending_buf_q)) {
- buf = pending_queue_pop(cap);
+ buf = fimc_pending_queue_pop(cap);
vb2_buffer_done(&buf->vb, VB2_BUF_STATE_ERROR);
}
while (!list_empty(&cap->active_buf_q)) {
- buf = active_queue_pop(cap);
+ buf = fimc_active_queue_pop(cap);
vb2_buffer_done(&buf->vb, VB2_BUF_STATE_ERROR);
}
@@ -259,7 +259,7 @@ static void buffer_queue(struct vb2_buffer *vb)
fimc_hw_set_output_addr(fimc, &buf->paddr, buf_id);
buf->index = vid_cap->buf_index;
- active_queue_add(vid_cap, buf);
+ fimc_active_queue_add(vid_cap, buf);
if (++vid_cap->buf_index >= FIMC_MAX_OUT_BUFS)
vid_cap->buf_index = 0;
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 4d6aca5..078793d 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -328,7 +328,7 @@ void fimc_capture_irq_handler(struct fimc_dev *fimc, bool
rel_buf)
test_bit(ST_CAPT_RUN, &fimc->state) && rel_buf) {
ktime_get_real_ts(&ts);
- v_buf = active_queue_pop(cap);
+ v_buf = fimc_active_queue_pop(cap);
tv = &v_buf->vb.v4l2_buf.timestamp;
tv->tv_sec = ts.tv_sec;
@@ -345,12 +345,12 @@ void fimc_capture_irq_handler(struct fimc_dev *fimc, bool
rel_buf)
if (!list_empty(&cap->pending_buf_q)) {
- v_buf = pending_queue_pop(cap);
+ v_buf = fimc_pending_queue_pop(cap);
fimc_hw_set_output_addr(fimc, &v_buf->paddr, cap->buf_index);
v_buf->index = cap->buf_index;
/* Move the buffer to the capture active queue */
- active_queue_add(cap, v_buf);
+ fimc_active_queue_add(cap, v_buf);
dbg("next frame: %d, done frame: %d",
fimc_hw_get_frame_index(fimc), v_buf->index);
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index 781fb10..ee91d88 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -744,22 +744,27 @@ static inline void fimc_deactivate_capture(struct
fimc_dev *fimc)
}
/*
- * Add buf to the capture active buffers queue.
- * Locking: Need to be called with fimc_dev::slock held.
+ * Buffer list manipulation functions. Must be called with fimc.slock held.
*/
-static inline void active_queue_add(struct fimc_vid_cap *vid_cap,
- struct fimc_vid_buffer *buf)
+
+/**
+ * fimc_active_queue_add - add buffer to the capture active buffers queue
+ * @buf: buffer to add to the active buffers list
+ */
+static inline void fimc_active_queue_add(struct fimc_vid_cap *vid_cap,
+struct fimc_vid_buffer *buf)
{
list_add_tail(&buf->list, &vid_cap->active_buf_q);
vid_cap->active_buf_cnt++;
}
-/*
- * Pop a video buffer from the capture active buffers queue
- * Locking: Need to be called with fimc_dev::slock held.
+/**
+ * fimc_active_queue_pop - pop buffer from the capture active buffers queue
+ *
+ * The caller must assure the active_buf_q list is not empty.
*/
-static inline struct fimc_vid_buffer *
-active_queue_pop(struct fimc_vid_cap *vid_cap)
+static inline struct fimc_vid_buffer *fimc_active_queue_pop(
+ struct fimc_vid_cap *vid_cap)
{
struct fimc_vid_buffer *buf;
buf = list_entry(vid_cap->active_buf_q.next,
@@ -769,16 +774,23 @@ active_queue_pop(struct fimc_vid_cap *vid_cap)
return buf;
}
-/* Add video buffer to the capture pending buffers queue */
+/**
+ * fimc_pending_queue_add - add buffer to the capture pending buffers queue
+ * @buf: buffer to add to the pending buffers list
+ */
static inline void fimc_pending_queue_add(struct fimc_vid_cap *vid_cap,
struct fimc_vid_buffer *buf)
{
list_add_tail(&buf->list, &vid_cap->pending_buf_q);
}
-/* Add v
[PATCH v2 13/18] s5p-fimc: Convert to use media pipeline operations
Add format negotiation routine for sensor subdevs not exposing
a device node. TRY_FMT ioctl is completed by a subsequent patch
adding the capture subdev. This way the try_fmt routines can be
common for the subdev and the video node.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 109 +--
drivers/media/video/s5p-fimc/fimc-core.c| 125 +++
drivers/media/video/s5p-fimc/fimc-core.h| 14 ++-
drivers/media/video/s5p-fimc/fimc-reg.c |8 +-
4 files changed, 125 insertions(+), 131 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index a2a13e6..176fd9d 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -75,11 +75,9 @@ static int fimc_start_capture(struct fimc_dev *fimc)
static int fimc_stop_capture(struct fimc_dev *fimc)
{
- unsigned long flags;
- struct fimc_vid_cap *cap;
+ struct fimc_vid_cap *cap = &fimc->vid_cap;
struct fimc_vid_buffer *buf;
-
- cap = &fimc->vid_cap;
+ unsigned long flags;
if (!fimc_capture_active(fimc))
return 0;
@@ -93,11 +91,10 @@ static int fimc_stop_capture(struct fimc_dev *fimc)
!test_bit(ST_CAPT_SHUT, &fimc->state),
FIMC_SHUTDOWN_TIMEOUT);
- v4l2_subdev_call(cap->sd, video, s_stream, 0);
-
spin_lock_irqsave(&fimc->slock, flags);
fimc->state &= ~(1 << ST_CAPT_RUN | 1 << ST_CAPT_PEND |
-1 << ST_CAPT_SHUT | 1 << ST_CAPT_STREAM);
+1 << ST_CAPT_SHUT | 1 << ST_CAPT_STREAM |
+1 << ST_CAPT_ISP_STREAM);
fimc->vid_cap.active_buf_cnt = 0;
@@ -113,9 +110,9 @@ static int fimc_stop_capture(struct fimc_dev *fimc)
}
spin_unlock_irqrestore(&fimc->slock, flags);
-
dbg("state: 0x%lx", fimc->state);
- return 0;
+
+ return fimc_pipeline_s_stream(fimc, 0);
}
int fimc_capture_suspend(struct fimc_dev *fimc)
@@ -200,15 +197,13 @@ static int buffer_prepare(struct vb2_buffer *vb)
return -EINVAL;
for (i = 0; i < ctx->d_frame.fmt->memplanes; i++) {
- unsigned long size = get_plane_size(&ctx->d_frame, i);
-
+ unsigned long size = ctx->d_frame.payload[i];
if (vb2_plane_size(vb, i) < size) {
v4l2_err(ctx->fimc_dev->vid_cap.vfd,
"User buffer too small (%ld < %ld)\n",
vb2_plane_size(vb, i), size);
return -EINVAL;
}
-
vb2_set_plane_payload(vb, i, size);
}
@@ -217,10 +212,10 @@ static int buffer_prepare(struct vb2_buffer *vb)
static void buffer_queue(struct vb2_buffer *vb)
{
- struct fimc_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
- struct fimc_dev *fimc = ctx->fimc_dev;
struct fimc_vid_buffer *buf
= container_of(vb, struct fimc_vid_buffer, vb);
+ struct fimc_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
+ struct fimc_dev *fimc = ctx->fimc_dev;
struct fimc_vid_cap *vid_cap = &fimc->vid_cap;
unsigned long flags;
int min_bufs;
@@ -247,9 +242,14 @@ static void buffer_queue(struct vb2_buffer *vb)
min_bufs = vid_cap->reqbufs_count > 1 ? 2 : 1;
if (vid_cap->active_buf_cnt >= min_bufs &&
- !test_and_set_bit(ST_CAPT_STREAM, &fimc->state))
+ !test_and_set_bit(ST_CAPT_STREAM, &fimc->state)) {
fimc_activate_capture(ctx);
+ spin_unlock_irqrestore(&fimc->slock, flags);
+ if (!test_and_set_bit(ST_CAPT_ISP_STREAM, &fimc->state))
+ fimc_pipeline_s_stream(fimc, 1);
+ return;
+ }
spin_unlock_irqrestore(&fimc->slock, flags);
}
@@ -312,15 +312,21 @@ static int fimc_capture_open(struct file *file)
if (fimc_m2m_active(fimc))
return -EBUSY;
- ret = pm_runtime_get_sync(&fimc->pdev->dev);
- if (ret < 0) {
- v4l2_fh_release(file);
- return ret;
- }
-
- if (++fimc->vid_cap.refcnt == 1)
+ pm_runtime_get_sync(&fimc->pdev->dev);
+
+ if (++fimc->vid_cap.refcnt == 1) {
+ ret = fimc_pipeline_initialize(fimc,
+ &fimc->vid_cap.vfd->entity, true);
+ if (ret < 0) {
+ dev_err(&fimc->pdev->dev,
+ "Video pipeline initialization failed\n");
+ pm_runtime_put_sync(&fimc->pdev->dev);
+ fimc->vid_cap.refcnt--;
+ v4l2_fh_release(file);
+ return ret;
+ }
ret = fimc_capture_ctrls_create(fimc);
-
+ }
[PATCH v2 07/18] s5p-fimc: Add the media device driver
The fimc media device driver is hooked onto "s5p-fimc-md" platform device.
Such a platform device need to be added in a board initialization code
and then camera sensors need to be specified as it's platform data.
The "s5p-fimc-md" device is a top level entity for all FIMC, mipi-csis
and sensor devices.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/s5p-fimc/Makefile |2 +-
drivers/media/video/s5p-fimc/fimc-core.c| 22 +-
drivers/media/video/s5p-fimc/fimc-core.h| 12 +-
drivers/media/video/s5p-fimc/fimc-mdevice.c | 792 +++
drivers/media/video/s5p-fimc/fimc-mdevice.h | 118
include/media/s5p_fimc.h|2 +
7 files changed, 932 insertions(+), 18 deletions(-)
create mode 100644 drivers/media/video/s5p-fimc/fimc-mdevice.c
create mode 100644 drivers/media/video/s5p-fimc/fimc-mdevice.h
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 4847c2c..8de3476 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -935,7 +935,7 @@ config VIDEO_MX2
config VIDEO_SAMSUNG_S5P_FIMC
tristate "Samsung S5P and EXYNOS4 camera host interface driver"
- depends on VIDEO_DEV && VIDEO_V4L2 && PLAT_S5P
+ depends on VIDEO_DEV && VIDEO_V4L2 && PLAT_S5P && VIDEO_V4L2_SUBDEV_API
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
---help---
diff --git a/drivers/media/video/s5p-fimc/Makefile
b/drivers/media/video/s5p-fimc/Makefile
index df6954a..33dec7f 100644
--- a/drivers/media/video/s5p-fimc/Makefile
+++ b/drivers/media/video/s5p-fimc/Makefile
@@ -1,4 +1,4 @@
-s5p-fimc-objs := fimc-core.o fimc-reg.o fimc-capture.o
+s5p-fimc-objs := fimc-core.o fimc-reg.o fimc-capture.o fimc-mdevice.o
s5p-csis-objs := mipi-csis.o
obj-$(CONFIG_VIDEO_S5P_MIPI_CSIS) += s5p-csis.o
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index abc6269..cfc033b 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -29,6 +29,7 @@
#include
#include "fimc-core.h"
+#include "fimc-mdevice.h"
static char *fimc_clocks[MAX_FIMC_CLOCKS] = {
"sclk_fimc", "fimc"
@@ -1968,31 +1969,22 @@ static const struct dev_pm_ops fimc_pm_ops = {
static struct platform_driver fimc_driver = {
.probe = fimc_probe,
- .remove = __devexit_p(fimc_remove),
+ .remove = __devexit_p(fimc_remove),
.id_table = fimc_driver_ids,
.driver = {
- .name = MODULE_NAME,
+ .name = FIMC_MODULE_NAME,
.owner = THIS_MODULE,
.pm = &fimc_pm_ops,
}
};
-static int __init fimc_init(void)
+
+int __init fimc_register_driver(void)
{
- int ret = platform_driver_register(&fimc_driver);
- if (ret)
- err("platform_driver_register failed: %d\n", ret);
- return ret;
+ return platform_driver_probe(&fimc_driver, fimc_probe);
}
-static void __exit fimc_exit(void)
+void __exit fimc_unregister_driver(void)
{
platform_driver_unregister(&fimc_driver);
}
-
-module_init(fimc_init);
-module_exit(fimc_exit);
-
-MODULE_AUTHOR("Sylwester Nawrocki ");
-MODULE_DESCRIPTION("S5P FIMC camera host interface/video postprocessor
driver");
-MODULE_LICENSE("GPL");
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index fe82bf7..f886167 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -36,7 +36,7 @@
/* Time to wait for next frame VSYNC interrupt while stopping operation. */
#define FIMC_SHUTDOWN_TIMEOUT ((100*HZ)/1000)
#define MAX_FIMC_CLOCKS2
-#define MODULE_NAME"s5p-fimc"
+#define FIMC_MODULE_NAME "s5p-fimc"
#define FIMC_MAX_DEVS 4
#define FIMC_MAX_OUT_BUFS 4
#define SCALER_MAX_HRATIO 64
@@ -387,6 +387,12 @@ struct samsung_fimc_driverdata {
int num_entities;
};
+struct fimc_pipeline {
+ struct media_pipeline *pipe;
+ struct v4l2_subdev *sensor;
+ struct v4l2_subdev *csis;
+};
+
struct fimc_ctx;
/**
@@ -408,6 +414,7 @@ struct fimc_ctx;
* @vid_cap: camera capture device information
* @state: flags used to synchronize m2m and capture mode operation
* @alloc_ctx: videobuf2 memory allocator context
+ * @pipeline: fimc pipeline information
*/
struct fimc_dev {
spinlock_t slock;
@@ -427,6 +434,7 @@ struct fimc_dev {
struct fimc_vid_cap vid_cap;
unsigned long state;
struct vb2_alloc_ctx*alloc_ctx;
+ struct fimc_pipelinepipeline;
};
/**
@@ -645,6 +653,8 @@ int fimc_prepare_addr(struct fimc_ctx *ctx, struct
vb2_buffer *vb,
int fimc_register_m2m_
[PATCH v2 11/18] s5p-fimc: Add PM helper function for streaming control
Create a helper function for (re)starting streaming in PM resume calls.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c | 80 ---
drivers/media/video/s5p-fimc/fimc-core.c|4 +-
drivers/media/video/s5p-fimc/fimc-core.h|3 +
3 files changed, 52 insertions(+), 35 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index f9beee8..a7d579d 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -31,6 +31,48 @@
#include "fimc-mdevice.h"
#include "fimc-core.h"
+/**
+ * fimc_start_capture - initialize the H/W for camera capture operation
+ *
+ * Initialize the camera capture datapath so when this function successfuly
+ * completes all what is needed to start the capture pipeline is asserting
+ * the global capture bit ImgCptEn.
+ */
+static int fimc_start_capture(struct fimc_dev *fimc)
+{
+ struct fimc_ctx *ctx = fimc->vid_cap.ctx;
+ struct fimc_sensor_info *sensor;
+ unsigned long flags;
+ int ret = 0;
+
+ if (fimc->pipeline.sensor == NULL || ctx == NULL)
+ return -EIO;
+ sensor = v4l2_get_subdev_hostdata(fimc->pipeline.sensor);
+
+ spin_lock_irqsave(&fimc->slock, flags);
+ fimc_prepare_dma_offset(ctx, &ctx->d_frame);
+ fimc_set_yuv_order(ctx);
+
+ fimc_hw_set_camera_polarity(fimc, sensor->pdata);
+ fimc_hw_set_camera_type(fimc, sensor->pdata);
+ fimc_hw_set_camera_source(fimc, sensor->pdata);
+ fimc_hw_set_camera_offset(fimc, &ctx->s_frame);
+
+ ret = fimc_set_scaler_info(ctx);
+ if (!ret) {
+ fimc_hw_set_input_path(ctx);
+ fimc_hw_set_prescaler(ctx);
+ fimc_hw_set_mainscaler(ctx);
+ fimc_hw_set_target_format(ctx);
+ fimc_hw_set_rotation(ctx);
+ fimc_hw_set_effect(ctx);
+ fimc_hw_set_output_path(ctx);
+ fimc_hw_set_out_dma(ctx);
+ }
+ spin_unlock_irqrestore(&fimc->slock, flags);
+ return ret;
+}
+
static int fimc_stop_capture(struct fimc_dev *fimc)
{
unsigned long flags;
@@ -92,47 +134,19 @@ static int start_streaming(struct vb2_queue *q)
{
struct fimc_ctx *ctx = q->drv_priv;
struct fimc_dev *fimc = ctx->fimc_dev;
- struct s5p_fimc_isp_info *isp_info;
+ struct fimc_vid_cap *vid_cap = &fimc->vid_cap;
int ret;
fimc_hw_reset(fimc);
- ret = v4l2_subdev_call(fimc->vid_cap.sd, video, s_stream, 1);
- if (ret && ret != -ENOIOCTLCMD)
- return ret;
+ vid_cap->active_buf_cnt = 0;
+ vid_cap->frame_count = 0;
+ vid_cap->buf_index = 0;
- ret = fimc_prepare_config(ctx, ctx->state);
+ ret = fimc_start_capture(fimc);
if (ret)
return ret;
- isp_info = &fimc->pdata->isp_info[fimc->vid_cap.input_index];
- fimc_hw_set_camera_type(fimc, isp_info);
- fimc_hw_set_camera_source(fimc, isp_info);
- fimc_hw_set_camera_offset(fimc, &ctx->s_frame);
-
- if (ctx->state & FIMC_PARAMS) {
- ret = fimc_set_scaler_info(ctx);
- if (ret) {
- err("Scaler setup error");
- return ret;
- }
- fimc_hw_set_input_path(ctx);
- fimc_hw_set_prescaler(ctx);
- fimc_hw_set_mainscaler(ctx);
- fimc_hw_set_target_format(ctx);
- fimc_hw_set_rotation(ctx);
- fimc_hw_set_effect(ctx);
- }
-
- fimc_hw_set_output_path(ctx);
- fimc_hw_set_out_dma(ctx);
-
- INIT_LIST_HEAD(&fimc->vid_cap.pending_buf_q);
- INIT_LIST_HEAD(&fimc->vid_cap.active_buf_q);
- fimc->vid_cap.active_buf_cnt = 0;
- fimc->vid_cap.frame_count = 0;
- fimc->vid_cap.buf_index = 0;
-
set_bit(ST_CAPT_PEND, &fimc->state);
return 0;
}
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 2aa4612..437d664 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -468,7 +468,7 @@ int fimc_prepare_addr(struct fimc_ctx *ctx, struct
vb2_buffer *vb,
}
/* Set order for 1 and 2 plane YCBCR 4:2:2 formats. */
-static void fimc_set_yuv_order(struct fimc_ctx *ctx)
+void fimc_set_yuv_order(struct fimc_ctx *ctx)
{
/* The one only mode supported in SoC. */
ctx->in_order_2p = S5P_FIMC_LSB_CRCB;
@@ -510,7 +510,7 @@ static void fimc_set_yuv_order(struct fimc_ctx *ctx)
dbg("ctx->out_order_1p= %d", ctx->out_order_1p);
}
-static void fimc_prepare_dma_offset(struct fimc_ctx *ctx, struct fimc_frame *f)
+void fimc_prepare_dma_offset(struct fimc_ctx *ctx, struct fimc_frame *f)
{
struct samsung_fimc_variant *variant = ctx->fimc_dev->variant;
[PATCH v2 02/18] s5p-fimc: Remove registration of video nodes from probe()
Do not register video nodes during FIMC device probe. Also make
fimc_register_m2m_device() public for use by the media device driver.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-capture.c |1 +
drivers/media/video/s5p-fimc/fimc-core.c| 30 +++---
drivers/media/video/s5p-fimc/fimc-core.h|1 +
3 files changed, 10 insertions(+), 22 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-capture.c
b/drivers/media/video/s5p-fimc/fimc-capture.c
index 2748cca..c7bb6f6 100644
--- a/drivers/media/video/s5p-fimc/fimc-capture.c
+++ b/drivers/media/video/s5p-fimc/fimc-capture.c
@@ -926,4 +926,5 @@ void fimc_unregister_capture_device(struct fimc_dev *fimc)
video_unregister_device(vfd);
}
kfree(fimc->vid_cap.ctx);
+ fimc->vid_cap.ctx = NULL;
}
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index af0d966..22e848a 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -1491,7 +1491,7 @@ static struct v4l2_m2m_ops m2m_ops = {
.job_abort = fimc_job_abort,
};
-static int fimc_register_m2m_device(struct fimc_dev *fimc)
+int fimc_register_m2m_device(struct fimc_dev *fimc)
{
struct video_device *vfd;
struct platform_device *pdev;
@@ -1565,13 +1565,16 @@ err_m2m_r1:
void fimc_unregister_m2m_device(struct fimc_dev *fimc)
{
- if (fimc == NULL)
+ if (!fimc)
return;
- v4l2_m2m_release(fimc->m2m.m2m_dev);
+ if (fimc->m2m.m2m_dev)
+ v4l2_m2m_release(fimc->m2m.m2m_dev);
v4l2_device_unregister(&fimc->m2m.v4l2_dev);
- media_entity_cleanup(&fimc->m2m.vfd->entity);
- video_unregister_device(fimc->m2m.vfd);
+ if (fimc->m2m.vfd) {
+ media_entity_cleanup(&fimc->m2m.vfd->entity);
+ video_unregister_device(fimc->m2m.vfd);
+ }
}
static void fimc_clk_put(struct fimc_dev *fimc)
@@ -1700,25 +1703,12 @@ static int fimc_probe(struct platform_device *pdev)
goto err_irq;
}
- ret = fimc_register_m2m_device(fimc);
- if (ret)
- goto err_irq;
-
- /* At least one camera sensor is required to register capture node */
- if (cap_input_index >= 0) {
- ret = fimc_register_capture_device(fimc);
- if (ret)
- goto err_m2m;
- }
-
dev_dbg(&pdev->dev, "%s(): fimc-%d registered successfully\n",
__func__, fimc->id);
pm_runtime_put_sync(&fimc->pdev->dev);
return 0;
-err_m2m:
- fimc_unregister_m2m_device(fimc);
err_irq:
free_irq(fimc->irq, fimc);
err_clk:
@@ -1730,7 +1720,6 @@ err_req_region:
kfree(fimc->regs_res);
err_info:
kfree(fimc);
-
return ret;
}
@@ -1805,9 +1794,6 @@ static int __devexit fimc_remove(struct platform_device
*pdev)
fimc_suspend(&pdev->dev);
pm_runtime_set_suspended(&pdev->dev);
- fimc_unregister_m2m_device(fimc);
- fimc_unregister_capture_device(fimc);
-
vb2_dma_contig_cleanup_ctx(fimc->alloc_ctx);
clk_disable(fimc->clock[CLK_BUS]);
diff --git a/drivers/media/video/s5p-fimc/fimc-core.h
b/drivers/media/video/s5p-fimc/fimc-core.h
index 55c1410..c088dac 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.h
+++ b/drivers/media/video/s5p-fimc/fimc-core.h
@@ -644,6 +644,7 @@ int fimc_set_scaler_info(struct fimc_ctx *ctx);
int fimc_prepare_config(struct fimc_ctx *ctx, u32 flags);
int fimc_prepare_addr(struct fimc_ctx *ctx, struct vb2_buffer *vb,
struct fimc_frame *frame, struct fimc_addr *paddr);
+int fimc_register_m2m_device(struct fimc_dev *fimc);
/* -*/
/* fimc-capture.c */
--
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
Re: Sveon stv22 patches
Helo again: Sorry for my mistakes and errors, is my first patch, thanks for the doc, yes i have diffed in the wrong direction. i don't know how use git to patch but i'm gonna make a new patches, i expect the patches will be ok this time. Ok. The rc.map.h patch is not needed because we are using DIGIBOX rc.map, one less patch needed then. Thanks for your time Emilio David Diaus López -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC, PATCH] USB: EHCI: Allow users to override 80% max periodic bandwidth
On 10:30 Wed 22 Jun , matt mooney wrote:
> On 20:02 Wed 22 Jun , Kirill Smelkov wrote:
> > There are cases, when 80% max isochronous bandwidth is too limiting.
> >
> > For example I have two USB video capture cards which stream uncompressed
> > video, and to stream full NTSC + PAL videos we'd need
> >
> > NTSC 640x480 YUV422 @30fps ~17.6 MB/s
> > PAL 720x576 YUV422 @25fps ~19.7 MB/s
> >
> > isoc bandwidth.
> >
> > Now, due to limited alt settings in capture devices NTSC one ends up
> > streaming with max_pkt_size=2688 and PAL with max_pkt_size=2892, both
> > with interval=1. In terms of microframe time allocation this gives
> >
> > NTSC~53us
> > PAL ~57us
> >
> > and together
> >
> > ~110us > 100us == 80% of 125us uframe time.
> >
> > So those two devices can't work together simultaneously because the'd
> > over allocate isochronous bandwidth.
> >
> > 80% seemed a bit arbitrary to me, and I've tried to raise it to 90% and
> > both devices started to work together, so I though sometimes it would be
> > a good idea for users to override hardcoded default of max 80% isoc
> > bandwidth.
>
> There is nothing arbitrary about 80%. The USB 2.0 Specification constrains
> periodic transfers for high-speed endpoints to 80% of the microframe. See
> section 5.6.4.
>
Looking at the patch, I see that you probably already knew that.
So I digress and defer to the USB experts ;)
-mfm
> > After all, isn't it a user who should decide how to load the bus? If I
> > can live with 10% or even 5% bulk bandwidth that should be ok. I'm a USB
> > newcomer, but that 80% seems to be chosen pretty arbitrary to me, just
> > to serve as a reasonable default.
> >
> > NOTE: for two streams with max_pkt_size=3072 (worst case) both time
> > allocation would be 60us+60us=120us which is 96% periodic bandwidth
> > leaving 4% for bulk and control. I think this should work too.
> >
> > Signed-off-by: Kirill Smelkov
> > Cc: Alan Stern
> > ---
> > drivers/usb/host/ehci-hcd.c | 16
> > drivers/usb/host/ehci-sched.c | 17 +++--
> > 2 files changed, 23 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> > index c606b02..1d36e72 100644
> > --- a/drivers/usb/host/ehci-hcd.c
> > +++ b/drivers/usb/host/ehci-hcd.c
> > @@ -112,6 +112,14 @@ static unsigned int hird;
> > module_param(hird, int, S_IRUGO);
> > MODULE_PARM_DESC(hird, "host initiated resume duration, +1 for each
> > 75us\n");
> >
> > +/*
> > + * max periodic time per microframe
> > + * (be careful, USB 2.0 requires it to be 100us = 80% of 125us)
> > + */
> > +static unsigned int uframe_periodic_max = 100;
> > +module_param(uframe_periodic_max, uint, S_IRUGO);
> > +MODULE_PARM_DESC(uframe_periodic_max, "maximum allowed periodic part of a
> > microframe, us");
> > +
> > #defineINTR_MASK (STS_IAA | STS_FATAL | STS_PCD | STS_ERR | STS_INT)
> >
> >
> > /*-*/
> > @@ -571,6 +579,14 @@ static int ehci_init(struct usb_hcd *hcd)
> > hcc_params = ehci_readl(ehci, &ehci->caps->hcc_params);
> >
> > /*
> > +* tell user, if using non-standard (80% == 100 usec/uframe) bandwidth
> > +*/
> > + if (uframe_periodic_max != 100)
> > + ehci_info(ehci, "using non-standard max periodic bandwith "
> > + "(%u%% == %u usec/uframe)",
> > + 100*uframe_periodic_max/125,
> > uframe_periodic_max);
> > +
> > + /*
> > * hw default: 1K periodic list heads, one per frame.
> > * periodic_size can shrink by USBCMD update if hcc_params allows.
> > */
> > diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
> > index d12426f..fb374f2 100644
> > --- a/drivers/usb/host/ehci-sched.c
> > +++ b/drivers/usb/host/ehci-sched.c
> > @@ -172,7 +172,7 @@ periodic_usecs (struct ehci_hcd *ehci, unsigned frame,
> > unsigned uframe)
> > }
> > }
> > #ifdef DEBUG
> > - if (usecs > 100)
> > + if (usecs > uframe_periodic_max)
> > ehci_err (ehci, "uframe %d sched overrun: %d usecs\n",
> > frame * 8 + uframe, usecs);
> > #endif
> > @@ -709,11 +709,8 @@ static int check_period (
> > if (uframe >= 8)
> > return 0;
> >
> > - /*
> > -* 80% periodic == 100 usec/uframe available
> > -* convert "usecs we need" to "max already claimed"
> > -*/
> > - usecs = 100 - usecs;
> > + /* convert "usecs we need" to "max already claimed" */
> > + usecs = uframe_periodic_max - usecs;
> >
> > /* we "know" 2 and 4 uframe intervals were rejected; so
> > * for period 0, check _every_ microframe in the schedule.
> > @@ -1286,9 +1283,9 @@ itd_slot_ok (
> > {
> > uframe %= period;
> > do {
> > - /* can't commit more than 80% periodic == 100 usec */
> > + /* can't commit more than uf
Re: [RFC, PATCH] USB: EHCI: Allow users to override 80% max periodic bandwidth
On 20:02 Wed 22 Jun , Kirill Smelkov wrote:
> There are cases, when 80% max isochronous bandwidth is too limiting.
>
> For example I have two USB video capture cards which stream uncompressed
> video, and to stream full NTSC + PAL videos we'd need
>
> NTSC 640x480 YUV422 @30fps ~17.6 MB/s
> PAL 720x576 YUV422 @25fps ~19.7 MB/s
>
> isoc bandwidth.
>
> Now, due to limited alt settings in capture devices NTSC one ends up
> streaming with max_pkt_size=2688 and PAL with max_pkt_size=2892, both
> with interval=1. In terms of microframe time allocation this gives
>
> NTSC~53us
> PAL ~57us
>
> and together
>
> ~110us > 100us == 80% of 125us uframe time.
>
> So those two devices can't work together simultaneously because the'd
> over allocate isochronous bandwidth.
>
> 80% seemed a bit arbitrary to me, and I've tried to raise it to 90% and
> both devices started to work together, so I though sometimes it would be
> a good idea for users to override hardcoded default of max 80% isoc
> bandwidth.
There is nothing arbitrary about 80%. The USB 2.0 Specification constrains
periodic transfers for high-speed endpoints to 80% of the microframe. See
section 5.6.4.
-mfm
> After all, isn't it a user who should decide how to load the bus? If I
> can live with 10% or even 5% bulk bandwidth that should be ok. I'm a USB
> newcomer, but that 80% seems to be chosen pretty arbitrary to me, just
> to serve as a reasonable default.
>
> NOTE: for two streams with max_pkt_size=3072 (worst case) both time
> allocation would be 60us+60us=120us which is 96% periodic bandwidth
> leaving 4% for bulk and control. I think this should work too.
>
> Signed-off-by: Kirill Smelkov
> Cc: Alan Stern
> ---
> drivers/usb/host/ehci-hcd.c | 16
> drivers/usb/host/ehci-sched.c | 17 +++--
> 2 files changed, 23 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index c606b02..1d36e72 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c
> @@ -112,6 +112,14 @@ static unsigned int hird;
> module_param(hird, int, S_IRUGO);
> MODULE_PARM_DESC(hird, "host initiated resume duration, +1 for each 75us\n");
>
> +/*
> + * max periodic time per microframe
> + * (be careful, USB 2.0 requires it to be 100us = 80% of 125us)
> + */
> +static unsigned int uframe_periodic_max = 100;
> +module_param(uframe_periodic_max, uint, S_IRUGO);
> +MODULE_PARM_DESC(uframe_periodic_max, "maximum allowed periodic part of a
> microframe, us");
> +
> #define INTR_MASK (STS_IAA | STS_FATAL | STS_PCD | STS_ERR | STS_INT)
>
> /*-*/
> @@ -571,6 +579,14 @@ static int ehci_init(struct usb_hcd *hcd)
> hcc_params = ehci_readl(ehci, &ehci->caps->hcc_params);
>
> /*
> + * tell user, if using non-standard (80% == 100 usec/uframe) bandwidth
> + */
> + if (uframe_periodic_max != 100)
> + ehci_info(ehci, "using non-standard max periodic bandwith "
> + "(%u%% == %u usec/uframe)",
> + 100*uframe_periodic_max/125,
> uframe_periodic_max);
> +
> + /*
>* hw default: 1K periodic list heads, one per frame.
>* periodic_size can shrink by USBCMD update if hcc_params allows.
>*/
> diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
> index d12426f..fb374f2 100644
> --- a/drivers/usb/host/ehci-sched.c
> +++ b/drivers/usb/host/ehci-sched.c
> @@ -172,7 +172,7 @@ periodic_usecs (struct ehci_hcd *ehci, unsigned frame,
> unsigned uframe)
> }
> }
> #ifdef DEBUG
> - if (usecs > 100)
> + if (usecs > uframe_periodic_max)
> ehci_err (ehci, "uframe %d sched overrun: %d usecs\n",
> frame * 8 + uframe, usecs);
> #endif
> @@ -709,11 +709,8 @@ static int check_period (
> if (uframe >= 8)
> return 0;
>
> - /*
> - * 80% periodic == 100 usec/uframe available
> - * convert "usecs we need" to "max already claimed"
> - */
> - usecs = 100 - usecs;
> + /* convert "usecs we need" to "max already claimed" */
> + usecs = uframe_periodic_max - usecs;
>
> /* we "know" 2 and 4 uframe intervals were rejected; so
>* for period 0, check _every_ microframe in the schedule.
> @@ -1286,9 +1283,9 @@ itd_slot_ok (
> {
> uframe %= period;
> do {
> - /* can't commit more than 80% periodic == 100 usec */
> + /* can't commit more than uframe_periodic_max usec */
> if (periodic_usecs (ehci, uframe >> 3, uframe & 0x7)
> - > (100 - usecs))
> + > (uframe_periodic_max - usecs))
> return 0;
>
> /* we know urb->interval is 2^N uframes */
> @@ -1345,7 +1342,7 @@ sitd_sl
Re: [RFC] vtunerc - virtual DVB device driver
On Sat, Jun 18, 2011 at 8:10 PM, HoP wrote: > Hi, > > get inspired by (unfortunately close-source) solution on stb > Dreambox 800 I have made my own implementation > of virtual DVB device, based on the same device API. > > In conjunction with "Dreamtuner" userland project > [http://code.google.com/p/dreamtuner/] by Ronald Mieslinger > user can create virtual DVB device on client side and connect it > to the server. When connected, user is able to use any Linux DVB API > compatible application on client side (like VDR, MeTV, MythTV, etc) > without any need of code modification. As server can be used any > Linux DVB API compatible device. I can think of many interesting uses for a solution like this. It's great that such a driver exists and that people can use it now to create interesting do-it-yourself projects, however, I do not believe this should ever be merged into the kernel. If this solution were merged into the kernel, there would be no reason for companies like Hauppauge to ever again contribute any open source drivers. Once it's possible to deliver a closed source driver to the masses, that's what vendors will do -- there will no longer be any motivation to continue working in open source. Some may like that idea, but I feel this will destroy the foundation that we've been building for years. I repeat, the solution itself has some potential, and I see nothing wrong with this existing and being available to users in source code form, but it should never be merged into a kernel to be shipped directly to end-users. This can create a horrible president that would truly result in the prevention of open source driver contributions from silicon vendors and hardware manufacturers. Regards, Michael Krufky LinuxTV developer / Hauppauge Digital -- 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] vtunerc - virtual DVB device driver
>> This is not a political issue. It is a licensing issue. If you want to use >> someone's else code, you need to accept the licensing terms that the >> developers >> are giving you, by either paying the price for the code usage (on closed >> source >> licensing models), or by accepting the license when using an open-sourced >> code. Mauro, My comments for your review: I've spoken on this topic many times, it's bad news for the LinuxTV eco-system and it will eventually lead to binary only drivers that ultimately diminishes all of the good work that me any my fellow developers have poured into Linux over the last 5-10 years. I repeat my message from 2 years ago when the subject was raised: and this is (paraphrase) "I can say with great certainty that if we allow API's that permit closed source drivers then silicon vendors and board manufacturers will take advantage of that, they will only delivery (at best) closed source drivers". If closed source drivers is what the community wants then this is a way to achieve this. I don't want to see user-space drivers happen through LinuxDVB or V4L2 API's. I politely and respectfully nack this idea. Best, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
On Wed, 22 Jun 2011 15:39:23 +0200, Arnd Bergmann wrote: Why that? I would expect you can do the same that hugepages (used to) do and just attempt high-order allocations. If they succeed, you can add them as a CMA region and free them again, into the movable set of pages, otherwise you just fail the request from user space when the memory is already fragmented. Problem with that is that CMA needs to have whole pageblocks allocated and buddy can allocate at most half a pageblock. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michal "mina86" Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC, PATCH] USB: EHCI: Allow users to override 80% max periodic bandwidth
There are cases, when 80% max isochronous bandwidth is too limiting.
For example I have two USB video capture cards which stream uncompressed
video, and to stream full NTSC + PAL videos we'd need
NTSC 640x480 YUV422 @30fps ~17.6 MB/s
PAL 720x576 YUV422 @25fps ~19.7 MB/s
isoc bandwidth.
Now, due to limited alt settings in capture devices NTSC one ends up
streaming with max_pkt_size=2688 and PAL with max_pkt_size=2892, both
with interval=1. In terms of microframe time allocation this gives
NTSC~53us
PAL ~57us
and together
~110us > 100us == 80% of 125us uframe time.
So those two devices can't work together simultaneously because the'd
over allocate isochronous bandwidth.
80% seemed a bit arbitrary to me, and I've tried to raise it to 90% and
both devices started to work together, so I though sometimes it would be
a good idea for users to override hardcoded default of max 80% isoc
bandwidth.
After all, isn't it a user who should decide how to load the bus? If I
can live with 10% or even 5% bulk bandwidth that should be ok. I'm a USB
newcomer, but that 80% seems to be chosen pretty arbitrary to me, just
to serve as a reasonable default.
NOTE: for two streams with max_pkt_size=3072 (worst case) both time
allocation would be 60us+60us=120us which is 96% periodic bandwidth
leaving 4% for bulk and control. I think this should work too.
Signed-off-by: Kirill Smelkov
Cc: Alan Stern
---
drivers/usb/host/ehci-hcd.c | 16
drivers/usb/host/ehci-sched.c | 17 +++--
2 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index c606b02..1d36e72 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -112,6 +112,14 @@ static unsigned int hird;
module_param(hird, int, S_IRUGO);
MODULE_PARM_DESC(hird, "host initiated resume duration, +1 for each 75us\n");
+/*
+ * max periodic time per microframe
+ * (be careful, USB 2.0 requires it to be 100us = 80% of 125us)
+ */
+static unsigned int uframe_periodic_max = 100;
+module_param(uframe_periodic_max, uint, S_IRUGO);
+MODULE_PARM_DESC(uframe_periodic_max, "maximum allowed periodic part of a
microframe, us");
+
#defineINTR_MASK (STS_IAA | STS_FATAL | STS_PCD | STS_ERR | STS_INT)
/*-*/
@@ -571,6 +579,14 @@ static int ehci_init(struct usb_hcd *hcd)
hcc_params = ehci_readl(ehci, &ehci->caps->hcc_params);
/*
+* tell user, if using non-standard (80% == 100 usec/uframe) bandwidth
+*/
+ if (uframe_periodic_max != 100)
+ ehci_info(ehci, "using non-standard max periodic bandwith "
+ "(%u%% == %u usec/uframe)",
+ 100*uframe_periodic_max/125,
uframe_periodic_max);
+
+ /*
* hw default: 1K periodic list heads, one per frame.
* periodic_size can shrink by USBCMD update if hcc_params allows.
*/
diff --git a/drivers/usb/host/ehci-sched.c b/drivers/usb/host/ehci-sched.c
index d12426f..fb374f2 100644
--- a/drivers/usb/host/ehci-sched.c
+++ b/drivers/usb/host/ehci-sched.c
@@ -172,7 +172,7 @@ periodic_usecs (struct ehci_hcd *ehci, unsigned frame,
unsigned uframe)
}
}
#ifdef DEBUG
- if (usecs > 100)
+ if (usecs > uframe_periodic_max)
ehci_err (ehci, "uframe %d sched overrun: %d usecs\n",
frame * 8 + uframe, usecs);
#endif
@@ -709,11 +709,8 @@ static int check_period (
if (uframe >= 8)
return 0;
- /*
-* 80% periodic == 100 usec/uframe available
-* convert "usecs we need" to "max already claimed"
-*/
- usecs = 100 - usecs;
+ /* convert "usecs we need" to "max already claimed" */
+ usecs = uframe_periodic_max - usecs;
/* we "know" 2 and 4 uframe intervals were rejected; so
* for period 0, check _every_ microframe in the schedule.
@@ -1286,9 +1283,9 @@ itd_slot_ok (
{
uframe %= period;
do {
- /* can't commit more than 80% periodic == 100 usec */
+ /* can't commit more than uframe_periodic_max usec */
if (periodic_usecs (ehci, uframe >> 3, uframe & 0x7)
- > (100 - usecs))
+ > (uframe_periodic_max - usecs))
return 0;
/* we know urb->interval is 2^N uframes */
@@ -1345,7 +1342,7 @@ sitd_slot_ok (
#endif
/* check starts (OUT uses more than one) */
- max_used = 100 - stream->usecs;
+ max_used = uframe_periodic_max - stream->usecs;
for (tmp = stream->raw_mask & 0xff; tmp; tmp >>= 1, uf++) {
if (periodic_usecs (ehci, frame, uf) > max_used)
return 0;
@@ -1354,
Video4Linux2 developer needed for H.264/MPEG-4 capture cards
We are actively seeking a developer for our line of H.264 / MPEG-4 capture cards. The driver is mostly mature, but several tweaks and enhancements are still needed, along with continued support to our customers. This position would work closely with our team of developers working on our Linux surveillance application. You *must* have previous experience with MPEG-4 / H.264 video formats. Previous gstreamer experience would be useful. Information about the card and features of the driver can be found here: http://support.bluecherrydvr.com/entries/235174-using-the-bluecherry-hardware-compression-open-source-linux-drivers-mpeg-4-h-264 https://github.com/bluecherrydvr/solo6x10 Technically we do not have a requirement on *where* you live, as this position is a telecommuting position. We would however like for your to be available during the times that our US developers are working. Being that Video4Linux developers are pretty unique, I figured I would post on this forum first, before we started targeting various job boards. We have positions for part and full-time, so please send inquires to j...@bluecherrydvr.com Thanks! -- Curtis Hall (c...@corp.bluecherry.net) Bluecherry - www.bluecherrydvr.com (877) 418-3391 x 283 -- 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: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
On Wednesday, June 22, 2011 2:42 PM Arnd Bergmann wrote: We could also go further and add a runtime sysctl mechanism like the one for hugepages, where you can grow the pool at run time as long as there is enough free contiguous memory (e.g. from init scripts), or shrink it later if you want to allow larger nonmovable allocations. On Wed, 22 Jun 2011 15:15:35 +0200, Marek Szyprowski wrote: Sounds really good, but it might be really hard to implement, at least for CMA, because it needs to tweak parameters of memory management internal structures very early, when buddy allocator has not been activated yet. If you are able to allocate a pageblock of free memory from buddy system, you should be able to convert it to CMA memory with no problems. Also, if you want to convert CMA memory back to regular memory you should be able to do that even if some of the memory is used by CMA (it just won't be available right away but only when CMA frees it). It is important to note that, because of the use of migration type, all such conversion have to be performed on pageblock basis. I don't think this is a feature we should consider for the first patch though. We started with an overgrown idea about what CMA might do and it didn't got us far. Let's first get the basics right and then start implementing features as they become needed. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michal "mina86" Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- -- 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] vtunerc - virtual DVB device driver
On 06/22/2011 05:19 PM, Mauro Carvalho Chehab wrote: > Em 22-06-2011 11:24, Andreas Oberritter escreveu: >> On 06/22/2011 03:45 PM, Mauro Carvalho Chehab wrote: >>> Em 22-06-2011 10:13, Andreas Oberritter escreveu: On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote: > Em 22-06-2011 09:37, HoP escreveu: >> 2011/6/22 Mauro Carvalho Chehab : >>> Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab : >> [...] > If people have different understandings, then we'll likely need to > ask some > support from Open source lawyers about this subject. My very little opinion is that waving GPL is way to the hell. Nobody told me why similar technologies, in different kernel parts are acceptable, but not here. >>> >>> If you want to do the networking code at userspace, why do you need a >>> kernel >>> driver after all? The proper solution is to write an userspace library >>> for that, >>> and either enclose such library inside the applications, or use >>> LD_PRELOAD to >>> bind the library to handle the open/close/ioctl glibc calls. libv4l >>> does that. >>> As it proofed to be a good library, now almost all V4L applications are >>> using >>> it. >> >> LD_PELOAD is out of bussiness for normal work. It is technique for >> development >> and/or debugging. > > Well, libv4l successfully uses LD_PRELOAD in order to support all > applications > that weren't ported to it yet. It offers two ways: > 1) you can use it as a normal library; > 2) you can use it with LD_PRELOAD. > > >> Library would be possible, but then you kill main advantage >> - totally independece of changes inside userland DVB applications. > > Why? if you write a "dvb_open", "dvb_ioctl", ... methods with the same > syntax of > glibc open, ioctl, ..., the efforts to migrate an userspace application > to use it > is to just run: > sed s,open,dvb_open,g > sed s,ioctl,dvb_ioctl,g > > > The library and the application will be completely independent. How do you transparently set up the network parameters? By using environment variables? How do you pass existing sockets to the library? How do you intercept an open() that won't ever happen, because no virtual device to be opened exists? >>> >>> Sorry, but I failed to see at the vtunerc driver anything network-related. >> >> Of course it doesn't. You're the one who proposed to put networking into >> the driver. I however fail to see how you imagined to add remote tuner >> support to any existing application by using LD_PRELOAD. > > If you take a look at libv4l, it hooks calls to open/close/ioctl/read/write > glibc > calls. So, when an userspace application calls "open", it will run the library > code, and not glibc open function. So, it is completely transparent to the > userspace application. Again, please answer this question, how do you plan to intercept an open() call for a character device that *doesn't exist*, because it's on a remote system? That open() will never happen. LD_PRELOAD may have worked well for whatever was needed for libv4l, but that's obviously a different thing. >>> Also, the picture shows that it is just acting as a proxy to an userspace >>> code >>> that it is actually handling the network conversion. The complete solution >>> seems to have a kernel driver and an userspace client/daemon. >> >> Right. >> >>> Technically, doing such proxy in kernel is not a good idea, due to several >>> reasons: >>> >>> 1) The proxy code and the userspace network client will need to be tightly >>> coupled: >>> if you add a new feature at the proxy, the same feature will need to be >>> supported by >>> the userspace daemon; >> >> Just like anything else DVB related inside the kernel. > > Yes. > >> Adding a new feature to the proxy would mean that a new feature got >> added to the frontend API, so a new kernel would be required anyway. >> >>> 2) Data will need to be using copy_from_user/copy_to_user for every data >>> access; >> >> Also, just like anything else DVB related inside the kernel. > > Yes, but if you do it on userspace, you don't need to do double buffering. > With a proxy, the same data will need to be passed 3 times from/to > kernelspace: > 2 times at vtunerc, and 1 time to the network driver. If implemented on > userspace, > all it needed is to pass the data to the network driver, reducing latency. > > Also, newer functions can be added on userspace in order to optimize > applications > that will use it as a library, like providing functions that combine DVB and > network commands altogether. > >> No one would notice some frontend ioctl parameters being copied twice. >> We're talking about a few bytes. > > If the intention is to limit it to just frontend ioctl's, you're right: the > only di
[PATCH 3/3] noon010pc30: Clean up the s_power callback
Remove unneeded check for the platform data in s_power operation
and reorder the code to use early return path. There is no functional
changes in this patch.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/noon010pc30.c | 18 ++
1 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/noon010pc30.c
b/drivers/media/video/noon010pc30.c
index 6920cc4..99b58d0 100644
--- a/drivers/media/video/noon010pc30.c
+++ b/drivers/media/video/noon010pc30.c
@@ -588,25 +588,19 @@ static int noon010_base_config(struct v4l2_subdev *sd)
static int noon010_s_power(struct v4l2_subdev *sd, int on)
{
struct noon010_info *info = to_noon010(sd);
- const struct noon010pc30_platform_data *pdata = info->pdata;
- int ret = 0;
-
- if (WARN(pdata == NULL, "No platform data!\n"))
- return -ENOMEM;
+ int ret;
if (on) {
ret = power_enable(info);
if (ret)
return ret;
- ret = noon010_base_config(sd);
- } else {
- noon010_power_ctrl(sd, false, true);
- ret = power_disable(info);
- info->curr_win = NULL;
- info->curr_fmt = NULL;
+ return noon010_base_config(sd);
}
- return ret;
+ noon010_power_ctrl(sd, false, true);
+ info->curr_win = NULL;
+ info->curr_fmt = NULL;
+ return power_disable(info);
}
static int noon010_s_stream(struct v4l2_subdev *sd, int on)
--
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 2/3] noon010pc30: Convert to the pad level ops
Replace g/s_mbus_fmt ops with the pad level get/set_fmt operations.
Add media entity initalization and set subdev flags so the host driver
creates a v4l-subdev device node for the driver. A mutex is added for
serializing operations on subdevice node. When setting format
is attempted during streaming EBUSY error code will be returned.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/Kconfig |2 +-
drivers/media/video/noon010pc30.c | 130 +
2 files changed, 90 insertions(+), 42 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 8de3476..b505120 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -746,7 +746,7 @@ config VIDEO_VIA_CAMERA
config VIDEO_NOON010PC30
tristate "NOON010PC30 CIF camera sensor support"
- depends on I2C && VIDEO_V4L2
+ depends on I2C && VIDEO_V4L2 && EXPERIMENTAL && VIDEO_V4L2_SUBDEV_API
---help---
This driver supports NOON010PC30 CIF camera from Siliconfile
diff --git a/drivers/media/video/noon010pc30.c
b/drivers/media/video/noon010pc30.c
index 50ca097..6920cc4 100644
--- a/drivers/media/video/noon010pc30.c
+++ b/drivers/media/video/noon010pc30.c
@@ -1,7 +1,7 @@
/*
* Driver for SiliconFile NOON010PC30 CIF (1/11") Image Sensor with ISP
*
- * Copyright (C) 2010 Samsung Electronics
+ * Copyright (C) 2010 - 2011 Samsung Electronics
* Contact: Sylwester Nawrocki,
*
* Initial register configuration based on a driver authored by
@@ -130,14 +130,19 @@ static const char * const noon010_supply_name[] = {
#define NOON010_NUM_SUPPLIES ARRAY_SIZE(noon010_supply_name)
struct noon010_info {
+ /* Mutex protecting this data structure and subdev operations */
+ struct mutex lock;
struct v4l2_subdev sd;
+ struct media_pad pad;
struct v4l2_ctrl_handler hdl;
const struct noon010pc30_platform_data *pdata;
const struct noon010_format *curr_fmt;
const struct noon010_frmsize *curr_win;
+ struct v4l2_mbus_framefmt format;
unsigned int hflip:1;
unsigned int vflip:1;
unsigned int power:1;
+ unsigned int streaming:1;
u8 i2c_reg_page;
struct regulator_bulk_data supply[NOON010_NUM_SUPPLIES];
u32 gpio_nreset;
@@ -342,7 +347,7 @@ static int noon010_set_params(struct v4l2_subdev *sd)
struct noon010_info *info = to_noon010(sd);
int ret;
- if (!info->curr_win)
+ if (!info->curr_win || !info->power)
return -EINVAL;
ret = cam_i2c_write(sd, VDO_CTL_REG(0), info->curr_win->vid_ctl1);
@@ -354,7 +359,8 @@ static int noon010_set_params(struct v4l2_subdev *sd)
}
/* Find nearest matching image pixel size. */
-static int noon010_try_frame_size(struct v4l2_mbus_framefmt *mf)
+static int noon010_try_frame_size(struct v4l2_mbus_framefmt *mf,
+ const struct noon010_frmsize **size)
{
unsigned int min_err = ~0;
int i = ARRAY_SIZE(noon010_sizes);
@@ -374,6 +380,8 @@ static int noon010_try_frame_size(struct v4l2_mbus_framefmt
*mf)
if (match) {
mf->width = match->width;
mf->height = match->height;
+ if (size)
+ *size = match;
return 0;
}
return -EINVAL;
@@ -464,36 +472,45 @@ static int noon010_s_ctrl(struct v4l2_ctrl *ctrl)
}
}
-static int noon010_enum_fmt(struct v4l2_subdev *sd, unsigned int index,
- enum v4l2_mbus_pixelcode *code)
+static int noon010_enum_mbus_code(struct v4l2_subdev *sd,
+ struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_mbus_code_enum *code)
{
- if (!code || index >= ARRAY_SIZE(noon010_formats))
+ if (!code || code->index >= ARRAY_SIZE(noon010_formats))
return -EINVAL;
- *code = noon010_formats[index].code;
+ code->code = noon010_formats[code->index].code;
return 0;
}
-static int noon010_g_fmt(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt *mf)
+static int noon010_get_fmt(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_format *fmt)
{
struct noon010_info *info = to_noon010(sd);
- int ret;
+ struct v4l2_mbus_framefmt *mf;
- if (!mf)
+ if (fmt->pad != 0)
return -EINVAL;
- if (!info->curr_win || !info->curr_fmt) {
- ret = noon010_set_params(sd);
- if (ret)
- return ret;
+ if (fmt->which == V4L2_SUBDEV_FORMAT_TRY) {
+ if (fh) {
+ mf = v4l2_subdev_get_try_format(fh, 0);
+ fmt->format = *mf;
+ }
+ return 0;
}
+ /* Active format */
+ mf = &fmt->format;
+ mute
[PATCH 0/3] noon010pc30 driver conversion to the pad level operations
The following patch set converts noon010pc30 camera sensor driver to the subdev pad level operations. Additionally it cleans up some leftover after conversion to the regulator framework and marks driver as experimental as it now uses V4L2 sub-device API. Sylwester Nawrocki (3): noon010pc30: Do not ignore errors in initial controls setup noon010pc30: Convert to the pad level ops noon010pc30: Clean up the s_power callback drivers/media/video/Kconfig |2 +- drivers/media/video/noon010pc30.c | 151 - 2 files changed, 98 insertions(+), 55 deletions(-) -- 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
[PATCH 1/3] noon010pc30: Do not ignore errors in initial controls setup
Propagate return value from v4l2_ctrl_handler_setup as any errors from it are now silently ignored. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- drivers/media/video/noon010pc30.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/noon010pc30.c b/drivers/media/video/noon010pc30.c index 35f722a..50ca097 100644 --- a/drivers/media/video/noon010pc30.c +++ b/drivers/media/video/noon010pc30.c @@ -554,7 +554,8 @@ static int noon010_base_config(struct v4l2_subdev *sd) ret = noon010_power_ctrl(sd, false, false); /* sync the handler and the registers state */ - v4l2_ctrl_handler_setup(&to_noon010(sd)->hdl); + if (!ret) + ret = v4l2_ctrl_handler_setup(&info->hdl); return ret; } -- 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
Re: [RFC] vtunerc - virtual DVB device driver
Em 22-06-2011 11:24, Andreas Oberritter escreveu: > On 06/22/2011 03:45 PM, Mauro Carvalho Chehab wrote: >> Em 22-06-2011 10:13, Andreas Oberritter escreveu: >>> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote: Em 22-06-2011 09:37, HoP escreveu: > 2011/6/22 Mauro Carvalho Chehab : >> Em 21-06-2011 14:38, HoP escreveu: >>> 2011/6/21 Mauro Carvalho Chehab : > [...] If people have different understandings, then we'll likely need to ask some support from Open source lawyers about this subject. >>> >>> My very little opinion is that waving GPL is way to the hell. Nobody >>> told me >>> why similar technologies, in different kernel parts are acceptable, >>> but not here. >> >> If you want to do the networking code at userspace, why do you need a >> kernel >> driver after all? The proper solution is to write an userspace library >> for that, >> and either enclose such library inside the applications, or use >> LD_PRELOAD to >> bind the library to handle the open/close/ioctl glibc calls. libv4l does >> that. >> As it proofed to be a good library, now almost all V4L applications are >> using >> it. > > LD_PELOAD is out of bussiness for normal work. It is technique for > development > and/or debugging. Well, libv4l successfully uses LD_PRELOAD in order to support all applications that weren't ported to it yet. It offers two ways: 1) you can use it as a normal library; 2) you can use it with LD_PRELOAD. > Library would be possible, but then you kill main advantage > - totally independece of changes inside userland DVB applications. Why? if you write a "dvb_open", "dvb_ioctl", ... methods with the same syntax of glibc open, ioctl, ..., the efforts to migrate an userspace application to use it is to just run: sed s,open,dvb_open,g sed s,ioctl,dvb_ioctl,g The library and the application will be completely independent. >>> >>> How do you transparently set up the network parameters? By using >>> environment variables? How do you pass existing sockets to the library? >>> How do you intercept an open() that won't ever happen, because no >>> virtual device to be opened exists? >> >> Sorry, but I failed to see at the vtunerc driver anything network-related. > > Of course it doesn't. You're the one who proposed to put networking into > the driver. I however fail to see how you imagined to add remote tuner > support to any existing application by using LD_PRELOAD. If you take a look at libv4l, it hooks calls to open/close/ioctl/read/write glibc calls. So, when an userspace application calls "open", it will run the library code, and not glibc open function. So, it is completely transparent to the userspace application. >> Also, the picture shows that it is just acting as a proxy to an userspace >> code >> that it is actually handling the network conversion. The complete solution >> seems to have a kernel driver and an userspace client/daemon. > > Right. > >> Technically, doing such proxy in kernel is not a good idea, due to several >> reasons: >> >> 1) The proxy code and the userspace network client will need to be tightly >> coupled: >> if you add a new feature at the proxy, the same feature will need to be >> supported by >> the userspace daemon; > > Just like anything else DVB related inside the kernel. Yes. > Adding a new feature to the proxy would mean that a new feature got > added to the frontend API, so a new kernel would be required anyway. > >> 2) Data will need to be using copy_from_user/copy_to_user for every data >> access; > > Also, just like anything else DVB related inside the kernel. Yes, but if you do it on userspace, you don't need to do double buffering. With a proxy, the same data will need to be passed 3 times from/to kernelspace: 2 times at vtunerc, and 1 time to the network driver. If implemented on userspace, all it needed is to pass the data to the network driver, reducing latency. Also, newer functions can be added on userspace in order to optimize applications that will use it as a library, like providing functions that combine DVB and network commands altogether. > No one would notice some frontend ioctl parameters being copied twice. > We're talking about a few bytes. If the intention is to limit it to just frontend ioctl's, you're right: the only difference is that latency will be a little higher, probably unnoticed (yet, introduced for not a good reason). But, if the intention is to also provide remote streaming, then the volume of data copied tree times will be noticeable, especially if the stream is in HD and/or if support for full-featured DVB cards is added later. > Passing the remote TS to the kernel is completely *optional*, and only > required if you want to use the kernel's demux or the underlying > hardware's fi
RE: [PATCH 2/4 v9] v4l: add control definitions for codec devices.
Hi, Just a quick comment below. > -Original Message- > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > Sent: 22 June 2011 10:26 > > On Tuesday, June 14, 2011 18:36:54 Kamil Debski wrote: > > Add control definitions and documentation for controls > > specific to codec devices. > > > > Signed-off-by: Kamil Debski > > Signed-off-by: Kyungmin Park > > --- > > Documentation/DocBook/media/v4l/controls.xml | 958 > ++ > > include/linux/videodev2.h| 171 + > > 2 files changed, 1129 insertions(+), 0 deletions(-) > > > > diff --git a/Documentation/DocBook/media/v4l/controls.xml > b/Documentation/DocBook/media/v4l/controls.xml > > index 6880798..6b0d06a 100644 > > --- a/Documentation/DocBook/media/v4l/controls.xml > > +++ b/Documentation/DocBook/media/v4l/controls.xml > > @@ -325,6 +325,22 @@ minimum value disables backlight ... > > + > > + > > +spanname="id">V4L2_CID_MPEG_VIDEO_MB_RC_ENABLE ntry> > > + boolean > > + > > + Macroblock level rate control > enable. > > +Applicable to the MPEG4 and H264 encoders. > > If I understand this right enabling this will 'activate' the > V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_* controls. > > So this makes me wonder whether this control shouldn't perhaps be MFC51 > specific > as well. Alternatively, we can say something like: 'How macroblock rate > control is > implemented will differ per device, so devices that implement this will have > their > own set of controls.' > The V4L2_CID_MPEG_MFC51_VIDEO_H264_ADAPTIVE_RC_* controls are an added tweak by MFC. So I think it should stay as a generic control, especially that macroblock rate control is defined in the MPEG4 standard. ... Best regards, -- Kamil Debski Linux Platform Group Samsung Poland R&D 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: [RFC] vtunerc - virtual DVB device driver
On 06/22/2011 03:45 PM, Mauro Carvalho Chehab wrote: > Em 22-06-2011 10:13, Andreas Oberritter escreveu: >> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote: >>> Em 22-06-2011 09:37, HoP escreveu: 2011/6/22 Mauro Carvalho Chehab : > Em 21-06-2011 14:38, HoP escreveu: >> 2011/6/21 Mauro Carvalho Chehab : [...] >>> If people have different understandings, then we'll likely need to ask >>> some >>> support from Open source lawyers about this subject. >> >> My very little opinion is that waving GPL is way to the hell. Nobody >> told me >> why similar technologies, in different kernel parts are acceptable, >> but not here. > > If you want to do the networking code at userspace, why do you need a > kernel > driver after all? The proper solution is to write an userspace library > for that, > and either enclose such library inside the applications, or use > LD_PRELOAD to > bind the library to handle the open/close/ioctl glibc calls. libv4l does > that. > As it proofed to be a good library, now almost all V4L applications are > using > it. LD_PELOAD is out of bussiness for normal work. It is technique for development and/or debugging. >>> >>> Well, libv4l successfully uses LD_PRELOAD in order to support all >>> applications >>> that weren't ported to it yet. It offers two ways: >>> 1) you can use it as a normal library; >>> 2) you can use it with LD_PRELOAD. >>> >>> Library would be possible, but then you kill main advantage - totally independece of changes inside userland DVB applications. >>> >>> Why? if you write a "dvb_open", "dvb_ioctl", ... methods with the same >>> syntax of >>> glibc open, ioctl, ..., the efforts to migrate an userspace application to >>> use it >>> is to just run: >>> sed s,open,dvb_open,g >>> sed s,ioctl,dvb_ioctl,g >>> >>> >>> The library and the application will be completely independent. >> >> How do you transparently set up the network parameters? By using >> environment variables? How do you pass existing sockets to the library? >> How do you intercept an open() that won't ever happen, because no >> virtual device to be opened exists? > > Sorry, but I failed to see at the vtunerc driver anything network-related. Of course it doesn't. You're the one who proposed to put networking into the driver. I however fail to see how you imagined to add remote tuner support to any existing application by using LD_PRELOAD. > Also, the picture shows that it is just acting as a proxy to an userspace code > that it is actually handling the network conversion. The complete solution > seems to have a kernel driver and an userspace client/daemon. Right. > Technically, doing such proxy in kernel is not a good idea, due to several > reasons: > > 1) The proxy code and the userspace network client will need to be tightly > coupled: > if you add a new feature at the proxy, the same feature will need to be > supported by > the userspace daemon; Just like anything else DVB related inside the kernel. Adding a new feature to the proxy would mean that a new feature got added to the frontend API, so a new kernel would be required anyway. > 2) Data will need to be using copy_from_user/copy_to_user for every data > access; Also, just like anything else DVB related inside the kernel. No one would notice some frontend ioctl parameters being copied twice. We're talking about a few bytes. Passing the remote TS to the kernel is completely *optional*, and only required if you want to use the kernel's demux or the underlying hardware's filtering and decoding features. However, the TS even gets filtered before being transferred over the network. So again, even if used though being optional, this is not a big data rate. > 3) There's no good reason to write such code inside kernelspace. > > On a library based approach, what you'll have, instead is a library. The same > userspace client/daemon will be needed. However, as both can be shipped > together > (the library proxy code and the userspace client/daemon), there are several > advantages, like: > > 1) The library and the userspace client will be in sync: there's no need to > check > for version differences at the api, or providing any sort of backport support; Breaking the ABI of libraries isn't much better than breaking the ABI of kernel interfaces. A library may have many users, more than "the userspace client" you're talking about. > 2) There's no need to recompile the kernel when someone wants to use the > proxy; You could of course build it as a module, without the need to recompile the kernel. > 3) The userspace won't be bound to the Kernel release schedule: When the code > is > stable enough, both libraries and userspace can be released at the same time. For the same reason one could argue that putting device drivers into userspace would have the same benefits. Well, the original proposal
Re: [RFC] vtunerc - virtual DVB device driver
Em 22-06-2011 11:03, HoP escreveu: > 2011/6/22 Mauro Carvalho Chehab : >> Em 22-06-2011 10:13, Andreas Oberritter escreveu: >>> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote: Em 22-06-2011 09:37, HoP escreveu: > 2011/6/22 Mauro Carvalho Chehab : >> Em 21-06-2011 14:38, HoP escreveu: >>> 2011/6/21 Mauro Carvalho Chehab : Em 21-06-2011 12:09, Andreas Oberritter escreveu: > On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: >> Em 21-06-2011 11:15, Andreas Oberritter escreveu: >>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote: On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter wrote: > Mauro and Devin, I think you're missing the point. This is not > about > creating drivers in userspace. This is not about open or closed > source. > The "vtuner" interface, as implemented for the Dreambox, is used > to > access remote tuners: Put x tuners into y boxes and access them > from > another box as if they were local. It's used in conjunction with > further > software to receive the transport stream over a network > connection. > Honza's code does the same thing. I'm not missing the point at all. I realize exactly what Honza is trying to accomplish (and from a purely technical standpoint, it's not a bad approach) - but I'm talking about the effects of such a driver being introduced which changes the kernel/userland licensing boundary and has very real implications with how the in-kernel code is accessed. > You don't need it in order to create closed source drivers. You > can > already create closed kernel drivers now. Also, you can create > tuner > drivers in userspace using the i2c-dev interface. If you like to > connect > a userspace driver to a DVB API device node, you can distribute a > small > (open or closed) wrapper with it. So what are you arguing about? > Everything you're feared of can already be done since virtually > forever. I disagree. There is currently no API which allows applications to issue tuning requests into the DVB core, and have those requests proxied back out to userland where an application can then use i2c-dev to tune the actual device. Meaning if somebody wants to write a closed source userland application which controls the tuner, he/she can do that (while not conforming to the DVB API). But if if he wants to reuse the GPL licensed DVB core, he has to replace the entire DVB core. The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. I used to work for a vendor that makes tuners, and they do a bunch of Linux work. And that work has resulted in a bunch of open source drivers. I can tell you though that *every* conversation I've had regarding a new driver goes something like this: === "Devin, we need to support tuner X under Linux." "Great! I'll be happy to write a new GPL driver for the tuner/demodulator/whatever for that device" "But to save time/money, we just want to reuse the Windows driver code (or reference code from the vendor)." "Ok. Well, what is the licensing for that code? Is it GPL compatible?" "Not currently. So can we just make our driver closed source?" "Well, you can't reuse any of the existing DVB core functionality or any of the other GPL drivers (tuners, bridges, demods), so you would have rewrite all that from scratch." "Oh, that would be a ton of work. Can we maybe write some userland stuff that controls the demodulator which we can keep closed source? Since it's not in the kernel, the GPL won't apply". "Well, you can't really do that because there is no way for the DVB core to call back out to userland when the application makes the tuning request to the DVB core." "Oh, ok
RE: [PATCH 5/5] marvell-cam: implement contiguous DMA operation
Hello, On Tuesday, June 21, 2011 10:26 PM Mauro Carvalho Chehab wrote: > Em 20-06-2011 16:14, Jonathan Corbet escreveu: > > The core driver can now operate in either vmalloc or dma-contig modes; > > obviously the latter is preferable when it is supported. Default is > > currently vmalloc on all platforms; load the module with buffer_mode=1 > for contiguous DMA mode. > > Patch looks correct. > > A side note for vb2 maintainers: > > IMO, vb2 core should take the responsibility to allow to switch between DMA > scatter/gather and continuous (and, eventually, vmalloc), where the bridge > driver support more than one option. > Otherwise, we'll end by having codes similar to that on all drivers that > can be used on different architectures. Could you elaborate a bit more on this issue? Depending on driver needs, on just sets queue->mem_ops to vb2_vmalloc_memops, vb2_dma-contig_memops or vb2_dma-sg_memops. There is no dependencies between the core and memory allocators/handlers. Best regards -- Marek Szyprowski Samsung Poland R&D 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: [PATCH 1/5] marvell-cam: convert to videobuf2
On Wed, 22 Jun 2011 15:59:04 +0200 Marek Szyprowski wrote: > > This is a basic, naive conversion to the videobuf2 infrastructure, removing > > a lot of code in the process. For now, we're using vmalloc, which is > > suboptimal, but it does match what the cafe driver did before. > > Could you elaborate a bit why vmalloc is suboptimal for your case? Because it requires copying every frame in kernel space. That's not a problem with the vb2 vmalloc implementation, obviously, it's just inherent in that approach. Systems with the old Cafe controller are probably stuck with it (though CMA might just make contiguous DMA operation possible); I hope to not see it used on anything newer. (Other comments noted, thanks.) jon -- 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] vtunerc - virtual DVB device driver
2011/6/22 Mauro Carvalho Chehab : > Em 22-06-2011 10:13, Andreas Oberritter escreveu: >> On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote: >>> Em 22-06-2011 09:37, HoP escreveu: 2011/6/22 Mauro Carvalho Chehab : > Em 21-06-2011 14:38, HoP escreveu: >> 2011/6/21 Mauro Carvalho Chehab : >>> Em 21-06-2011 12:09, Andreas Oberritter escreveu: On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: > Em 21-06-2011 11:15, Andreas Oberritter escreveu: >> On 06/21/2011 03:44 PM, Devin Heitmueller wrote: >>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter >>> wrote: Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The "vtuner" interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. >>> >>> I'm not missing the point at all. I realize exactly what Honza is >>> trying to accomplish (and from a purely technical standpoint, it's >>> not >>> a bad approach) - but I'm talking about the effects of such a driver >>> being introduced which changes the kernel/userland licensing >>> boundary >>> and has very real implications with how the in-kernel code is >>> accessed. >>> You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. >>> >>> I disagree. There is currently no API which allows applications to >>> issue tuning requests into the DVB core, and have those requests >>> proxied back out to userland where an application can then use >>> i2c-dev >>> to tune the actual device. Meaning if somebody wants to write a >>> closed source userland application which controls the tuner, he/she >>> can do that (while not conforming to the DVB API). But if if he >>> wants >>> to reuse the GPL licensed DVB core, he has to replace the entire DVB >>> core. >>> >>> The introduction of this patch makes it trivial for a third party to >>> provide closed-source userland support for tuners while reusing all >>> the existing GPL driver code that makes up the framework. >>> >>> I used to work for a vendor that makes tuners, and they do a bunch >>> of >>> Linux work. And that work has resulted in a bunch of open source >>> drivers. I can tell you though that *every* conversation I've had >>> regarding a new driver goes something like this: >>> >>> === >>> "Devin, we need to support tuner X under Linux." >>> >>> "Great! I'll be happy to write a new GPL driver for the >>> tuner/demodulator/whatever for that device" >>> >>> "But to save time/money, we just want to reuse the Windows driver >>> code >>> (or reference code from the vendor)." >>> >>> "Ok. Well, what is the licensing for that code? Is it GPL >>> compatible?" >>> >>> "Not currently. So can we just make our driver closed source?" >>> >>> "Well, you can't reuse any of the existing DVB core functionality or >>> any of the other GPL drivers (tuners, bridges, demods), so you would >>> have rewrite all that from scratch." >>> >>> "Oh, that would be a ton of work. Can we maybe write some userland >>> stuff that controls the demodulator which we can keep closed source? >>> Since it's not in the kernel, the GPL won't apply". >>> >>> "Well, you can't really do that because there is no way for the DVB >>> core to call back out to userland when the application makes the >>> tuning request to the DVB core." >>> >>> "Oh, ok then. I guess we'll have to talk to the vendor and get them >>> to give us the reference driver code under the GPL." >>> === >>> >>> I can tell you without a doubt that if this driver were present in >>> the >>> kernel, tha
RE: [PATCH 1/5] marvell-cam: convert to videobuf2
Hello Jonathan,
On Monday, June 20, 2011 9:15 PM Jonathan Corbet wrote:
> This is a basic, naive conversion to the videobuf2 infrastructure, removing
> a lot of code in the process. For now, we're using vmalloc, which is
> suboptimal, but it does match what the cafe driver did before.
Could you elaborate a bit why vmalloc is suboptimal for your case?
> In the cafe
> case, it may have to stay that way just because memory is too tight to do
> direct streaming; mmp-camera will be able to do better.
>
> Signed-off-by: Jonathan Corbet
> ---
> drivers/media/video/marvell-ccic/Kconfig |2 +
> drivers/media/video/marvell-ccic/mcam-core.c | 579 --
>
> drivers/media/video/marvell-ccic/mcam-core.h | 26 +-
> 3 files changed, 196 insertions(+), 411 deletions(-)
>
> diff --git a/drivers/media/video/marvell-ccic/Kconfig
> b/drivers/media/video/marvell-ccic/Kconfig
> index b4f7260..eb535b1 100644
> --- a/drivers/media/video/marvell-ccic/Kconfig
> +++ b/drivers/media/video/marvell-ccic/Kconfig
> @@ -2,6 +2,7 @@ config VIDEO_CAFE_CCIC
> tristate "Marvell 88ALP01 (Cafe) CMOS Camera Controller support"
> depends on PCI && I2C && VIDEO_V4L2
> select VIDEO_OV7670
> + select VIDEOBUF2_VMALLOC
> ---help---
> This is a video4linux2 driver for the Marvell 88ALP01 integrated
> CMOS camera controller. This is the controller found on first-
> @@ -12,6 +13,7 @@ config VIDEO_MMP_CAMERA
> depends on ARCH_MMP && I2C && VIDEO_V4L2
> select VIDEO_OV7670
> select I2C_GPIO
> + select VIDEOBUF2_VMALLOC
> ---help---
> This is a Video4Linux2 driver for the integrated camera
> controller found on Marvell Armada 610 application
> diff --git a/drivers/media/video/marvell-ccic/mcam-core.c
> b/drivers/media/video/marvell-ccic/mcam-core.c
> index 3e6a5e8..055d843 100644
> --- a/drivers/media/video/marvell-ccic/mcam-core.c
> +++ b/drivers/media/video/marvell-ccic/mcam-core.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -149,7 +150,6 @@ static void mcam_reset_buffers(struct mcam_camera *cam)
> cam->next_buf = -1;
> for (i = 0; i < cam->nbufs; i++)
> clear_bit(i, &cam->flags);
> - cam->specframes = 0;
> }
>
> static inline int mcam_needs_config(struct mcam_camera *cam)
> @@ -165,6 +165,21 @@ static void mcam_set_config_needed(struct mcam_camera
> *cam, int needed)
> clear_bit(CF_CONFIG_NEEDED, &cam->flags);
> }
>
> +/*
> + * Our buffer type for working with videobuf2. Note that the vb2
> + * developers have decreed that struct vb2_buffer must be at the
> + * beginning of this structure.
> + */
> +struct mcam_vb_buffer {
> + struct vb2_buffer vb_buf;
> + struct list_head queue;
> +};
> +
> +static inline struct mcam_vb_buffer *vb_to_mvb(struct vb2_buffer *vb)
> +{
> + return container_of(vb, struct mcam_vb_buffer, vb_buf);
> +}
> +
>
> /*
> * Debugging and related.
> @@ -339,9 +354,7 @@ static void mcam_ctlr_stop_dma(struct mcam_camera *cam)
> spin_lock_irqsave(&cam->dev_lock, flags);
> mcam_ctlr_stop(cam);
> spin_unlock_irqrestore(&cam->dev_lock, flags);
> - mdelay(1);
> - wait_event_timeout(cam->iowait,
> - !test_bit(CF_DMA_ACTIVE, &cam->flags), HZ);
> + msleep(10);
> if (test_bit(CF_DMA_ACTIVE, &cam->flags))
> cam_err(cam, "Timeout waiting for DMA to end\n");
> /* This would be bad news - what now? */
> @@ -524,44 +537,11 @@ static void mcam_free_dma_bufs(struct mcam_camera
> *cam)
>
>
>
> -
> -
> /* ---
> */
> /*
> * Here starts the V4L2 interface code.
> */
>
> -/*
> - * Read an image from the device.
> - */
> -static ssize_t mcam_deliver_buffer(struct mcam_camera *cam,
> - char __user *buffer, size_t len, loff_t *pos)
> -{
> - int bufno;
> - unsigned long flags;
> -
> - spin_lock_irqsave(&cam->dev_lock, flags);
> - if (cam->next_buf < 0) {
> - cam_err(cam, "deliver_buffer: No next buffer\n");
> - spin_unlock_irqrestore(&cam->dev_lock, flags);
> - return -EIO;
> - }
> - bufno = cam->next_buf;
> - clear_bit(bufno, &cam->flags);
> - if (++(cam->next_buf) >= cam->nbufs)
> - cam->next_buf = 0;
> - if (!test_bit(cam->next_buf, &cam->flags))
> - cam->next_buf = -1;
> - cam->specframes = 0;
> - spin_unlock_irqrestore(&cam->dev_lock, flags);
> -
> - if (len > cam->pix_format.sizeimage)
> - len = cam->pix_format.sizeimage;
> - if (copy_to_user(buffer, cam->dma_bufs[bufno], len))
> - return -EFAULT;
> - (*pos) += len;
> - return len;
> -}
>
> /*
> * Get everything ready, and start grabbing frames.
> @@ -598,75 +578,138 @@ static int mcam_read_setup(struct mcam_camera *cam,
> e
Re: [RFC] vtunerc - virtual DVB device driver
Em 22-06-2011 10:13, Andreas Oberritter escreveu: > On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote: >> Em 22-06-2011 09:37, HoP escreveu: >>> 2011/6/22 Mauro Carvalho Chehab : Em 21-06-2011 14:38, HoP escreveu: > 2011/6/21 Mauro Carvalho Chehab : >> Em 21-06-2011 12:09, Andreas Oberritter escreveu: >>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 11:15, Andreas Oberritter escreveu: > On 06/21/2011 03:44 PM, Devin Heitmueller wrote: >> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter >> wrote: >>> Mauro and Devin, I think you're missing the point. This is not about >>> creating drivers in userspace. This is not about open or closed >>> source. >>> The "vtuner" interface, as implemented for the Dreambox, is used to >>> access remote tuners: Put x tuners into y boxes and access them from >>> another box as if they were local. It's used in conjunction with >>> further >>> software to receive the transport stream over a network connection. >>> Honza's code does the same thing. >> >> I'm not missing the point at all. I realize exactly what Honza is >> trying to accomplish (and from a purely technical standpoint, it's >> not >> a bad approach) - but I'm talking about the effects of such a driver >> being introduced which changes the kernel/userland licensing boundary >> and has very real implications with how the in-kernel code is >> accessed. >> >>> You don't need it in order to create closed source drivers. You can >>> already create closed kernel drivers now. Also, you can create tuner >>> drivers in userspace using the i2c-dev interface. If you like to >>> connect >>> a userspace driver to a DVB API device node, you can distribute a >>> small >>> (open or closed) wrapper with it. So what are you arguing about? >>> Everything you're feared of can already be done since virtually >>> forever. >> >> I disagree. There is currently no API which allows applications to >> issue tuning requests into the DVB core, and have those requests >> proxied back out to userland where an application can then use >> i2c-dev >> to tune the actual device. Meaning if somebody wants to write a >> closed source userland application which controls the tuner, he/she >> can do that (while not conforming to the DVB API). But if if he >> wants >> to reuse the GPL licensed DVB core, he has to replace the entire DVB >> core. >> >> The introduction of this patch makes it trivial for a third party to >> provide closed-source userland support for tuners while reusing all >> the existing GPL driver code that makes up the framework. >> >> I used to work for a vendor that makes tuners, and they do a bunch of >> Linux work. And that work has resulted in a bunch of open source >> drivers. I can tell you though that *every* conversation I've had >> regarding a new driver goes something like this: >> >> === >> "Devin, we need to support tuner X under Linux." >> >> "Great! I'll be happy to write a new GPL driver for the >> tuner/demodulator/whatever for that device" >> >> "But to save time/money, we just want to reuse the Windows driver >> code >> (or reference code from the vendor)." >> >> "Ok. Well, what is the licensing for that code? Is it GPL >> compatible?" >> >> "Not currently. So can we just make our driver closed source?" >> >> "Well, you can't reuse any of the existing DVB core functionality or >> any of the other GPL drivers (tuners, bridges, demods), so you would >> have rewrite all that from scratch." >> >> "Oh, that would be a ton of work. Can we maybe write some userland >> stuff that controls the demodulator which we can keep closed source? >> Since it's not in the kernel, the GPL won't apply". >> >> "Well, you can't really do that because there is no way for the DVB >> core to call back out to userland when the application makes the >> tuning request to the DVB core." >> >> "Oh, ok then. I guess we'll have to talk to the vendor and get them >> to give us the reference driver code under the GPL." >> === >> >> I can tell you without a doubt that if this driver were present in >> the >> kernel, that going forward that vendor would have *zero* interest in >> doing any GPL driver work. Why would they? Why give away the code >> which could potentially help their competitors if
Re: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
On Wednesday 22 June 2011, Marek Szyprowski wrote: > Sounds really good, but it might be really hard to implemnt, at least for > CMA, because it needs to tweak parameters of memory management internal > structures very early, when buddy allocator has not been activated yet. Why that? I would expect you can do the same that hugepages (used to) do and just attempt high-order allocations. If they succeed, you can add them as a CMA region and free them again, into the movable set of pages, otherwise you just fail the request from user space when the memory is already fragmented. > > These essentially fight over the same memory (though things are slightly > > different with dynamic hugepages), and they all face the same basic problem > > of getting as much for themselves without starving the other three. > > I'm not sure we can solve all such issues in the first version. Maybe we > should > first have each of the above fully working in mainline separately and then > start the integration works. Yes, makes sense. We just need to be careful not to introduce user-visible interfaces that we cannot change any more in the process. Arnd -- 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] vtunerc - virtual DVB device driver
2011/6/22 Mauro Carvalho Chehab : > Em 22-06-2011 09:30, Andreas Oberritter escreveu: >> On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote: >>> Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab : > Em 21-06-2011 12:09, Andreas Oberritter escreveu: >> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: >>> Em 21-06-2011 11:15, Andreas Oberritter escreveu: On 06/21/2011 03:44 PM, Devin Heitmueller wrote: > On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter > wrote: >> Mauro and Devin, I think you're missing the point. This is not about >> creating drivers in userspace. This is not about open or closed >> source. >> The "vtuner" interface, as implemented for the Dreambox, is used to >> access remote tuners: Put x tuners into y boxes and access them from >> another box as if they were local. It's used in conjunction with >> further >> software to receive the transport stream over a network connection. >> Honza's code does the same thing. > > I'm not missing the point at all. I realize exactly what Honza is > trying to accomplish (and from a purely technical standpoint, it's not > a bad approach) - but I'm talking about the effects of such a driver > being introduced which changes the kernel/userland licensing boundary > and has very real implications with how the in-kernel code is > accessed. > >> You don't need it in order to create closed source drivers. You can >> already create closed kernel drivers now. Also, you can create tuner >> drivers in userspace using the i2c-dev interface. If you like to >> connect >> a userspace driver to a DVB API device node, you can distribute a >> small >> (open or closed) wrapper with it. So what are you arguing about? >> Everything you're feared of can already be done since virtually >> forever. > > I disagree. There is currently no API which allows applications to > issue tuning requests into the DVB core, and have those requests > proxied back out to userland where an application can then use i2c-dev > to tune the actual device. Meaning if somebody wants to write a > closed source userland application which controls the tuner, he/she > can do that (while not conforming to the DVB API). But if if he wants > to reuse the GPL licensed DVB core, he has to replace the entire DVB > core. > > The introduction of this patch makes it trivial for a third party to > provide closed-source userland support for tuners while reusing all > the existing GPL driver code that makes up the framework. > > I used to work for a vendor that makes tuners, and they do a bunch of > Linux work. And that work has resulted in a bunch of open source > drivers. I can tell you though that *every* conversation I've had > regarding a new driver goes something like this: > > === > "Devin, we need to support tuner X under Linux." > > "Great! I'll be happy to write a new GPL driver for the > tuner/demodulator/whatever for that device" > > "But to save time/money, we just want to reuse the Windows driver code > (or reference code from the vendor)." > > "Ok. Well, what is the licensing for that code? Is it GPL > compatible?" > > "Not currently. So can we just make our driver closed source?" > > "Well, you can't reuse any of the existing DVB core functionality or > any of the other GPL drivers (tuners, bridges, demods), so you would > have rewrite all that from scratch." > > "Oh, that would be a ton of work. Can we maybe write some userland > stuff that controls the demodulator which we can keep closed source? > Since it's not in the kernel, the GPL won't apply". > > "Well, you can't really do that because there is no way for the DVB > core to call back out to userland when the application makes the > tuning request to the DVB core." > > "Oh, ok then. I guess we'll have to talk to the vendor and get them > to give us the reference driver code under the GPL." > === > > I can tell you without a doubt that if this driver were present in the > kernel, that going forward that vendor would have *zero* interest in > doing any GPL driver work. Why would they? Why give away the code > which could potentially help their competitors if they can keep it > safe and protected while still being able to reuse everybody else's > contributions? > > Companies don't contribute GPL code out of "g
RE: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
Hello, On Wednesday, June 22, 2011 2:42 PM Arnd Bergmann wrote: > On Wednesday 22 June 2011, Hans Verkuil wrote: > > > How about a Kconfig option that defines the percentage of memory > > > to set aside for contiguous allocations? > > > > I would actually like to see a cma_size kernel option of some sort. This > would > > be for the global CMA pool only as I don't think we should try to do > anything > > more complicated here. > > A command line is probably good to override the compile-time default, yes. > > We could also go further and add a runtime sysctl mechanism like the one > for hugepages, where you can grow the pool at run time as long as there is > enough free contiguous memory (e.g. from init scripts), or shrink it later > if you want to allow larger nonmovable allocations. Sounds really good, but it might be really hard to implemnt, at least for CMA, because it needs to tweak parameters of memory management internal structures very early, when buddy allocator has not been activated yet. > My feeling is that we need to find a way to integrate the global settings > for four kinds of allocations: > > * nonmovable kernel pages > * hugetlb pages > * CMA > * memory hotplug > > These essentially fight over the same memory (though things are slightly > different with dynamic hugepages), and they all face the same basic problem > of getting as much for themselves without starving the other three. I'm not sure we can solve all such issues in the first version. Maybe we should first have each of the above fully working in mainline separately and then start the integration works. Best regards -- Marek Szyprowski Samsung Poland R&D 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: [RFC] vtunerc - virtual DVB device driver
On 06/22/2011 03:03 PM, Mauro Carvalho Chehab wrote: > Em 22-06-2011 09:37, HoP escreveu: >> 2011/6/22 Mauro Carvalho Chehab : >>> Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab : > Em 21-06-2011 12:09, Andreas Oberritter escreveu: >> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: >>> Em 21-06-2011 11:15, Andreas Oberritter escreveu: On 06/21/2011 03:44 PM, Devin Heitmueller wrote: > On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter > wrote: >> Mauro and Devin, I think you're missing the point. This is not about >> creating drivers in userspace. This is not about open or closed >> source. >> The "vtuner" interface, as implemented for the Dreambox, is used to >> access remote tuners: Put x tuners into y boxes and access them from >> another box as if they were local. It's used in conjunction with >> further >> software to receive the transport stream over a network connection. >> Honza's code does the same thing. > > I'm not missing the point at all. I realize exactly what Honza is > trying to accomplish (and from a purely technical standpoint, it's not > a bad approach) - but I'm talking about the effects of such a driver > being introduced which changes the kernel/userland licensing boundary > and has very real implications with how the in-kernel code is > accessed. > >> You don't need it in order to create closed source drivers. You can >> already create closed kernel drivers now. Also, you can create tuner >> drivers in userspace using the i2c-dev interface. If you like to >> connect >> a userspace driver to a DVB API device node, you can distribute a >> small >> (open or closed) wrapper with it. So what are you arguing about? >> Everything you're feared of can already be done since virtually >> forever. > > I disagree. There is currently no API which allows applications to > issue tuning requests into the DVB core, and have those requests > proxied back out to userland where an application can then use i2c-dev > to tune the actual device. Meaning if somebody wants to write a > closed source userland application which controls the tuner, he/she > can do that (while not conforming to the DVB API). But if if he wants > to reuse the GPL licensed DVB core, he has to replace the entire DVB > core. > > The introduction of this patch makes it trivial for a third party to > provide closed-source userland support for tuners while reusing all > the existing GPL driver code that makes up the framework. > > I used to work for a vendor that makes tuners, and they do a bunch of > Linux work. And that work has resulted in a bunch of open source > drivers. I can tell you though that *every* conversation I've had > regarding a new driver goes something like this: > > === > "Devin, we need to support tuner X under Linux." > > "Great! I'll be happy to write a new GPL driver for the > tuner/demodulator/whatever for that device" > > "But to save time/money, we just want to reuse the Windows driver code > (or reference code from the vendor)." > > "Ok. Well, what is the licensing for that code? Is it GPL > compatible?" > > "Not currently. So can we just make our driver closed source?" > > "Well, you can't reuse any of the existing DVB core functionality or > any of the other GPL drivers (tuners, bridges, demods), so you would > have rewrite all that from scratch." > > "Oh, that would be a ton of work. Can we maybe write some userland > stuff that controls the demodulator which we can keep closed source? > Since it's not in the kernel, the GPL won't apply". > > "Well, you can't really do that because there is no way for the DVB > core to call back out to userland when the application makes the > tuning request to the DVB core." > > "Oh, ok then. I guess we'll have to talk to the vendor and get them > to give us the reference driver code under the GPL." > === > > I can tell you without a doubt that if this driver were present in the > kernel, that going forward that vendor would have *zero* interest in > doing any GPL driver work. Why would they? Why give away the code > which could potentially help their competitors if they can keep it > safe and protected while still being able to reuse everybody else's > contributions? > > Companies don't contribute GPL code out of "good will". The
Re: [RFC] vtunerc - virtual DVB device driver
On 06/22/2011 02:55 PM, Mauro Carvalho Chehab wrote: > Em 22-06-2011 09:30, Andreas Oberritter escreveu: >> On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote: >>> Em 21-06-2011 14:38, HoP escreveu: 2011/6/21 Mauro Carvalho Chehab : > Em 21-06-2011 12:09, Andreas Oberritter escreveu: >> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: >>> Em 21-06-2011 11:15, Andreas Oberritter escreveu: On 06/21/2011 03:44 PM, Devin Heitmueller wrote: > On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter > wrote: >> Mauro and Devin, I think you're missing the point. This is not about >> creating drivers in userspace. This is not about open or closed >> source. >> The "vtuner" interface, as implemented for the Dreambox, is used to >> access remote tuners: Put x tuners into y boxes and access them from >> another box as if they were local. It's used in conjunction with >> further >> software to receive the transport stream over a network connection. >> Honza's code does the same thing. > > I'm not missing the point at all. I realize exactly what Honza is > trying to accomplish (and from a purely technical standpoint, it's not > a bad approach) - but I'm talking about the effects of such a driver > being introduced which changes the kernel/userland licensing boundary > and has very real implications with how the in-kernel code is > accessed. > >> You don't need it in order to create closed source drivers. You can >> already create closed kernel drivers now. Also, you can create tuner >> drivers in userspace using the i2c-dev interface. If you like to >> connect >> a userspace driver to a DVB API device node, you can distribute a >> small >> (open or closed) wrapper with it. So what are you arguing about? >> Everything you're feared of can already be done since virtually >> forever. > > I disagree. There is currently no API which allows applications to > issue tuning requests into the DVB core, and have those requests > proxied back out to userland where an application can then use i2c-dev > to tune the actual device. Meaning if somebody wants to write a > closed source userland application which controls the tuner, he/she > can do that (while not conforming to the DVB API). But if if he wants > to reuse the GPL licensed DVB core, he has to replace the entire DVB > core. > > The introduction of this patch makes it trivial for a third party to > provide closed-source userland support for tuners while reusing all > the existing GPL driver code that makes up the framework. > > I used to work for a vendor that makes tuners, and they do a bunch of > Linux work. And that work has resulted in a bunch of open source > drivers. I can tell you though that *every* conversation I've had > regarding a new driver goes something like this: > > === > "Devin, we need to support tuner X under Linux." > > "Great! I'll be happy to write a new GPL driver for the > tuner/demodulator/whatever for that device" > > "But to save time/money, we just want to reuse the Windows driver code > (or reference code from the vendor)." > > "Ok. Well, what is the licensing for that code? Is it GPL > compatible?" > > "Not currently. So can we just make our driver closed source?" > > "Well, you can't reuse any of the existing DVB core functionality or > any of the other GPL drivers (tuners, bridges, demods), so you would > have rewrite all that from scratch." > > "Oh, that would be a ton of work. Can we maybe write some userland > stuff that controls the demodulator which we can keep closed source? > Since it's not in the kernel, the GPL won't apply". > > "Well, you can't really do that because there is no way for the DVB > core to call back out to userland when the application makes the > tuning request to the DVB core." > > "Oh, ok then. I guess we'll have to talk to the vendor and get them > to give us the reference driver code under the GPL." > === > > I can tell you without a doubt that if this driver were present in the > kernel, that going forward that vendor would have *zero* interest in > doing any GPL driver work. Why would they? Why give away the code > which could potentially help their competitors if they can keep it > safe and protected while still being able to reuse everybody else's > contributions? > > Companies don't contribute
Re: [RFC] vtunerc - virtual DVB device driver
Em 22-06-2011 09:37, HoP escreveu: > 2011/6/22 Mauro Carvalho Chehab : >> Em 21-06-2011 14:38, HoP escreveu: >>> 2011/6/21 Mauro Carvalho Chehab : Em 21-06-2011 12:09, Andreas Oberritter escreveu: > On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: >> Em 21-06-2011 11:15, Andreas Oberritter escreveu: >>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote: On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter wrote: > Mauro and Devin, I think you're missing the point. This is not about > creating drivers in userspace. This is not about open or closed > source. > The "vtuner" interface, as implemented for the Dreambox, is used to > access remote tuners: Put x tuners into y boxes and access them from > another box as if they were local. It's used in conjunction with > further > software to receive the transport stream over a network connection. > Honza's code does the same thing. I'm not missing the point at all. I realize exactly what Honza is trying to accomplish (and from a purely technical standpoint, it's not a bad approach) - but I'm talking about the effects of such a driver being introduced which changes the kernel/userland licensing boundary and has very real implications with how the in-kernel code is accessed. > You don't need it in order to create closed source drivers. You can > already create closed kernel drivers now. Also, you can create tuner > drivers in userspace using the i2c-dev interface. If you like to > connect > a userspace driver to a DVB API device node, you can distribute a > small > (open or closed) wrapper with it. So what are you arguing about? > Everything you're feared of can already be done since virtually > forever. I disagree. There is currently no API which allows applications to issue tuning requests into the DVB core, and have those requests proxied back out to userland where an application can then use i2c-dev to tune the actual device. Meaning if somebody wants to write a closed source userland application which controls the tuner, he/she can do that (while not conforming to the DVB API). But if if he wants to reuse the GPL licensed DVB core, he has to replace the entire DVB core. The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. I used to work for a vendor that makes tuners, and they do a bunch of Linux work. And that work has resulted in a bunch of open source drivers. I can tell you though that *every* conversation I've had regarding a new driver goes something like this: === "Devin, we need to support tuner X under Linux." "Great! I'll be happy to write a new GPL driver for the tuner/demodulator/whatever for that device" "But to save time/money, we just want to reuse the Windows driver code (or reference code from the vendor)." "Ok. Well, what is the licensing for that code? Is it GPL compatible?" "Not currently. So can we just make our driver closed source?" "Well, you can't reuse any of the existing DVB core functionality or any of the other GPL drivers (tuners, bridges, demods), so you would have rewrite all that from scratch." "Oh, that would be a ton of work. Can we maybe write some userland stuff that controls the demodulator which we can keep closed source? Since it's not in the kernel, the GPL won't apply". "Well, you can't really do that because there is no way for the DVB core to call back out to userland when the application makes the tuning request to the DVB core." "Oh, ok then. I guess we'll have to talk to the vendor and get them to give us the reference driver code under the GPL." === I can tell you without a doubt that if this driver were present in the kernel, that going forward that vendor would have *zero* interest in doing any GPL driver work. Why would they? Why give away the code which could potentially help their competitors if they can keep it safe and protected while still being able to reuse everybody else's contributions? Companies don't contribute GPL code out of "good will". They do it because they are compelled to by licenses or because there is no economically viable alternative. Mauro
Re: [RFC] vtunerc - virtual DVB device driver
Em 22-06-2011 09:30, Andreas Oberritter escreveu: > On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote: >> Em 21-06-2011 14:38, HoP escreveu: >>> 2011/6/21 Mauro Carvalho Chehab : Em 21-06-2011 12:09, Andreas Oberritter escreveu: > On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: >> Em 21-06-2011 11:15, Andreas Oberritter escreveu: >>> On 06/21/2011 03:44 PM, Devin Heitmueller wrote: On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter wrote: > Mauro and Devin, I think you're missing the point. This is not about > creating drivers in userspace. This is not about open or closed > source. > The "vtuner" interface, as implemented for the Dreambox, is used to > access remote tuners: Put x tuners into y boxes and access them from > another box as if they were local. It's used in conjunction with > further > software to receive the transport stream over a network connection. > Honza's code does the same thing. I'm not missing the point at all. I realize exactly what Honza is trying to accomplish (and from a purely technical standpoint, it's not a bad approach) - but I'm talking about the effects of such a driver being introduced which changes the kernel/userland licensing boundary and has very real implications with how the in-kernel code is accessed. > You don't need it in order to create closed source drivers. You can > already create closed kernel drivers now. Also, you can create tuner > drivers in userspace using the i2c-dev interface. If you like to > connect > a userspace driver to a DVB API device node, you can distribute a > small > (open or closed) wrapper with it. So what are you arguing about? > Everything you're feared of can already be done since virtually > forever. I disagree. There is currently no API which allows applications to issue tuning requests into the DVB core, and have those requests proxied back out to userland where an application can then use i2c-dev to tune the actual device. Meaning if somebody wants to write a closed source userland application which controls the tuner, he/she can do that (while not conforming to the DVB API). But if if he wants to reuse the GPL licensed DVB core, he has to replace the entire DVB core. The introduction of this patch makes it trivial for a third party to provide closed-source userland support for tuners while reusing all the existing GPL driver code that makes up the framework. I used to work for a vendor that makes tuners, and they do a bunch of Linux work. And that work has resulted in a bunch of open source drivers. I can tell you though that *every* conversation I've had regarding a new driver goes something like this: === "Devin, we need to support tuner X under Linux." "Great! I'll be happy to write a new GPL driver for the tuner/demodulator/whatever for that device" "But to save time/money, we just want to reuse the Windows driver code (or reference code from the vendor)." "Ok. Well, what is the licensing for that code? Is it GPL compatible?" "Not currently. So can we just make our driver closed source?" "Well, you can't reuse any of the existing DVB core functionality or any of the other GPL drivers (tuners, bridges, demods), so you would have rewrite all that from scratch." "Oh, that would be a ton of work. Can we maybe write some userland stuff that controls the demodulator which we can keep closed source? Since it's not in the kernel, the GPL won't apply". "Well, you can't really do that because there is no way for the DVB core to call back out to userland when the application makes the tuning request to the DVB core." "Oh, ok then. I guess we'll have to talk to the vendor and get them to give us the reference driver code under the GPL." === I can tell you without a doubt that if this driver were present in the kernel, that going forward that vendor would have *zero* interest in doing any GPL driver work. Why would they? Why give away the code which could potentially help their competitors if they can keep it safe and protected while still being able to reuse everybody else's contributions? Companies don't contribute GPL code out of "good will". They do it because they are compelled to by licenses or because there is no economically viable al
Re: vb2: holding buffers until after start_streaming()
On Wednesday, June 22, 2011 14:38:55 Jonathan Corbet wrote: > On Wed, 22 Jun 2011 11:43:14 +0200 > Marek Szyprowski wrote: > > > > Do you really need a flag? If a driver absolutely cannot stream without > > > buffers queued (and can't be fixed to start streaming for real when the > > > buffers show up) it should just return -EINVAL from start_streaming() or > > > some such. The driver must be aware of its limitations regardless, but > > > there's no need to push that awareness into vb2 as well. > > > > The main idea behind vb2 was to move all common error handling code to > > the framework and provide simple functions that can be used by the driver > > directly without the need for additional checks. > > For stuff that's truly common, that makes sense. As soon as you start > adding driver-specific flags, things aren't quite so common anymore. In > this case, the driver writer can just as easily check the state of the > buffer queue at streamon time, so I don't see what would be gained. > Whatever, doesn't matter that much. > > > > (FWIW, I wouldn't switch the order of operations in vb2_streamon(); I > > > would just take out the "if (q->streaming)" test at the end of vb2_qbuf() > > > and pass the buffers through directly. But maybe that's just me.) > > > > I want to keep the current version of vb2_qbuf() and change the order of > > operations in streamon(). > > I'm curious as to why? As far as I can tell, there's no reason not to > pass the buffers straight through when you get them? I'm curious as well. I don't see the problem with that. > > The only problem that still need to be resolved is what should happen with > > the buffers if start_streaming() fails. The ownership for these buffers have > > been already given to the driver, but they might have been in dirty state. > > Probably vb2 should assume that the buffers are lost and reinitialize them. > > You already grab them back at stop_streaming() time, right? I'd think > that a failed start_streaming() should leave things in exactly the same > state as a start/stop_streaming() sequence. I think so too. vb2 can just call queue_cancel, I think. Regards, Hans > > Thanks, > > jon > -- > 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
Re: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
On Wednesday 22 June 2011, Hans Verkuil wrote: > > How about a Kconfig option that defines the percentage of memory > > to set aside for contiguous allocations? > > I would actually like to see a cma_size kernel option of some sort. This would > be for the global CMA pool only as I don't think we should try to do anything > more complicated here. A command line is probably good to override the compile-time default, yes. We could also go further and add a runtime sysctl mechanism like the one for hugepages, where you can grow the pool at run time as long as there is enough free contiguous memory (e.g. from init scripts), or shrink it later if you want to allow larger nonmovable allocations. My feeling is that we need to find a way to integrate the global settings for four kinds of allocations: * nonmovable kernel pages * hugetlb pages * CMA * memory hotplug These essentially fight over the same memory (though things are slightly different with dynamic hugepages), and they all face the same basic problem of getting as much for themselves without starving the other three. Arnd -- 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: vb2: holding buffers until after start_streaming()
On Wed, 22 Jun 2011 11:43:14 +0200 Marek Szyprowski wrote: > > Do you really need a flag? If a driver absolutely cannot stream without > > buffers queued (and can't be fixed to start streaming for real when the > > buffers show up) it should just return -EINVAL from start_streaming() or > > some such. The driver must be aware of its limitations regardless, but > > there's no need to push that awareness into vb2 as well. > > The main idea behind vb2 was to move all common error handling code to > the framework and provide simple functions that can be used by the driver > directly without the need for additional checks. For stuff that's truly common, that makes sense. As soon as you start adding driver-specific flags, things aren't quite so common anymore. In this case, the driver writer can just as easily check the state of the buffer queue at streamon time, so I don't see what would be gained. Whatever, doesn't matter that much. > > (FWIW, I wouldn't switch the order of operations in vb2_streamon(); I > > would just take out the "if (q->streaming)" test at the end of vb2_qbuf() > > and pass the buffers through directly. But maybe that's just me.) > > I want to keep the current version of vb2_qbuf() and change the order of > operations in streamon(). I'm curious as to why? As far as I can tell, there's no reason not to pass the buffers straight through when you get them? > The only problem that still need to be resolved is what should happen with > the buffers if start_streaming() fails. The ownership for these buffers have > been already given to the driver, but they might have been in dirty state. > Probably vb2 should assume that the buffers are lost and reinitialize them. You already grab them back at stop_streaming() time, right? I'd think that a failed start_streaming() should leave things in exactly the same state as a start/stop_streaming() sequence. Thanks, jon -- 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] vtunerc - virtual DVB device driver
2011/6/22 Mauro Carvalho Chehab : > Em 21-06-2011 14:38, HoP escreveu: >> 2011/6/21 Mauro Carvalho Chehab : >>> Em 21-06-2011 12:09, Andreas Oberritter escreveu: On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: > Em 21-06-2011 11:15, Andreas Oberritter escreveu: >> On 06/21/2011 03:44 PM, Devin Heitmueller wrote: >>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter >>> wrote: Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The "vtuner" interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. >>> >>> I'm not missing the point at all. I realize exactly what Honza is >>> trying to accomplish (and from a purely technical standpoint, it's not >>> a bad approach) - but I'm talking about the effects of such a driver >>> being introduced which changes the kernel/userland licensing boundary >>> and has very real implications with how the in-kernel code is >>> accessed. >>> You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. >>> >>> I disagree. There is currently no API which allows applications to >>> issue tuning requests into the DVB core, and have those requests >>> proxied back out to userland where an application can then use i2c-dev >>> to tune the actual device. Meaning if somebody wants to write a >>> closed source userland application which controls the tuner, he/she >>> can do that (while not conforming to the DVB API). But if if he wants >>> to reuse the GPL licensed DVB core, he has to replace the entire DVB >>> core. >>> >>> The introduction of this patch makes it trivial for a third party to >>> provide closed-source userland support for tuners while reusing all >>> the existing GPL driver code that makes up the framework. >>> >>> I used to work for a vendor that makes tuners, and they do a bunch of >>> Linux work. And that work has resulted in a bunch of open source >>> drivers. I can tell you though that *every* conversation I've had >>> regarding a new driver goes something like this: >>> >>> === >>> "Devin, we need to support tuner X under Linux." >>> >>> "Great! I'll be happy to write a new GPL driver for the >>> tuner/demodulator/whatever for that device" >>> >>> "But to save time/money, we just want to reuse the Windows driver code >>> (or reference code from the vendor)." >>> >>> "Ok. Well, what is the licensing for that code? Is it GPL compatible?" >>> >>> "Not currently. So can we just make our driver closed source?" >>> >>> "Well, you can't reuse any of the existing DVB core functionality or >>> any of the other GPL drivers (tuners, bridges, demods), so you would >>> have rewrite all that from scratch." >>> >>> "Oh, that would be a ton of work. Can we maybe write some userland >>> stuff that controls the demodulator which we can keep closed source? >>> Since it's not in the kernel, the GPL won't apply". >>> >>> "Well, you can't really do that because there is no way for the DVB >>> core to call back out to userland when the application makes the >>> tuning request to the DVB core." >>> >>> "Oh, ok then. I guess we'll have to talk to the vendor and get them >>> to give us the reference driver code under the GPL." >>> === >>> >>> I can tell you without a doubt that if this driver were present in the >>> kernel, that going forward that vendor would have *zero* interest in >>> doing any GPL driver work. Why would they? Why give away the code >>> which could potentially help their competitors if they can keep it >>> safe and protected while still being able to reuse everybody else's >>> contributions? >>> >>> Companies don't contribute GPL code out of "good will". They do it >>> because they are compelled to by licenses or because there is no >>> economically viable alternative. >>> >>> Mauro, ultimately it is your decision as the maintainer which drivers >>> get accepted in to the kernel. I can tell you though that this will >>> be a very b
Re: [RFC] vtunerc - virtual DVB device driver
On 06/22/2011 02:17 PM, Mauro Carvalho Chehab wrote: > Em 21-06-2011 14:38, HoP escreveu: >> 2011/6/21 Mauro Carvalho Chehab : >>> Em 21-06-2011 12:09, Andreas Oberritter escreveu: On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: > Em 21-06-2011 11:15, Andreas Oberritter escreveu: >> On 06/21/2011 03:44 PM, Devin Heitmueller wrote: >>> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter >>> wrote: Mauro and Devin, I think you're missing the point. This is not about creating drivers in userspace. This is not about open or closed source. The "vtuner" interface, as implemented for the Dreambox, is used to access remote tuners: Put x tuners into y boxes and access them from another box as if they were local. It's used in conjunction with further software to receive the transport stream over a network connection. Honza's code does the same thing. >>> >>> I'm not missing the point at all. I realize exactly what Honza is >>> trying to accomplish (and from a purely technical standpoint, it's not >>> a bad approach) - but I'm talking about the effects of such a driver >>> being introduced which changes the kernel/userland licensing boundary >>> and has very real implications with how the in-kernel code is >>> accessed. >>> You don't need it in order to create closed source drivers. You can already create closed kernel drivers now. Also, you can create tuner drivers in userspace using the i2c-dev interface. If you like to connect a userspace driver to a DVB API device node, you can distribute a small (open or closed) wrapper with it. So what are you arguing about? Everything you're feared of can already be done since virtually forever. >>> >>> I disagree. There is currently no API which allows applications to >>> issue tuning requests into the DVB core, and have those requests >>> proxied back out to userland where an application can then use i2c-dev >>> to tune the actual device. Meaning if somebody wants to write a >>> closed source userland application which controls the tuner, he/she >>> can do that (while not conforming to the DVB API). But if if he wants >>> to reuse the GPL licensed DVB core, he has to replace the entire DVB >>> core. >>> >>> The introduction of this patch makes it trivial for a third party to >>> provide closed-source userland support for tuners while reusing all >>> the existing GPL driver code that makes up the framework. >>> >>> I used to work for a vendor that makes tuners, and they do a bunch of >>> Linux work. And that work has resulted in a bunch of open source >>> drivers. I can tell you though that *every* conversation I've had >>> regarding a new driver goes something like this: >>> >>> === >>> "Devin, we need to support tuner X under Linux." >>> >>> "Great! I'll be happy to write a new GPL driver for the >>> tuner/demodulator/whatever for that device" >>> >>> "But to save time/money, we just want to reuse the Windows driver code >>> (or reference code from the vendor)." >>> >>> "Ok. Well, what is the licensing for that code? Is it GPL compatible?" >>> >>> "Not currently. So can we just make our driver closed source?" >>> >>> "Well, you can't reuse any of the existing DVB core functionality or >>> any of the other GPL drivers (tuners, bridges, demods), so you would >>> have rewrite all that from scratch." >>> >>> "Oh, that would be a ton of work. Can we maybe write some userland >>> stuff that controls the demodulator which we can keep closed source? >>> Since it's not in the kernel, the GPL won't apply". >>> >>> "Well, you can't really do that because there is no way for the DVB >>> core to call back out to userland when the application makes the >>> tuning request to the DVB core." >>> >>> "Oh, ok then. I guess we'll have to talk to the vendor and get them >>> to give us the reference driver code under the GPL." >>> === >>> >>> I can tell you without a doubt that if this driver were present in the >>> kernel, that going forward that vendor would have *zero* interest in >>> doing any GPL driver work. Why would they? Why give away the code >>> which could potentially help their competitors if they can keep it >>> safe and protected while still being able to reuse everybody else's >>> contributions? >>> >>> Companies don't contribute GPL code out of "good will". They do it >>> because they are compelled to by licenses or because there is no >>> economically viable alternative. >>> >>> Mauro, ultimately it is your decision as the maintainer which drivers >>> get accepted in to the kernel. I can tell you though that this will
Re: [RFC] vtunerc - virtual DVB device driver
Em 21-06-2011 14:38, HoP escreveu: > 2011/6/21 Mauro Carvalho Chehab : >> Em 21-06-2011 12:09, Andreas Oberritter escreveu: >>> On 06/21/2011 04:35 PM, Mauro Carvalho Chehab wrote: Em 21-06-2011 11:15, Andreas Oberritter escreveu: > On 06/21/2011 03:44 PM, Devin Heitmueller wrote: >> On Tue, Jun 21, 2011 at 7:04 AM, Andreas Oberritter >> wrote: >>> Mauro and Devin, I think you're missing the point. This is not about >>> creating drivers in userspace. This is not about open or closed source. >>> The "vtuner" interface, as implemented for the Dreambox, is used to >>> access remote tuners: Put x tuners into y boxes and access them from >>> another box as if they were local. It's used in conjunction with further >>> software to receive the transport stream over a network connection. >>> Honza's code does the same thing. >> >> I'm not missing the point at all. I realize exactly what Honza is >> trying to accomplish (and from a purely technical standpoint, it's not >> a bad approach) - but I'm talking about the effects of such a driver >> being introduced which changes the kernel/userland licensing boundary >> and has very real implications with how the in-kernel code is >> accessed. >> >>> You don't need it in order to create closed source drivers. You can >>> already create closed kernel drivers now. Also, you can create tuner >>> drivers in userspace using the i2c-dev interface. If you like to connect >>> a userspace driver to a DVB API device node, you can distribute a small >>> (open or closed) wrapper with it. So what are you arguing about? >>> Everything you're feared of can already be done since virtually forever. >> >> I disagree. There is currently no API which allows applications to >> issue tuning requests into the DVB core, and have those requests >> proxied back out to userland where an application can then use i2c-dev >> to tune the actual device. Meaning if somebody wants to write a >> closed source userland application which controls the tuner, he/she >> can do that (while not conforming to the DVB API). But if if he wants >> to reuse the GPL licensed DVB core, he has to replace the entire DVB >> core. >> >> The introduction of this patch makes it trivial for a third party to >> provide closed-source userland support for tuners while reusing all >> the existing GPL driver code that makes up the framework. >> >> I used to work for a vendor that makes tuners, and they do a bunch of >> Linux work. And that work has resulted in a bunch of open source >> drivers. I can tell you though that *every* conversation I've had >> regarding a new driver goes something like this: >> >> === >> "Devin, we need to support tuner X under Linux." >> >> "Great! I'll be happy to write a new GPL driver for the >> tuner/demodulator/whatever for that device" >> >> "But to save time/money, we just want to reuse the Windows driver code >> (or reference code from the vendor)." >> >> "Ok. Well, what is the licensing for that code? Is it GPL compatible?" >> >> "Not currently. So can we just make our driver closed source?" >> >> "Well, you can't reuse any of the existing DVB core functionality or >> any of the other GPL drivers (tuners, bridges, demods), so you would >> have rewrite all that from scratch." >> >> "Oh, that would be a ton of work. Can we maybe write some userland >> stuff that controls the demodulator which we can keep closed source? >> Since it's not in the kernel, the GPL won't apply". >> >> "Well, you can't really do that because there is no way for the DVB >> core to call back out to userland when the application makes the >> tuning request to the DVB core." >> >> "Oh, ok then. I guess we'll have to talk to the vendor and get them >> to give us the reference driver code under the GPL." >> === >> >> I can tell you without a doubt that if this driver were present in the >> kernel, that going forward that vendor would have *zero* interest in >> doing any GPL driver work. Why would they? Why give away the code >> which could potentially help their competitors if they can keep it >> safe and protected while still being able to reuse everybody else's >> contributions? >> >> Companies don't contribute GPL code out of "good will". They do it >> because they are compelled to by licenses or because there is no >> economically viable alternative. >> >> Mauro, ultimately it is your decision as the maintainer which drivers >> get accepted in to the kernel. I can tell you though that this will >> be a very bad thing for the driver ecosystem as a whole - it will >> essentially make it trivial for vendors (some of which who are doing >> GPL work now) to p
Re: impossible to tune card, but I can watch TV :?
No exactly knowledge, but I cannot see where you define used bandwidth. Frequency and bandwidth are generally needed by every DVB-T tuner as param. Maybe those just are defaulted to different defaults or no default at all. Antti On 06/22/2011 01:05 PM, mutoid wrote: Hello, I have an Avermedia Super 007, installed in a headless Linux machine to multicast some TV channels. I use "mumudvb" and works fine, without problem. I can stream 4 TV channels and 4 radios at once But now I need to extract EPG data, using dbvtune and tv_grab_dvb I tried 2 configurations: * Kworld USB DVB-T + dvbtune + tv_grab_dvb = works fine ~# dvbtune -c 1 -f 77 Using DVB card "Afatech AF9013 DVB-T" tuning DVB-T (in United Kingdom) to 77000 Hz polling Getting frontend event FE_STATUS: polling Getting frontend event FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC Event: Frequency: 78060 SymbolRate: 0 FEC_inner: 2 Bit error rate: 0 Signal strength: 51993 SNR: 120 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC * Avermedia Super 007 + dvbtune = no working ~# dvbtune -c 0 -f 77 Using DVB card "Philips TDA10046H DVB-T" tuning DVB-T (in United Kingdom) to 77000 Hz polling Getting frontend event FE_STATUS: polling polling polling polling Why can I use dvbtune with one USB card but not with a PCI card? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: RTL2831U driver updates
On 06/22/2011 09:13 AM, Steffen Barszus wrote: On Wed, 22 Jun 2011 07:34:31 +0200 Jan Hoogenraad wrote: Thanks. Do you know more about this subject ? We do have specs about the chipset, but http://linuxtv.org/downloads/v4l-dvb-apis/remote_controllers.html#Remote_controllers_Intro only mentions lirc, not rc-core. This is about where my knowledge stops, however. rc-core is only mentioned shortly in: http://linuxtv.org/wiki/index.php/Remote_Controllers I think/hope Jarod can comment on this - i just know that new remotes should use rc-core, as this is the "new thing" for this. I'm no developer whatsoever :) No problem there, I already know rather well how rc-core is working :) Will do that. RTL2830 demod driver seems to be now rather OK, missing all statistics as I planned, but otherwise rather ready. Seems to have some more work for getting statistic since looks like it polls huge amount of regs when updating those. I am now finalizing that USB-bridge part. Do you have idea if that should be called; as used chipset names: dvb_usb_rtl2831u dvb_usb_rtl2832u dvb_usb_rtl2836u dvb_usb_rtl2840u or just name it as generic: dvb_usb_rtl28xxu dvb_usb_rtl2800u or some other. rtl28xxu or rtl2800u sounds best for me. 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: Sveon stv22 patches
Hello Comments below. Could you use Git since you have latest Kernel? If that's too hard don't try it, I can leave without, but it will easy my work a little. You have diffed wrong direction, those patches are removing lines rather than adding (- vs. +). Also you your signed off by is needed. See: http://linuxtv.org/wiki/index.php/Development:_Submitting_Patches --- ./rc-map.h 2011-06-21 11:16:55.0 +0200 +++ ./include/media/rc-map.h2011-06-21 12:41:34.114509214 +0200 @@ -130,7 +130,6 @@ #define RC_MAP_RC6_MCE "rc-rc6-mce" #define RC_MAP_REAL_AUDIO_220_32_KEYS"rc-real-audio-220-32-keys" #define RC_MAP_STREAMZAP "rc-streamzap" -#define RC_MAP_SVEON_STV22 "rc-msi-digivox-iii" #define RC_MAP_TBS_NEC "rc-tbs-nec" #define RC_MAP_TECHNISAT_USB2"rc-technisat-usb2" #define RC_MAP_TERRATEC_CINERGY_XS "rc-terratec-cinergy-xs" That's wrong, it is not needed at all. All the other seems to be rather OK. 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 2/4 v9] v4l: add control definitions for codec devices.
On Wednesday, June 22, 2011 12:30:45 Kamil Debski wrote: > > > + > > > + > spanname="id">V4L2_CID_MPEG_VIDEO_MPEG4_VOP_TIME_RES&nb > > sp; > > > + integer > > > + vop_time_increment_resolution > > value for MPEG4. Applicable to the MPEG4 encoder. > > > + > > > + > > > + > > > + > spanname="id">V4L2_CID_MPEG_VIDEO_MPEG4_VOP_TIME_INC&nb > > sp; > > > + integer > > > + vop_time_increment value for > > MPEG4. Applicable to the MPEG4 encoder. > > > > How should these two controls be used? Are you supposed to set them? Or do > > they > > have suitable default values? > > They are used only in MPEG4 and are used instead of S_PARM to set fps. > You are supposed to set them, but I think the driver could set a default value > (such as vop_time_res = 3 and vop_time_res_increment = 1000). Hmm. Perhaps S_PARM should be used for this? I am not too keen on adding this when it looks like it is exactly the same as the S_PARM functionality. How do other codecs do this? > > > + > > V4L2_MPEG_MFC51_FRAME_SKIP_MODE_DISABLED > entry> > > > + Frame skip mode is disabled. > > > + > > > + > > > + > > V4L2_MPEG_MFC51_FRAME_SKIP_MODE_LEVEL_LIMIT > > ; > > > + Frame skip mode enabled and buffer limit is set by > > the chosen level. > > > > With which control do I set that level? > > *_MPEG4_LEVEL and *_H264_LEVEL, I will add some clarification. Ah! That level :-) 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
Sveon stv22 patches
Hello Again:
The patches for sveon stv22 are done, the first test seems to be ok ,
tdt tv working , remote working, tests with ubuntu and custom kernel
3.0.0.rc4 , software tvheadend and xbmc tvlive frontend.
The console output is:
usb 5-1.4: new high speed USB device number 13 using ehci_hcd
dvb-usb: found a 'Sveon STV22 Dual USB DVB-T Tuner HDTV ' in cold
state, will try to load a firmware
dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw'
dvb-usb: found a 'Sveon STV22 Dual USB DVB-T Tuner HDTV ' in warm state.
dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
DVB: registering new adapter (Sveon STV22 Dual USB DVB-T Tuner HDTV )
af9013: firmware version:5.1.0.0
DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)...
MXL5005S: Attached at address 0xc6
dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
DVB: registering new adapter (Sveon STV22 Dual USB DVB-T Tuner HDTV )
af9013: found a 'Afatech AF9013 DVB-T' in warm state.
af9013: firmware version:5.1.0.0
DVB: registering adapter 1 frontend 0 (Afatech AF9013 DVB-T)...
MXL5005S: Attached at address 0xc6
Registered IR keymap rc-msi-digivox-iii
input: IR-receiver inside an USB DVB receiver as
/devices/pci:00/:00:1d.7/usb5/5-1/5-1.4/rc/rc2/input11
rc2: IR-receiver inside an USB DVB receiver as
/devices/pci:00/:00:1d.7/usb5/5-1/5-1.4/rc/rc2
dvb-usb: schedule remote query interval to 500 msecs.
dvb-usb: Sveon STV22 Dual USB DVB-T Tuner HDTV successfully
initialized and connected.
usbcore: registered new interface driver dvb_usb_af9015
Thanks for your time
Emilio David Diaus López
--- ./af9015.c 2011-06-22 12:05:28.0 +0200
+++ ./drivers/media/dvb/dvb-usb/af9015.c 2011-06-21 12:39:44.944874021 +0200
@@ -749,8 +749,6 @@
RC_MAP_AZUREWAVE_AD_TU700 },
{ (USB_VID_MSI_2 << 16) + USB_PID_MSI_DIGI_VOX_MINI_III,
RC_MAP_MSI_DIGIVOX_III },
- { (USB_VID_KWORLD_2 << 16) + USB_PID_SVEON_STV22,
- RC_MAP_MSI_DIGIVOX_III },
{ (USB_VID_LEADTEK << 16) + USB_PID_WINFAST_DTV_DONGLE_GOLD,
RC_MAP_LEADTEK_Y04G0051 },
{ (USB_VID_AVERMEDIA << 16) + USB_PID_AVERMEDIA_VOLAR_X,
@@ -1311,7 +1309,6 @@
USB_PID_TERRATEC_CINERGY_T_STICK_DUAL_RC)},
/* 35 */{USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_A850T)},
{USB_DEVICE(USB_VID_GTEK, USB_PID_TINYTWIN_3)},
- {USB_DEVICE(USB_VID_KWORLD_2, USB_PID_SVEON_STV22)},
{0},
};
MODULE_DEVICE_TABLE(usb, af9015_usb_table);
@@ -1652,11 +1649,6 @@
.warm_ids = {NULL},
},
{
-.name = "Sveon STV22 Dual USB DVB-T Tuner HDTV ",
-.cold_ids = {&af9015_usb_table[37], NULL},
-.warm_ids = {NULL},
- },
- {
.name = "Leadtek WinFast DTV2000DS",
.cold_ids = {&af9015_usb_table[29], NULL},
.warm_ids = {NULL},
--- ./dvb-usb-ids.h 2011-06-18 11:48:22.0 +0200
+++ ./drivers/media/dvb/dvb-usb/dvb-usb-ids.h 2011-06-21 12:39:45.017873108 +0200
@@ -128,7 +128,6 @@
#define USB_PID_INTEL_CE95000x9500
#define USB_PID_KWORLD_399U0xe399
#define USB_PID_KWORLD_399U_20xe400
-#define USB_PID_SVEON_STV220xe401
#define USB_PID_KWORLD_395U0xe396
#define USB_PID_KWORLD_395U_20xe39b
#define USB_PID_KWORLD_395U_30xe395
--- ./rc-map.h 2011-06-21 11:16:55.0 +0200
+++ ./include/media/rc-map.h 2011-06-21 12:41:34.114509214 +0200
@@ -130,7 +130,6 @@
#define RC_MAP_RC6_MCE "rc-rc6-mce"
#define RC_MAP_REAL_AUDIO_220_32_KEYS"rc-real-audio-220-32-keys"
#define RC_MAP_STREAMZAP "rc-streamzap"
-#define RC_MAP_SVEON_STV22 "rc-msi-digivox-iii"
#define RC_MAP_TBS_NEC "rc-tbs-nec"
#define RC_MAP_TECHNISAT_USB2"rc-technisat-usb2"
#define RC_MAP_TERRATEC_CINERGY_XS "rc-terratec-cinergy-xs"
RE: [PATCH 2/4 v9] v4l: add control definitions for codec devices.
Hi, > -Original Message- > From: Hans Verkuil [mailto:hverk...@xs4all.nl] > Sent: 22 June 2011 10:26 > To: Kamil Debski > Cc: linux-media@vger.kernel.org; m.szyprow...@samsung.com; > kyungmin.p...@samsung.com; jaeryul...@samsung.com; > laurent.pinch...@ideasonboard.com; jtp.p...@samsung.com > Subject: Re: [PATCH 2/4 v9] v4l: add control definitions for codec devices. > > On Tuesday, June 14, 2011 18:36:54 Kamil Debski wrote: > > Add control definitions and documentation for controls > > specific to codec devices. > > > > Signed-off-by: Kamil Debski > > Signed-off-by: Kyungmin Park > > --- > > Documentation/DocBook/media/v4l/controls.xml | 958 > ++ > > include/linux/videodev2.h| 171 + > > 2 files changed, 1129 insertions(+), 0 deletions(-) > > > > diff --git a/Documentation/DocBook/media/v4l/controls.xml > b/Documentation/DocBook/media/v4l/controls.xml > > index 6880798..6b0d06a 100644 > > --- a/Documentation/DocBook/media/v4l/controls.xml > > +++ b/Documentation/DocBook/media/v4l/controls.xml > > @@ -325,6 +325,22 @@ minimum value disables backlight > compensation. > > V4L2_CID_ILLUMINATORS_2 + 1). > > > > > > + ... > > + > > + > > + > > + > > +spanname="id">V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE t> > > + boolean > > + > > + If enabled the decoder expects a > single slice in one OUTPUT buffer, otherwise > > +the decoder expects a single frame in one input buffer. Applicable to the > decoder, all codecs. > > 'in one OUTPUT buffer' vs 'in one input buffer'. Perhaps rewriting it like > this is better: > > If enabled the decoder expects to > receive a single slice per buffer, otherwise > the decoder expects a single frame in per buffer. Applicable to the decoder, > all codecs. > > BTW: 'all codecs'? Your decoder hardware can handle e.g. MPEG-2 sliced input? > I thought slices were specific to e.g. MPEG4/H264? Just checking... I've checked the H263 spec and it mentions slice, same for MPEG2 (this site http://goo.gl/vXUEb mentions slices). It could be better to explicitly list the codecs, as there might be a codec that doesn't support slices. > > > + > > + > > + > > + > > + > > +spanname="id">V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_ENABLE&n > bsp; > > + boolean > > + > > + Enable writing sample aspect ratio > in the Video Usability Information. > > +Applicable to the H264 encoder. > > + > > + ... > > + > > + > > + > > +spanname="id">V4L2_CID_MPEG_VIDEO_H263_I_FRAME_QP > > > + integer > > + > > + Quantization parameter for an I > frame for H263. Valid range: from 1 to 31. > > Is this range defined by the H263 standard? If not, then you shouldn't > mention > the range as it is hardware dependent. Yes it is defined in the standard. > > > + > > + > > + > > + > > +spanname="id">V4L2_CID_MPEG_VIDEO_H263_MIN_QP try> > > + > > + > > + > > +spanname="id">V4L2_CID_MPEG_VIDEO_VBV_SIZE > > > + integer > > + > > + The Video Buffer Verifier size in > kilobytes, it used as a limitation of frame skip. > > Typo: 'it used' -> 'it is used' > > I think it would be good to either give some background information here, or > refer > to the standard for that information. Ok, will do. > > +Applicable to the MPEG1, MPEG2, MPEG4 encoders. > > + > > + > > + > > + > > +spanname="id">V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE entry> > > + integer > > + > > + The Coded Picture Buffer size in > kilobytes, it used as a limitation of frame skip. > > Same typo. > > > +Applicable to the H264 encoder. > > + > > + > > + > > + > > +spanname="id">V4L2_CID_MPEG_VIDEO_H264_I_PERIOD entry> > > + integer > > + > > + Period between I-frames in the open > GOP for H264. In case of an open GOP > > +this is the period between two I-frames. The period between IDR > (Instantaneous Decoding Refresh) frames is taken from the GOP_SIZE control. > > +An IDR frame, which stands for Instantaneous Decoding Refresh is an I- > frame after which no prior frames are > > +referenced. This means that a stream can be restarted from an IDR frame > without the need to store or decode any > > +previous frames. Applicable to the H264 encoder. > > + > > + ... > > + > > +spanname="id">V4L2_CID_MPEG_VIDEO_MPEG4_VOP_TIME_RES&nb > sp; > > + integer > > + vop_time_increment_resolution > value for MPEG4. Applicable to the MPEG4 encoder. > > + > > + > > + > > +spanname="id">V4L2_CID_MPEG_VIDEO_MPEG4_VOP_TIME_INC&nb > sp; > > + integer > > + vop_time_increment
[PATCH] Improve UVC buffering with regard to USB. Add checks to avoid division by zero.
Hi,
In the UVC driver, the amount of buffering is controlled by the picture frame
size divided by
the USB packet size. This can sometimes lead to too small or too big buffers.
The solution is
to fix the buffer size with regard to the amount of buffering time:
This patch will fix ISOCHRONOUS buffers around 2x16ms of buffering time. This
should give around
1000 / 16 = 62 IRQ/s, which should suffice for up to 60 FPS unbuffered. If the
frame rate goes
beyond 60FPS it is likely that there will be data loss due to too small buffers.
BULK buffers are fixed around 2x16K for non FULL speed and 2x4K for FULL speed
USB,
regardless of the frame size. This is a well known good combination for BULK
buffering.
--HPS
>From 9a9225cbfe22c978d3b92892580c2ca1e6f5abb2 Mon Sep 17 00:00:00 2001
From: Hans Petter Selasky
Date: Wed, 22 Jun 2011 12:02:15 +0200
Subject: [PATCH] Improve UVC buffering with regard to USB. Add checks to avoid
division by zero.
Signed-off-by: Hans Petter Selasky
---
drivers/media/video/uvc/uvc_video.c | 38 ++
drivers/media/video/uvc/uvcvideo.h |4 +-
2 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/media/video/uvc/uvc_video.c
b/drivers/media/video/uvc/uvc_video.c
index fc766b9..dfc5978 100644
--- a/drivers/media/video/uvc/uvc_video.c
+++ b/drivers/media/video/uvc/uvc_video.c
@@ -823,9 +823,7 @@ static int uvc_alloc_urb_buffers(struct uvc_streaming
*stream,
/* Compute the number of packets. Bulk endpoints might transfer UVC
* payloads across multiple URBs.
*/
- npackets = DIV_ROUND_UP(size, psize);
- if (npackets > UVC_MAX_PACKETS)
- npackets = UVC_MAX_PACKETS;
+ npackets = size / psize;
/* Retry allocations until one succeed. */
for (; npackets > 1; npackets /= 2) {
@@ -888,8 +886,25 @@ static int uvc_init_video_isoc(struct uvc_streaming
*stream,
u32 size;
psize = le16_to_cpu(ep->desc.wMaxPacketSize);
- psize = (psize & 0x07ff) * (1 + ((psize >> 11) & 3));
- size = stream->ctrl.dwMaxVideoFrameSize;
+
+ if (stream->dev->udev->speed == USB_SPEED_FULL) {
+ /* (8000 >> 3) = 1000 FPS */
+ psize = (psize & 0x07ff);
+ size = (UVC_MAX_PACKETS >> 3) * psize;
+ } else {
+ /* 1000 - 8000 FPS, figure out */
+ psize = (psize & 0x07ff) * (1 + ((psize >> 11) & 3));
+ size = ep->desc.bInterval;
+ if (size > 0)
+ size --;
+ if (size > 3)
+ size = 3;
+ size = (UVC_MAX_PACKETS >> size) * psize;
+ }
+
+ /* avoid division by zero */
+ if (psize == 0)
+ return -EINVAL;
npackets = uvc_alloc_urb_buffers(stream, size, psize, gfp_flags);
if (npackets == 0)
@@ -943,6 +958,19 @@ static int uvc_init_video_bulk(struct uvc_streaming
*stream,
size = stream->ctrl.dwMaxPayloadTransferSize;
stream->bulk.max_payload_size = size;
+ /* avoid division by zero */
+ if (psize == 0)
+ return -EINVAL;
+
+ /* roughly compute size for buffers */
+ if (stream->dev->udev->speed == USB_SPEED_FULL) {
+ size = 4096;
+ } else {
+ size = 16384;
+ }
+ /* align to packet boundary */
+ size += (psize - (size % psize)) % psize;
+
npackets = uvc_alloc_urb_buffers(stream, size, psize, gfp_flags);
if (npackets == 0)
return -ENOMEM;
diff --git a/drivers/media/video/uvc/uvcvideo.h
b/drivers/media/video/uvc/uvcvideo.h
index 45f01e7..2adbaf2 100644
--- a/drivers/media/video/uvc/uvcvideo.h
+++ b/drivers/media/video/uvc/uvcvideo.h
@@ -161,9 +161,9 @@ struct uvc_xu_control {
#define DRIVER_VERSION "v1.0.0"
/* Number of isochronous URBs. */
-#define UVC_URBS 5
+#define UVC_URBS 2U
/* Maximum number of packets per URB. */
-#define UVC_MAX_PACKETS32
+#define UVC_MAX_PACKETS128U/* at 8000 FPS */
/* Maximum number of video buffers. */
#define UVC_MAX_VIDEO_BUFFERS 32
/* Maximum status buffer size in bytes of interrupt URB. */
--
1.7.1.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
impossible to tune card, but I can watch TV :?
Hello, I have an Avermedia Super 007, installed in a headless Linux machine to multicast some TV channels. I use "mumudvb" and works fine, without problem. I can stream 4 TV channels and 4 radios at once But now I need to extract EPG data, using dbvtune and tv_grab_dvb I tried 2 configurations: * Kworld USB DVB-T + dvbtune + tv_grab_dvb = works fine ~# dvbtune -c 1 -f 77 Using DVB card "Afatech AF9013 DVB-T" tuning DVB-T (in United Kingdom) to 77000 Hz polling Getting frontend event FE_STATUS: polling Getting frontend event FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC Event: Frequency: 78060 SymbolRate: 0 FEC_inner: 2 Bit error rate: 0 Signal strength: 51993 SNR: 120 FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI FE_HAS_SYNC * Avermedia Super 007 + dvbtune = no working ~# dvbtune -c 0 -f 77 Using DVB card "Philips TDA10046H DVB-T" tuning DVB-T (in United Kingdom) to 77000 Hz polling Getting frontend event FE_STATUS: polling polling polling polling Why can I use dvbtune with one USB card but not with a PCI card? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: vb2: holding buffers until after start_streaming()
Hello, On Tuesday, June 21, 2011 7:14 PM Jonathan Corbet wrote: > On Tue, 21 Jun 2011 18:07:03 +0200 > Marek Szyprowski wrote: > > > I have an idea to introduce a new flags to let device driver tell vb2 > > weather it supports 'streaming without buffers' or not. This way the > > order of operations in vb2_streamon() function can be switched and vb2 > > can also return an error if one will try to enable streaming on device > > that cannot do it without buffers pre-queued. > > Do you really need a flag? If a driver absolutely cannot stream without > buffers queued (and can't be fixed to start streaming for real when the > buffers show up) it should just return -EINVAL from start_streaming() or > some such. The driver must be aware of its limitations regardless, but > there's no need to push that awareness into vb2 as well. The main idea behind vb2 was to move all common error handling code to the framework and provide simple functions that can be used by the driver directly without the need for additional checks. > (FWIW, I wouldn't switch the order of operations in vb2_streamon(); I > would just take out the "if (q->streaming)" test at the end of vb2_qbuf() > and pass the buffers through directly. But maybe that's just me.) I want to keep the current version of vb2_qbuf() and change the order of operations in streamon(). The only problem that still need to be resolved is what should happen with the buffers if start_streaming() fails. The ownership for these buffers have been already given to the driver, but they might have been in dirty state. Probably vb2 should assume that the buffers are lost and reinitialize them. Best regards -- Marek Szyprowski Samsung Poland R&D 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: [PATCH/RFC] fbdev: Add FOURCC-based format configuration API
Hi Florian, On Wednesday 22 June 2011 07:45:45 Florian Tobias Schandinat wrote: > On 06/21/2011 10:31 PM, Laurent Pinchart wrote: > > On Tuesday 21 June 2011 22:49:14 Geert Uytterhoeven wrote: > >> On Tue, Jun 21, 2011 at 17:36, Laurent Pinchart wrote: > >>> +The FOURCC-based API replaces format descriptions by four character > >>> codes +(FOURCC). FOURCCs are abstract identifiers that uniquely define > >>> a format +without explicitly describing it. This is the only API that > >>> supports YUV +formats. Drivers are also encouraged to implement the > >>> FOURCC-based API for RGB +and grayscale formats. > >>> + > >>> +Drivers that support the FOURCC-based API report this capability by > >>> setting +the FB_CAP_FOURCC bit in the fb_fix_screeninfo capabilities > >>> field. + > >>> +FOURCC definitions are located in the linux/videodev2.h header. > >>> However, and +despite starting with the V4L2_PIX_FMT_prefix, they are > >>> not restricted to V4L2 +and don't require usage of the V4L2 subsystem. > >>> FOURCC documentation is +available in > >>> Documentation/DocBook/v4l/pixfmt.xml. > >>> + > >>> +To select a format, applications set the FB_VMODE_FOURCC bit in the > >>> +fb_var_screeninfo vmode field, and set the fourcc field to the desired > >>> FOURCC. +The bits_per_pixel, red, green, blue, transp and nonstd fields > >>> must be set to +0 by applications and ignored by drivers. Note that the > >>> grayscale and fourcc +fields share the same memory location. > >>> Application must thus not set the +grayscale field to 0. > >> > >> These are the only parts I don't like: (ab)using the vmode field (this > >> isn't really a vmode flag), and the union of grayscale and fourcc (avoid > >> unions where possible). > > > > I've proposed adding a FB_NONSTD_FORMAT bit to the nonstd field as a > > FOURCC mode indicator in my initial RFC. Florian Tobias Schandinat > > wasn't very happy with that, and proposed using the vmode field instead. > > > > Given that there's virtually no fbdev documentation, whether the vmode > > field and/or nonstd field are good fit for a FOURCC mode indicator is > > subject to interpretation. > > The reason for my suggestion is that the vmode field is accepted to contain > only flags and at least to me there is no hard line what is part of the > video mode and what is not. Lacks of documentation indeed makes that line fuzzy. I really hope that api.txt will be extended to cover the full fbdev API :-) > In contrast the nonstd field is already used in a lot of different > (incompatible) ways. I think if we only use the nonstd field for handling > FOURCC it is likely that some problems will appear. > > >> What about storing the FOURCC value in nonstd instead? > > > > Wouldn't that be a union of nonstd and fourcc ? :-) FOURCC-based format > > setting will be a standard fbdev API, I'm not very keen on storing it in > > the nonstd field without a union. > > > >> As FOURCC values are always 4 ASCII characters (hence all 4 bytes must > >> be non-zero), I don't think there are any conflicts with existing values > >> of nonstd. To make it even safer and easier to parse, you could set bit > >> 31 of nonstd as a FOURCC indicator. > > > > I would then create a union between nonstd and fourcc, and document > > nonstd as being used for the legacy API only. Most existing drivers use > > a couple of nonstd bits only. The driver that (ab)uses nonstd the most > > is pxafb and uses bits 22:0. Bits 31:24 are never used as far as I can > > tell, so nonstd& 0xff00 != 0 could be used as a FOURCC mode test. > > > > This assumes that FOURCCs will never have their last character set to > > '\0'. Is that a safe assumption for the future ? > > Yes, I think. The information I found indicates that space should be used > for padding, so a \0 shouldn't exist. > I think using only the nonstd field and requiring applications to check the > capabilities would be possible, although not fool proof ;) > > Great work, Laurent, do you have plans to modify fbset to allow using this > format API from the command line? Once we agree on an API, I will implement it in a driver and update fbset. -- 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 4/4 v9] MFC: Add MFC 5.1 V4L2 driver
On Tuesday, June 14, 2011 18:36:56 Kamil Debski wrote:
> Multi Format Codec 5.1 is a hardware video coding acceleration
> module found in the S5PV210 and Exynos4 Samsung SoCs. It is
> capable of handling a range of video codecs and this driver
> provides a V4L2 interface for video decoding and encoding.
>
> Signed-off-by: Kamil Debski
> Signed-off-by: Kyungmin Park
> Cc: Jeongtae Park
> ---
> drivers/media/video/Kconfig |8 +
> drivers/media/video/Makefile |1 +
> drivers/media/video/s5p-mfc/Makefile |5 +
> drivers/media/video/s5p-mfc/regs-mfc.h | 385 +
> drivers/media/video/s5p-mfc/s5p_mfc.c| 1359 +
> drivers/media/video/s5p-mfc/s5p_mfc_cmd.c| 143 ++
> drivers/media/video/s5p-mfc/s5p_mfc_cmd.h| 28 +
> drivers/media/video/s5p-mfc/s5p_mfc_common.h | 472 ++
> drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c | 393 +
> drivers/media/video/s5p-mfc/s5p_mfc_ctrl.h | 27 +
> drivers/media/video/s5p-mfc/s5p_mfc_debug.h | 48 +
> drivers/media/video/s5p-mfc/s5p_mfc_dec.c| 1106 ++
> drivers/media/video/s5p-mfc/s5p_mfc_dec.h| 23 +
> drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 2021
> ++
> drivers/media/video/s5p-mfc/s5p_mfc_enc.h| 23 +
> drivers/media/video/s5p-mfc/s5p_mfc_inst.c | 52 +
> drivers/media/video/s5p-mfc/s5p_mfc_inst.h | 19 +
> drivers/media/video/s5p-mfc/s5p_mfc_intr.c | 94 ++
> drivers/media/video/s5p-mfc/s5p_mfc_intr.h | 26 +
> drivers/media/video/s5p-mfc/s5p_mfc_mem.h| 55 +
> drivers/media/video/s5p-mfc/s5p_mfc_opr.c| 1588
> drivers/media/video/s5p-mfc/s5p_mfc_opr.h| 88 ++
> drivers/media/video/s5p-mfc/s5p_mfc_pm.c | 131 ++
> drivers/media/video/s5p-mfc/s5p_mfc_pm.h | 24 +
> drivers/media/video/s5p-mfc/s5p_mfc_reg.c| 30 +
> drivers/media/video/s5p-mfc/s5p_mfc_reg.h| 126 ++
> drivers/media/video/s5p-mfc/s5p_mfc_shm.c| 55 +
> drivers/media/video/s5p-mfc/s5p_mfc_shm.h| 86 ++
> 28 files changed, 8416 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/s5p-mfc/Makefile
> create mode 100644 drivers/media/video/s5p-mfc/regs-mfc.h
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc.c
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd.c
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd.h
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_common.h
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_ctrl.h
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_debug.h
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_dec.c
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_dec.h
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_enc.c
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_enc.h
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_inst.c
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_inst.h
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_intr.c
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_intr.h
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_mem.h
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr.c
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr.h
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_pm.c
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_pm.h
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_reg.c
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_reg.h
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_shm.c
> create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_shm.h
>
...
> diff --git a/drivers/media/video/s5p-mfc/s5p_mfc_dec.c
> b/drivers/media/video/s5p-mfc/s5p_mfc_dec.c
> new file mode 100644
> index 000..a3d7378
> --- /dev/null
> +++ b/drivers/media/video/s5p-mfc/s5p_mfc_dec.c
...
> +static int s5p_mfc_dec_g_v_ctrl(struct v4l2_ctrl *ctrl)
> +{
> + struct s5p_mfc_ctx *ctx = ctrl_to_ctx(ctrl);
> + struct s5p_mfc_dev *dev = ctx->dev;
> +
> + switch (ctrl->id) {
> + case V4L2_CID_MIN_BUFFERS_FOR_CAPTURE:
> + if (ctx->state >= MFCINST_HEAD_PARSED &&
> + ctx->state < MFCINST_ABORT) {
> + ctrl->cur.val = ctx->dpb_count;
> + break;
> + } else if (ctx->state != MFCINST_INIT) {
> + v4l2_err(&dev->v4l2_dev, "Decoding not initialised.\n");
> + return -EINVAL;
> + }
> +
> + /* Should wait for the header to be parsed */
> + s5p_mfc_clean_ctx_int_flags(ctx);
> + s5p_mfc_wait_for_done_ctx(ctx,
> + S5P_FIMV_R2H_CMD_SEQ_DONE_RET, 0);
> + if (ctx->state >= MFCINST_HEAD_PARSED &&
> + ctx->state < MFCINST_AB
Re: [PATCH 2/4 v9] v4l: add control definitions for codec devices.
On Tuesday, June 14, 2011 18:36:54 Kamil Debski wrote: > Add control definitions and documentation for controls > specific to codec devices. > > Signed-off-by: Kamil Debski > Signed-off-by: Kyungmin Park > --- > Documentation/DocBook/media/v4l/controls.xml | 958 > ++ > include/linux/videodev2.h| 171 + > 2 files changed, 1129 insertions(+), 0 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/controls.xml > b/Documentation/DocBook/media/v4l/controls.xml > index 6880798..6b0d06a 100644 > --- a/Documentation/DocBook/media/v4l/controls.xml > +++ b/Documentation/DocBook/media/v4l/controls.xml > @@ -325,6 +325,22 @@ minimum value disables backlight compensation. > V4L2_CID_ILLUMINATORS_2 + 1). > > > + V4L2_CID_MIN_BUFFERS_FOR_CAPTURE > + integer > + This is a read-only control that can be read by the > application > +and used as a hint to determine the number of CAPTURE buffers to pass to > REQBUFS. > +The value is the minimum number of CAPTURE buffers that is necessary for > hardware > +to work. > + > + > + V4L2_CID_MIN_BUFFERRS_FOR_OUTPUT Typo: double 'R' in BUFFERRS :-) > + integer > + This is a read-only control that can be read by the > application > +and used as a hint to determine the number of OUTPUT buffers to pass to > REQBUFS. > +The value is the minimum number of OUTPUT buffers that is necessary for > hardware > +to work. > + > + > V4L2_CID_PRIVATE_BASE > > ID of the first custom (driver specific) control. > @@ -1409,6 +1425,948 @@ of the video. The supplied 32-bit integer is > interpreted as follows (bit > > > > + > + > + > + > + spanname="id">V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE > + boolean > + > + If enabled the decoder expects a > single slice in one OUTPUT buffer, otherwise > +the decoder expects a single frame in one input buffer. Applicable to the > decoder, all codecs. 'in one OUTPUT buffer' vs 'in one input buffer'. Perhaps rewriting it like this is better: If enabled the decoder expects to receive a single slice per buffer, otherwise the decoder expects a single frame in per buffer. Applicable to the decoder, all codecs. BTW: 'all codecs'? Your decoder hardware can handle e.g. MPEG-2 sliced input? I thought slices were specific to e.g. MPEG4/H264? Just checking... > + > + > + > + > + > + spanname="id">V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_ENABLE > + boolean > + > + Enable writing sample aspect ratio > in the Video Usability Information. > +Applicable to the H264 encoder. > + > + > + > + > + spanname="id">V4L2_CID_MPEG_VIDEO_H264_VUI_SAR_IDC > + enum v4l2_mpeg_video_h264_vui_sar_idc > + > + VUI sample aspect ratio indicator > for H.264 encoding. The value > +is defined in the table E-1 in the standard. Applicable to the H264 > encoder. > + > + > + > + > + > + > + > V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_UNSPECIFIED > + Unspecified > + > + > + > V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_1x1 > + 1x1 > + > + > + > V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_12x11 > + 12x11 > + > + > + > V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_10x11 > + 10x11 > + > + > + > V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_16x11 > + 16x11 > + > + > + > V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_40x33 > + 40x33 > + > + > + > V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_24x11 > + 24x11 > + > + > + > V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_20x11 > + 20x11 > + > + > + > V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_32x11 > + 32x11 > + > + > + > V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_80x33 > + 80x33 > + > + > + > V4L2_MPEG_VIDEO_H264_VUI_SAR_IDC_18x11 > + 18x11 > + > + > + >
Re: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
On Wed, 22 Jun 2011 09:03:30 +0200, Hans Verkuil wrote: What I was wondering about is how this patch series changes the allocation in case it can't allocate from the CMA pool. Will it attempt to fall back to a 'normal' allocation? Unless Marek changed something since I wrote the code, which I doubt, if CMA cannot obtain memory from CMA region, it will fail. Part of the reason is that CMA lacks the knowledge where to allocate memory from. For instance, with the case of several memory banks, it does not know which memory bank to allocate from. It is, in my opinion, a task for a higher level functions (read: DMA layer) to try another mechanism if CMA fails. -- Best regards, _ _ .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o ..o | Computer Science, Michal "mina86" Nazarewicz(o o) ooo +--ooO--(_)--Ooo-- -- 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: [Linaro-mm-sig] [PATCH 08/10] mm: cma: Contiguous Memory Allocator added
On Wednesday, June 15, 2011 09:37:18 Arnd Bergmann wrote: > On Wednesday 15 June 2011 09:11:39 Marek Szyprowski wrote: > > I see your concerns, but I really wonder how to determine the properties > > of the global/default cma pool. You definitely don't want to give all > > available memory o CMA, because it will have negative impact on kernel > > operation (kernel really needs to allocate unmovable pages from time to > > time). > > Exactly. This is a hard problem, so I would prefer to see a solution for > coming up with reasonable defaults. > > > The only solution I see now is to provide Kconfig entry to determine > > the size of the global CMA pool, but this still have some issues, > > especially for multi-board kernels (each board probably will have > > different amount of RAM and different memory-consuming devices > > available). It looks that each board startup code still might need to > > tweak the size of CMA pool. I can add a kernel command line option for > > it, but such solution also will not solve all the cases (afair there > > was a discussion about kernel command line parameters for memory > > configuration and the conclusion was that it should be avoided). > > The command line option can be a last resort if the heuristics fail, > but it's not much better than a fixed Kconfig setting. > > How about a Kconfig option that defines the percentage of memory > to set aside for contiguous allocations? I would actually like to see a cma_size kernel option of some sort. This would be for the global CMA pool only as I don't think we should try to do anything more complicated here. While it is relatively easy for embedded systems to do a recompile every time you need to change the pool size, this isn't an option on 'normal' desktop systems. While usually you have more than enough memory on such systems and don't need CMA, there are a number of cases where you do want to reserve sufficient memory. Usually these involve lots of video capture cards in one system. What I was wondering about is how this patch series changes the allocation in case it can't allocate from the CMA pool. Will it attempt to fall back to a 'normal' allocation? The reason I ask is that for desktop systems you could just start with a CMA pool of size 0. And only in specific situations would you need to add a cma_size kernel parameter depending on your needs. But this scheme would require a fallback scenario in case of a global CMA pool of size 0. Hmm, perhaps this fallback scenario is more driver specific. For SoC platform video devices you may not want a fallback, whereas for PCI(e)/USB devices you do. I don't know what's best, frankly. 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
