Re: Anysee E30 S2 plus
On 12/20/2011 03:04 AM, Jesper Krogh wrote: Hi I have a brand new Anysee E30 S2 plus, but with most recent media_build.git - it is reported as the wrong model. I have attached a copy of my lsusb output. That don't help at all. You should look from system log what it says. Use dmesg command for that. 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
about v4l2_fh_is_singular
Hi Sakari, Hans recommends me using v4l2_fh_is_singular in first open, but I found it used list_is_singular(fh-list). Should it use fh-vdev-fh_list or I missed something? Regards, Scott -- 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: Anysee E30 S2 plus
Ok. I had my doubts on whether to include that or not - But here it is /Jesper [ 1053.784044] usb 1-6: new high speed USB device number 7 using ehci_hcd [ 1054.556036] usb 1-6: device not accepting address 7, error -71 [ 1054.668043] usb 1-6: new high speed USB device number 8 using ehci_hcd [ 1056.136482] usb 1-6: config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64 [ 1056.136492] usb 1-6: config 1 interface 0 altsetting 0 bulk endpoint 0x81 has invalid maxpacket 64 [ 1056.136501] usb 1-6: config 1 interface 0 altsetting 1 bulk endpoint 0x1 has invalid maxpacket 64 [ 1056.136508] usb 1-6: config 1 interface 0 altsetting 1 bulk endpoint 0x81 has invalid maxpacket 64 [ 1056.137448] dvb-usb: found a 'Anysee DVB USB2.0' in warm state. [ 1056.137553] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 1056.137559] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 1056.137882] DVB: registering new adapter (Anysee DVB USB2.0) [ 1056.141938] anysee: firmware version:1.3 hardware id:11 [ 1056.145212] Invalid probe, probably not a CX24116 device [ 1056.145231] anysee: Unsupported Anysee version. Please report the linux-media@vger.kernel.org. [ 1056.145239] dvb-usb: no frontend was attached by 'Anysee DVB USB2.0' [ 1056.145473] Registered IR keymap rc-anysee [ 1056.145709] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb1/1-6/rc/rc1/input15 [ 1056.145858] rc1: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb1/1-6/rc/rc1 [ 1056.145866] dvb-usb: schedule remote query interval to 250 msecs. [ 1056.145873] dvb-usb: Anysee DVB USB2.0 successfully initialized and connected. On Tue, Dec 20, 2011 at 5:07 AM, Antti Palosaari cr...@iki.fi wrote: On 12/20/2011 03:04 AM, Jesper Krogh wrote: Hi I have a brand new Anysee E30 S2 plus, but with most recent media_build.git - it is reported as the wrong model. I have attached a copy of my lsusb output. That don't help at all. You should look from system log what it says. Use dmesg command for that. 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: [GIT PULL FOR 3.3] HDIC HD29L2 DMB-TH demodulator driver
On 14-12-2011 20:57, Antti Palosaari wrote:
Mauro,
Please PULL that new driver to the Kernel 3.3!
Antti
The following changes since commit 6dbc13e364ad49deb9dd93c4ab84af53ffb52435:
mxl5007t: implement .get_if_frequency() (2011-10-10 00:57:07 +0300)
are available in the git repository at:
git://linuxtv.org/anttip/media_tree.git hdic
Antti Palosaari (1):
HDIC HD29L2 DMB-TH demodulator driver
From: Antti Palosaari cr...@iki.fi
Date: Mon, 7 Nov 2011 01:01:13 +0200
Subject: HDIC HD29L2 DMB-TH demodulator driver
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb/frontends/Kconfig |7 +
drivers/media/dvb/frontends/Makefile |1 +
drivers/media/dvb/frontends/hd29l2.c | 863
+
drivers/media/dvb/frontends/hd29l2.h | 66 +++
drivers/media/dvb/frontends/hd29l2_priv.h | 314 +++
5 files changed, 1251 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/hd29l2.c
create mode 100644 drivers/media/dvb/frontends/hd29l2.h
create mode 100644 drivers/media/dvb/frontends/hd29l2_priv.h
diff --git a/drivers/media/dvb/frontends/Kconfig
b/drivers/media/dvb/frontends/Kconfig
index 4a2d2e6..ebb5ed7 100644
--- a/drivers/media/dvb/frontends/Kconfig
+++ b/drivers/media/dvb/frontends/Kconfig
@@ -404,6 +404,13 @@ config DVB_EC100
help
Say Y when you want to support this frontend.
+config DVB_HD29L2
+ tristate HDIC HD29L2
+ depends on DVB_CORE I2C
+ default m if DVB_FE_CUSTOMISE
+ help
+ Say Y when you want to support this frontend.
+
config DVB_STV0367
tristate ST STV0367 based
depends on DVB_CORE I2C
diff --git a/drivers/media/dvb/frontends/Makefile
b/drivers/media/dvb/frontends/Makefile
index f639f67..00a2063 100644
--- a/drivers/media/dvb/frontends/Makefile
+++ b/drivers/media/dvb/frontends/Makefile
@@ -84,6 +84,7 @@ obj-$(CONFIG_DVB_STV090x) += stv090x.o
obj-$(CONFIG_DVB_STV6110x) += stv6110x.o
obj-$(CONFIG_DVB_ISL6423) += isl6423.o
obj-$(CONFIG_DVB_EC100) += ec100.o
+obj-$(CONFIG_DVB_HD29L2) += hd29l2.o
obj-$(CONFIG_DVB_DS3000) += ds3000.o
obj-$(CONFIG_DVB_MB86A16) += mb86a16.o
obj-$(CONFIG_DVB_MB86A20S) += mb86a20s.o
diff --git a/drivers/media/dvb/frontends/hd29l2.c
b/drivers/media/dvb/frontends/hd29l2.c
new file mode 100644
index 000..a85ed47
--- /dev/null
+++ b/drivers/media/dvb/frontends/hd29l2.c
@@ -0,0 +1,863 @@
+/*
+ * HDIC HD29L2 DMB-TH demodulator driver
+ *
+ * Copyright (C) 2011 Metropolia University of Applied Sciences, Electria RD
+ *
+ * Author: Antti Palosaari cr...@iki.fi
+ *
+ *This program is free software; you can redistribute it and/or modify
+ *it under the terms of the GNU General Public License as published by
+ *the Free Software Foundation; either version 2 of the License, or
+ *(at your option) any later version.
+ *
+ *This program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *GNU General Public License for more details.
+ *
+ *You should have received a copy of the GNU General Public License
+ *along with this program; if not, write to the Free Software
+ *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include hd29l2_priv.h
+
+int hd29l2_debug;
+module_param_named(debug, hd29l2_debug, int, 0644);
+MODULE_PARM_DESC(debug, Turn on/off frontend debugging (default:off).);
+
+/* write multiple registers */
+static int hd29l2_wr_regs(struct hd29l2_priv *priv, u8 reg, u8 *val, int len)
+{
+ int ret;
+ u8 buf[2+len];
CodingStyle. It should be, instead:
u8 buf[2 + len]
+ struct i2c_msg msg[1] = {
+ {
+ .addr = priv-cfg.i2c_addr,
+ .flags = 0,
+ .len = sizeof(buf),
+ .buf = buf,
+ }
+ };
+
+ buf[0] = 0x00;
+ buf[1] = reg;
+ memcpy(buf[2], val, len);
+
+ ret = i2c_transfer(priv-i2c, msg, 1);
+ if (ret == 1) {
+ ret = 0;
+ } else {
+ warn(i2c wr failed=%d reg=%02x len=%d, ret, reg, len);
+ ret = -EREMOTEIO;
+ }
+
+ return ret;
+}
+
+/* read multiple registers */
+static int hd29l2_rd_regs(struct hd29l2_priv *priv, u8 reg, u8 *val, int len)
+{
+ int ret;
+ u8 buf[2] = { 0x00, reg };
+ struct i2c_msg msg[2] = {
+ {
+ .addr = priv-cfg.i2c_addr,
+ .flags = 0,
+ .len = 2,
+ .buf = buf,
+ }, {
+ .addr = priv-cfg.i2c_addr,
+ .flags = I2C_M_RD,
+ .len = len,
+ .buf = val,
+ }
+ };
+
+
Re: Anysee E30 S2 plus
On 12/20/2011 02:10 PM, Jesper Krogh wrote: Ok. I had my doubts on whether to include that or not - But here it is /Jesper [ 1056.137882] DVB: registering new adapter (Anysee DVB USB2.0) [ 1056.141938] anysee: firmware version:1.3 hardware id:11 [ 1056.145212] Invalid probe, probably not a CX24116 device [ 1056.145231] anysee: Unsupported Anysee version. Please report the linux-media@vger.kernel.org. Check your power supply is connected. It do same here without power supply since demod is powered using external power supply. If not then it is most likely firmware issue. I have very old firmware, maybe one of the first devel versions. 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: [GIT PULL FOR 3.3] HDIC HD29L2 DMB-TH demodulator driver
On 20-12-2011 12:52, Antti Palosaari wrote:
On 12/20/2011 03:39 PM, Mauro Carvalho Chehab wrote:
+
+/* ensure modulation validy */
+/* 0=QAM4_NR, 1=QAM4, 2=QAM16, 3=QAM32, 4=QAM64 */
+if (modulation 4) {
Please, don't use magic values.
Instead, it should be something like:
ARRAY_SIZE(reg_mod_vals_tab[0].val)
?
Why 4 and not 8 (or whatever)? You're using 4 to avoid a buffer
overflow on your table. As such, please explicitly code it with
ARRAY_SIZE, instead of using a 4 magic number.
Still, I don't understand why modulation should be QAM64 when the
auto_mode is disabled. Shouldn't it be provided via a DVB property?
API does not support DMB-TH params. See my earlier comment.
Ok, add support for it then ;)
+break;
+case 1: /* QAM4 */
+str_constellation = QAM4;
+c-modulation = QPSK; /* FIXME */
QPSK and QAM4 are two names for the same encoding.
I wasn't 100% sure if those are same or not, thats why added comment.
Maybe we should add #define QAM4 QPSK to API since QAM4 is much more commonly
used.
I think QPSK is seen mostly when dealing with DVB-T.
I would just add a comment at the frontends.h file. Otherwise, we would need
to replace it on every place.
+break;
+case 2:
+str_constellation = QAM16;
+c-modulation = QAM_16;
+break;
+case 3:
+str_constellation = QAM32;
+c-modulation = QAM_32;
+break;
+case 4:
+str_constellation = QAM64;
+c-modulation = QAM_64;
+break;
Please, avoid magic numbers. Instead, use macros for each
value.
I disagree that. Those numbers are coming from demodulator
register value. Same way is used almost every driver that
supports reading current transmission params from the demod.
There are drivers that don't code it well, but it is always preferred
to use macros for register values. Good drivers have it.
Again, don't abuse over the API. Instead, add the proper guard
intervals into it.
API issue again. I did that because DMB-TH was not supported.
Anyhow, I would like to ask why you even mention those as those are commented
clearly to be not correctly?
That is very commonly used method of our demod drivers. Look all existing
DMB-TH drivers and you can see same.
The other DMB drivers are ugly and only support whatever they call auto.
I won't doubt that they implement only a subset of the existing
modulations, FEC's, etc.
I wouldn't be surprised if they only support whatever someone
discovered from sniffing the i2c traffic.
+/* reset demod */
+/* it is recommended to HW reset chip using RST_N pin */
+if (fe-callback) {
+ret = fe-callback(fe, 0, 0, 0);
This looks weird on my eyes. The fe-callback is tuner-dependent.
So, the command you should use there requires a test for the tuner
type.
In other words, if you're needing to use it, the code should be doing
something similar to:
if (fe-callback priv-tuner_type == TUNER_XC2028)
ret = fe-callback(fe, 0, XC2028_TUNER_RESET, 0);
(the actual coding will depend on how do you store the tuner type, and
what are the commands for the tuner you're using)
That's said, it probably makes sense to deprecate fe-callback in favor
or a more generic set of callbacks, like fe-tuner_reset().
Yes it is wrong because there was no DEMOD defined. But, the callback
itself is correctly. IIRC there was only TUNER defined and no DEMOD.
Look callback definition from the API. It is very simply to fix. But at
the time left it like that, because I wanted to avoid touching one file
more. I will fix it properly later (2 line change).
And it was not a bug, it was just my known decision. I just forget to comment
it as FIXME or TODO.
Feel free to touch on other files, provided that you fix that. There's
no default behavior for fe-callback, as it were written in order to
provide ways for the tuner to call the bridge driver for some device-specific
reasons. So, the commands are defined with macros, and the callback code
should be device-specific.
After all as I see there is no big bugs. Those findings are mostly related
of missing DMB-TH API support (and was even commented clearly). And 1-2
CodingStyle issues.
One issue is pure CodingStyle. The other no-API related aren't.
As there is still few other DMB-TH drivers having similar issues already in
the master I don't see why not to add that too. Anyhow, if you see that must
be put to staging until DMB-TH is defined to API it is OK for me.
Please fix the non-API related issues. If you ack to provide us the API
improvements
for DMB for 3.4, and get rid of auto_mode = true for all cases, I'm
ok on merging it after the fixes at drivers/media/dvb.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Tuesday 20 December 2011, Sakari Ailus wrote:
(I'm jumping into the discussion in the middle, and might miss something
that has already been talked about. I still hope what I'm about to say is
relevant. :-))
It certainly is relevant.
In subsystems such as V4L2 where drivers deal with such large buffers, the
buffers stay mapped all the time. The user explicitly gives the control of
the buffers to the driver and eventually gets them back. This is already
part of those APIs, whether they're using dma_buf or not. The user could
have, and often has, the same buffers mapped elsewhere.
Do you normally use streaming (dma_{map,sync,unmap}_*) or consistent
(dma_{alloc,free}_*) mappings for this then?
When it comes to passing these buffers between different hardware devices,
either V4L2 or not, the user might not want to perform extra cache flush
when the buffer memory itself is not being touched by the CPU in the process
at all. I'd consider it impossible for the driver to know how the user space
intends to user the buffer.
The easiest solution to this problem would be to only allow consistent mappings
to be shared using the dma_buf mechanism. That means we never have to flush.
If you don't need the CPU to touch the buffer, that would not have any cost
at all, we could even have no kernel mapping at all instead of an uncached
mapping on ARM.
Flushing the cache is quite expensive: typically it's the best to flush the
whole data cache when one needs to flush buffers. The V4L2 DQBUF and QBUF
IOCTLs already have flags to suggest special cache handling for buffers.
[sidenote: whether it makes sense to flush individual cache lines or the entire
cache is a decision best left to the architectures. On systems with larger
caches than on ARM, e.g. 64MB instead of 512KB, you really want to keep
the cache intact.]
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: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Monday 19 December 2011, Semwal, Sumit wrote: I didn't see a consensus on whether dma_buf should enforce some form of serialization within the API - so atleast for v1 of dma-buf, I propose to 'not' impose a restriction, and we can tackle it (add new ops or enforce as design?) whenever we see the first need of it - will that be ok? [I am bending towards the thought that it is a problem to solve at a bigger platform than dma_buf.] The problem is generally understood for streaming mappings with a single device using it: if you have a long-running mapping, you have to use dma_sync_*. This obviously falls apart if you have multiple devices and no serialization between the accesses. If you don't want serialization, that implies that we cannot have use the dma_sync_* API on the buffer, which in turn implies that we cannot have streaming mappings. I think that's ok, but then you have to bring back the mmap API on the buffer if you want to allow any driver to provide an mmap function for a shared buffer. 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: [GIT PULL FOR 3.3] HDIC HD29L2 DMB-TH demodulator driver
On 12/20/2011 05:26 PM, Mauro Carvalho Chehab wrote:
On 20-12-2011 12:52, Antti Palosaari wrote:
On 12/20/2011 03:39 PM, Mauro Carvalho Chehab wrote:
+break;
+case 2:
+str_constellation = QAM16;
+c-modulation = QAM_16;
+break;
+case 3:
+str_constellation = QAM32;
+c-modulation = QAM_32;
+break;
+case 4:
+str_constellation = QAM64;
+c-modulation = QAM_64;
+break;
Please, avoid magic numbers. Instead, use macros for each
value.
I disagree that. Those numbers are coming from demodulator
register value. Same way is used almost every driver that
supports reading current transmission params from the demod.
There are drivers that don't code it well, but it is always preferred
to use macros for register values. Good drivers have it.
I still disagree. Are we speaking same issue?
val = read_reg(rgister)
switch (val) {
case 2:
c-modulation = QAM_16;
break;
case 3:
c-modulation = QAM_32;
break;
}
Why I should define macros here?
Or do you mean I should define macros for the selecting correct bits
from the register?
Anyhow, for me that piece of code looks very clear. And it is used
similarly very many drivers.
After all as I see there is no big bugs. Those findings are mostly related
of missing DMB-TH API support (and was even commented clearly). And 1-2
CodingStyle issues.
One issue is pure CodingStyle. The other no-API related aren't.
As there is still few other DMB-TH drivers having similar issues already in
the master I don't see why not to add that too. Anyhow, if you see that must
be put to staging until DMB-TH is defined to API it is OK for me.
Please fix the non-API related issues. If you ack to provide us the API
improvements
for DMB for 3.4, and get rid of auto_mode = true for all cases, I'm
ok on merging it after the fixes at drivers/media/dvb.
If I don't add DMB-TH support to API you will push that to the staging?
Adding those to API is not mission impossible. Interleaver is only new
parameter and all the rest are just extending values. But my time is
limited... and I really would like to finally got Anysee smart card
reader integrated to USB serial first.
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: [GIT PULL FOR 3.3] HDIC HD29L2 DMB-TH demodulator driver
Hi all, On Tuesday 20 December 2011 16:42:53 Antti Palosaari wrote: Adding those to API is not mission impossible. Interleaver is only new parameter and all the rest are just extending values. But my time is limited... and I really would like to finally got Anysee smart card reader integrated to USB serial first. And if it is added we should not forget to discuess whether DMB-TH is the right name. (If this has already been addressed in another thread please point me to it). I know this standard under at least 2 different names: CTTB and DTMB. Which is the one to choose? best regards, -- Patrick Kernel Labs Inc. 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: [RFC v3 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote: This is the first step in defining a dma buffer sharing mechanism. A new buffer object dma_buf is added, with operations and API to allow easy sharing of this buffer object across devices. The framework allows: - different devices to 'attach' themselves to this buffer, to facilitate backing storage negotiation, using dma_buf_attach() API. Any thoughts of adding facility to track them? So you can see who is using what? - association of a file pointer with each user-buffer and associated allocator-defined operations on that buffer. This operation is called the 'export' operation. 'create'? or 'alloc' ? export implies an import somwhere and I don't think that is the case here. - this exported buffer-object to be shared with the other entity by asking for its 'file-descriptor (fd)', and sharing the fd across. - a received fd to get the buffer object back, where it can be accessed using the associated exporter-defined operations. - the exporter and user to share the scatterlist using map_dma_buf and unmap_dma_buf operations. Atleast one 'attach()' call is required to be made prior to calling the map_dma_buf() operation. for the whole memory region or just for the device itself? Couple of building blocks in map_dma_buf() are added to ease introduction of sync'ing across exporter and users, and late allocation by the exporter. More details are there in the documentation patch. This is based on design suggestions from many people at the mini-summits[1], most notably from Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and Daniel Vetter dan...@ffwll.ch. The implementation is inspired from proof-of-concept patch-set from Tomasz Stanislawski t.stanisl...@samsung.com, who demonstrated buffer sharing between two v4l2 devices. [2] [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement [2]: http://lwn.net/Articles/454389 Signed-off-by: Sumit Semwal sumit.sem...@linaro.org Signed-off-by: Sumit Semwal sumit.sem...@ti.com --- drivers/base/Kconfig| 10 ++ drivers/base/Makefile |1 + drivers/base/dma-buf.c | 289 +++ include/linux/dma-buf.h | 172 4 files changed, 472 insertions(+), 0 deletions(-) create mode 100644 drivers/base/dma-buf.c create mode 100644 include/linux/dma-buf.h diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index 21cf46f..8a0e87f 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -174,4 +174,14 @@ config SYS_HYPERVISOR source drivers/base/regmap/Kconfig +config DMA_SHARED_BUFFER + bool Buffer framework to be shared between drivers + default n + select ANON_INODES + help + This option enables the framework for buffer-sharing between + multiple drivers. A buffer is associated with a file using driver + APIs extension; the file's descriptor can then be passed on to other + driver. + endmenu diff --git a/drivers/base/Makefile b/drivers/base/Makefile index 99a375a..d0df046 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -8,6 +8,7 @@ obj-$(CONFIG_DEVTMPFS)+= devtmpfs.o obj-y+= power/ obj-$(CONFIG_HAS_DMA)+= dma-mapping.o obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o +obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o obj-$(CONFIG_ISA)+= isa.o obj-$(CONFIG_FW_LOADER) += firmware_class.o obj-$(CONFIG_NUMA) += node.o diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c new file mode 100644 index 000..e920709 --- /dev/null +++ b/drivers/base/dma-buf.c @@ -0,0 +1,289 @@ +/* + * Framework for buffer objects that can be shared across devices/subsystems. + * + * Copyright(C) 2011 Linaro Limited. All rights reserved. + * Author: Sumit Semwal sumit.sem...@ti.com + * + * Many thanks to linaro-mm-sig list, and specially + * Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and + * Daniel Vetter dan...@ffwll.ch for their support in creation and + * refining of this idea. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published by + * the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + * + * You should have received a copy of the GNU General Public License along with + * this program. If not, see http://www.gnu.org/licenses/. + */ + +#include linux/fs.h +#include linux/slab.h +#include linux/dma-buf.h +#include linux/anon_inodes.h +#include linux/export.h + +static inline int is_dma_buf_file(struct file *); + +static int
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Tue, Dec 20, 2011 at 9:41 AM, Arnd Bergmann a...@arndb.de wrote: On Monday 19 December 2011, Semwal, Sumit wrote: I didn't see a consensus on whether dma_buf should enforce some form of serialization within the API - so atleast for v1 of dma-buf, I propose to 'not' impose a restriction, and we can tackle it (add new ops or enforce as design?) whenever we see the first need of it - will that be ok? [I am bending towards the thought that it is a problem to solve at a bigger platform than dma_buf.] The problem is generally understood for streaming mappings with a single device using it: if you have a long-running mapping, you have to use dma_sync_*. This obviously falls apart if you have multiple devices and no serialization between the accesses. If you don't want serialization, that implies that we cannot have use the dma_sync_* API on the buffer, which in turn implies that we cannot have streaming mappings. I think that's ok, but then you have to bring back the mmap API on the buffer if you want to allow any driver to provide an mmap function for a shared buffer. I'm thinking for a first version, we can get enough mileage out of it by saying: 1) only exporter can mmap to userspace 2) only importers that do not need CPU access to buffer.. This way we can get dmabuf into the kernel, maybe even for 3.3. I know there are a lot of interesting potential uses where this stripped down version is good enough. It probably isn't the final version, maybe more features are added over time to deal with importers that need CPU access to buffer, sync object, etc. But we have to start somewhere. BR, -R 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 -- 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 v3 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Tue, Dec 20, 2011 at 10:36 AM, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Mon, Dec 19, 2011 at 02:03:30PM +0530, Sumit Semwal wrote: This is the first step in defining a dma buffer sharing mechanism. A new buffer object dma_buf is added, with operations and API to allow easy sharing of this buffer object across devices. The framework allows: - different devices to 'attach' themselves to this buffer, to facilitate backing storage negotiation, using dma_buf_attach() API. Any thoughts of adding facility to track them? So you can see who is using what? - association of a file pointer with each user-buffer and associated allocator-defined operations on that buffer. This operation is called the 'export' operation. 'create'? or 'alloc' ? export implies an import somwhere and I don't think that is the case here. Well, the import is the attach/map stuff. The userspace facing export ioctl would call dma_buf_export().. the userspace facing import ioctl of the importing device would call dma_buf_attach/map(). Perhaps the language should be a create dma buf API used by the exporting driver. I guess the dmabuf is being created, the backing memory/pages are being exported. - this exported buffer-object to be shared with the other entity by asking for its 'file-descriptor (fd)', and sharing the fd across. - a received fd to get the buffer object back, where it can be accessed using the associated exporter-defined operations. - the exporter and user to share the scatterlist using map_dma_buf and unmap_dma_buf operations. Atleast one 'attach()' call is required to be made prior to calling the map_dma_buf() operation. for the whole memory region or just for the device itself? Attach should be called per buffer. It is basically registering intent of the importing device to user the buffer 1 or more times. Detach is letting the exporter know that the importer won't be using the buffer again (at least for a while). For example: attach() map() // buffer is backed and pinned do dma to/from buffer unmap() // exporter could mark the buffer evictable here map() // buffer is pinned do dma to/from buffer unmap() ... detach() Also, in case of multiple importers, the exporter could also wait to allocate backing pages until first map() in case one of the importers has stricter memory requirements (physically contiguous, certain memory range, etc) than the others. Some exporters, like v4l, might have some restrictions about the buffer being backed/pinned earlier, for those attach() might be basically a no-op. But the idea is to give exporters that are a bit more dynamic w/ memory management some flexibility. BR, -R Couple of building blocks in map_dma_buf() are added to ease introduction of sync'ing across exporter and users, and late allocation by the exporter. More details are there in the documentation patch. This is based on design suggestions from many people at the mini-summits[1], most notably from Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and Daniel Vetter dan...@ffwll.ch. The implementation is inspired from proof-of-concept patch-set from Tomasz Stanislawski t.stanisl...@samsung.com, who demonstrated buffer sharing between two v4l2 devices. [2] [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement [2]: http://lwn.net/Articles/454389 Signed-off-by: Sumit Semwal sumit.sem...@linaro.org Signed-off-by: Sumit Semwal sumit.sem...@ti.com --- drivers/base/Kconfig | 10 ++ drivers/base/Makefile | 1 + drivers/base/dma-buf.c | 289 +++ include/linux/dma-buf.h | 172 4 files changed, 472 insertions(+), 0 deletions(-) create mode 100644 drivers/base/dma-buf.c create mode 100644 include/linux/dma-buf.h diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig index 21cf46f..8a0e87f 100644 --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -174,4 +174,14 @@ config SYS_HYPERVISOR source drivers/base/regmap/Kconfig +config DMA_SHARED_BUFFER + bool Buffer framework to be shared between drivers + default n + select ANON_INODES + help + This option enables the framework for buffer-sharing between + multiple drivers. A buffer is associated with a file using driver + APIs extension; the file's descriptor can then be passed on to other + driver. + endmenu diff --git a/drivers/base/Makefile b/drivers/base/Makefile index 99a375a..d0df046 100644 --- a/drivers/base/Makefile +++ b/drivers/base/Makefile @@ -8,6 +8,7 @@ obj-$(CONFIG_DEVTMPFS) += devtmpfs.o obj-y += power/ obj-$(CONFIG_HAS_DMA) += dma-mapping.o obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o +obj-$(CONFIG_DMA_SHARED_BUFFER) += dma-buf.o obj-$(CONFIG_ISA) += isa.o obj-$(CONFIG_FW_LOADER) += firmware_class.o
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Tue, Dec 20, 2011 at 10:41:45AM -0600, Rob Clark wrote: On Tue, Dec 20, 2011 at 9:41 AM, Arnd Bergmann a...@arndb.de wrote: On Monday 19 December 2011, Semwal, Sumit wrote: I didn't see a consensus on whether dma_buf should enforce some form of serialization within the API - so atleast for v1 of dma-buf, I propose to 'not' impose a restriction, and we can tackle it (add new ops or enforce as design?) whenever we see the first need of it - will that be ok? [I am bending towards the thought that it is a problem to solve at a bigger platform than dma_buf.] The problem is generally understood for streaming mappings with a single device using it: if you have a long-running mapping, you have to use dma_sync_*. This obviously falls apart if you have multiple devices and no serialization between the accesses. If you don't want serialization, that implies that we cannot have use the dma_sync_* API on the buffer, which in turn implies that we cannot have streaming mappings. I think that's ok, but then you have to bring back the mmap API on the buffer if you want to allow any driver to provide an mmap function for a shared buffer. I'm thinking for a first version, we can get enough mileage out of it by saying: 1) only exporter can mmap to userspace 2) only importers that do not need CPU access to buffer.. This way we can get dmabuf into the kernel, maybe even for 3.3. I know there are a lot of interesting potential uses where this stripped down version is good enough. It probably isn't the final version, maybe more features are added over time to deal with importers that need CPU access to buffer, sync object, etc. But we have to start somewhere. I agree with Rob here - I think especially for the coherency discussion some actual users of dma_buf on a bunch of insane platforms (i915 qualifies here too, because we do some cacheline flushing behind everyones back) would massively help in clarifying things. It also sounds like that at least for proper userspace mmap support we'd need some dma api extensions on at least arm, and that might take a while ... Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL FOR 3.3] HDIC HD29L2 DMB-TH demodulator driv
On 12/20/2011 06:25 PM, Patrick Boettcher wrote: Hi all, On Tuesday 20 December 2011 16:42:53 Antti Palosaari wrote: Adding those to API is not mission impossible. Interleaver is only new parameter and all the rest are just extending values. But my time is limited... and I really would like to finally got Anysee smart card reader integrated to USB serial first. And if it is added we should not forget to discuess whether DMB-TH is the right name. (If this has already been addressed in another thread please point me to it). I know this standard under at least 2 different names: CTTB and DTMB. Which is the one to choose? Yes, there is many names and it is not even clear for me what are differences between names. I called it DMB-TH since existing Kernel drivers have selected that name. http://en.wikipedia.org/wiki/CMMB http://en.wikipedia.org/wiki/DTMB http://en.wikipedia.org/wiki/Digital_Multimedia_Broadcasting http://en.wikipedia.org/wiki/Digital_Terrestrial_Multimedia_Broadcast CMMB CTTB DTMB (DTMB-T/H, DMB-T/H) DMB (T-DMB) 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: [GIT PULL FOR 3.3] HDIC HD29L2 DMB-TH demodulator driv
On 12/20/2011 07:16 PM, Antti Palosaari wrote: On 12/20/2011 06:25 PM, Patrick Boettcher wrote: Hi all, On Tuesday 20 December 2011 16:42:53 Antti Palosaari wrote: Adding those to API is not mission impossible. Interleaver is only new parameter and all the rest are just extending values. But my time is limited... and I really would like to finally got Anysee smart card reader integrated to USB serial first. And if it is added we should not forget to discuess whether DMB-TH is the right name. (If this has already been addressed in another thread please point me to it). I know this standard under at least 2 different names: CTTB and DTMB. Which is the one to choose? Yes, there is many names and it is not even clear for me what are differences between names. I called it DMB-TH since existing Kernel drivers have selected that name. http://en.wikipedia.org/wiki/CMMB http://en.wikipedia.org/wiki/DTMB http://en.wikipedia.org/wiki/Digital_Multimedia_Broadcasting http://en.wikipedia.org/wiki/Digital_Terrestrial_Multimedia_Broadcast CMMB CTTB DTMB (DTMB-T/H, DMB-T/H) DMB (T-DMB) DMB seems to be much different so drop it out. DTMB seems to be official term for DMB-T/H. CMMB seems to be for small devices (mobile), maybe subset of DTMB. Finally I have CTTB and DTMB which seems to be equivalents. DTMB is more common. So I end up for the DTMB. I give my vote for that. 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: [GIT PULL FOR 3.3] HDIC HD29L2 DMB-TH demodulator driv
On 20-12-2011 16:01, Antti Palosaari wrote: On 12/20/2011 07:16 PM, Antti Palosaari wrote: On 12/20/2011 06:25 PM, Patrick Boettcher wrote: Hi all, On Tuesday 20 December 2011 16:42:53 Antti Palosaari wrote: Adding those to API is not mission impossible. Interleaver is only new parameter and all the rest are just extending values. But my time is limited... and I really would like to finally got Anysee smart card reader integrated to USB serial first. And if it is added we should not forget to discuess whether DMB-TH is the right name. (If this has already been addressed in another thread please point me to it). I know this standard under at least 2 different names: CTTB and DTMB. Which is the one to choose? Yes, there is many names and it is not even clear for me what are differences between names. I called it DMB-TH since existing Kernel drivers have selected that name. http://en.wikipedia.org/wiki/CMMB http://en.wikipedia.org/wiki/DTMB http://en.wikipedia.org/wiki/Digital_Multimedia_Broadcasting http://en.wikipedia.org/wiki/Digital_Terrestrial_Multimedia_Broadcast CMMB CTTB DTMB (DTMB-T/H, DMB-T/H) DMB (T-DMB) DMB seems to be much different so drop it out. DTMB seems to be official term for DMB-T/H. CMMB seems to be for small devices (mobile), maybe subset of DTMB. Finally I have CTTB and DTMB which seems to be equivalents. DTMB is more common. So I end up for the DTMB. I give my vote for that. I also vote for DTMB. It seems to be the more adequate one. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Tue Dec 20 19:00:43 CET 2011 git hash:875e2e3edf48a206c64195666cf408dd3d119137 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: 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-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2-rc1-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 linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2-rc1-x86_64: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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
[GIT PULL] VideoBuf2 fixes for v3.3
Hello Mauro, Please pull our fixes for videobuf2 framework into your for_v3.3 development branch. Best regards, Marek Szyprowski Samsung Poland RD Center The following changes since commit bcc072756e4467dc30e502a311b1c3adec96a0e4: [media] STV0900: Query DVB frontend delivery capabilities (2011-12-12 15:04:34 -0200) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung vb2-fixes Andrzej Pietrasiewicz (1): media: vb2: vmalloc-based allocator user pointer handling Marek Szyprowski (4): media: vb2: fix queueing of userptr buffers with null buffer pointer media: vb2: fix potential deadlock in mmap vs. get_userptr handling media: vb2: remove plane argument from call_memop and cleanup mempriv usage media: vb2: review mem_priv usage and fix potential bugs drivers/media/video/videobuf2-core.c| 118 +++ drivers/media/video/videobuf2-dma-sg.c |3 +- drivers/media/video/videobuf2-memops.c | 28 +++- drivers/media/video/videobuf2-vmalloc.c | 90 --- 4 files changed, 161 insertions(+), 78 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v3 0/2] Introduce DMA buffer sharing mechanism
On Mon, Dec 19, 2011 at 02:03:28PM +0530, Sumit Semwal wrote: Hello Everyone, This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the changelog below. Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the need to have a common mechanism to share memory buffers across different devices - ARM, video hardware, GPU. This need comes forth from a variety of use cases including cameras, image processing, video recorders, sound processing, DMA engines, GPU and display buffers, and others. This RFC is an attempt to define such a buffer sharing mechanism- it is the result of discussions from a couple of memory-management mini-summits held by Linaro to understand and address common needs around memory management. [1] A new dma_buf buffer object is added, with operations and API to allow easy sharing of this buffer object across devices. The framework allows: - a new buffer-object to be created with fixed size. - different devices to 'attach' themselves to this buffer, to facilitate backing storage negotiation, using dma_buf_attach() API. - association of a file pointer with each user-buffer and associated allocator-defined operations on that buffer. This operation is called the 'export' operation. - this exported buffer-object to be shared with the other entity by asking for its 'file-descriptor (fd)', and sharing the fd across. - a received fd to get the buffer object back, where it can be accessed using the associated exporter-defined operations. - the exporter and user to share the scatterlist using map_dma_buf and unmap_dma_buf operations. Documentation present in the patch-set gives more details. This is based on design suggestions from many people at the mini-summits, most notably from Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and Daniel Vetter dan...@ffwll.ch. The implementation is inspired from proof-of-concept patch-set from Tomasz Stanislawski t.stanisl...@samsung.com, who demonstrated buffer sharing between two v4l2 devices. [2] References: [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement [2]: http://lwn.net/Articles/454389 Patchset based on top of 3.2-rc3, the current version can be found at http://git.linaro.org/gitweb?p=people/sumitsemwal/linux-3.x.git Branch: dma-buf-upstr-v2 Earlier versions: v2 at: https://lkml.org/lkml/2011/12/2/53 v1 at: https://lkml.org/lkml/2011/10/11/92 Best regards, ~Sumit Semwal I think this is a really good v1 version of dma_buf. It contains all the required bits (with well-specified semantics in the doc patch) to implement some basic use-cases and start fleshing out the integration with various subsystem (like drm and v4l). All the things still under discussion like - userspace mmap support - more advanced (and more strictly specified) coherency models - and shared infrastructure for implementing exporters are imo much clearer once we have a few example drivers at hand and a better understanding of some of the insane corner cases we need to be able to handle. And I think any risk that the resulting clarifications will break a basic use-case is really minimal, so I think it'd be great if this could go into 3.3 (maybe as some kind of staging/experimental infrastructure). Hence for both patches: Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- 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] [RFC v3 0/2] Introduce DMA buffer sharing mechanism
This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the changelog below. Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the need to have a common mechanism to share memory buffers across different devices - ARM, video hardware, GPU. This need comes forth from a variety of use cases including cameras, image processing, video recorders, sound processing, DMA engines, GPU and display buffers, and others. This RFC is an attempt to define such a buffer sharing mechanism- it is the result of discussions from a couple of memory-management mini-summits held by Linaro to understand and address common needs around memory management. [1] A new dma_buf buffer object is added, with operations and API to allow easy sharing of this buffer object across devices. The framework allows: - a new buffer-object to be created with fixed size. - different devices to 'attach' themselves to this buffer, to facilitate backing storage negotiation, using dma_buf_attach() API. - association of a file pointer with each user-buffer and associated allocator-defined operations on that buffer. This operation is called the 'export' operation. - this exported buffer-object to be shared with the other entity by asking for its 'file-descriptor (fd)', and sharing the fd across. - a received fd to get the buffer object back, where it can be accessed using the associated exporter-defined operations. - the exporter and user to share the scatterlist using map_dma_buf and unmap_dma_buf operations. Documentation present in the patch-set gives more details. This is based on design suggestions from many people at the mini-summits, most notably from Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and Daniel Vetter dan...@ffwll.ch. The implementation is inspired from proof-of-concept patch-set from Tomasz Stanislawski t.stanisl...@samsung.com, who demonstrated buffer sharing between two v4l2 devices. [2] References: [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement [2]: http://lwn.net/Articles/454389 Patchset based on top of 3.2-rc3, the current version can be found at http://git.linaro.org/gitweb?p=people/sumitsemwal/linux-3.x.git Branch: dma-buf-upstr-v2 Earlier versions: v2 at: https://lkml.org/lkml/2011/12/2/53 v1 at: https://lkml.org/lkml/2011/10/11/92 Best regards, ~Sumit Semwal I think this is a really good v1 version of dma_buf. It contains all the required bits (with well-specified semantics in the doc patch) to implement some basic use-cases and start fleshing out the integration with various subsystem (like drm and v4l). All the things still under discussion like - userspace mmap support - more advanced (and more strictly specified) coherency models - and shared infrastructure for implementing exporters are imo much clearer once we have a few example drivers at hand and a better understanding of some of the insane corner cases we need to be able to handle. And I think any risk that the resulting clarifications will break a basic use-case is really minimal, so I think it'd be great if this could go into 3.3 (maybe as some kind of staging/experimental infrastructure). Hence for both patches: Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Yeah I'm with Daniel, I like this one, I can definitely build the drm buffer sharing layer on top of this. How do we see this getting merged? I'm quite happy to push it to Linus if we don't have an identified path, though it could go via a Linaro tree as well. so feel free to add: Reviewed-by: Dave Airlie airl...@redhat.com Dave. -- 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 0/17] V4L2 subdev and sensor control changes, SMIA++ driver and N9 camera board code
Hi everyone, This patchset contains new versions of a couple of previous patchsets I've sent to the list recently. There are mostly minor changes to many existing patches based on the comments I've got so far, so I'm resending them. The list is here: - Integer menu controls [2], - Selection IOCTL for subdevs [3], - Sensor control changes [5], - validate_pipeline() V4L2 subdev pad op, - OMAP 3 ISP driver improvements [4], - SMIA++ sensor driver and - rm680/rm696 board code (a.k.a Nokia N9 and N950) More detailed information can be found in the references. I'm still sending the set as RFC since it contains many patches which I would like to get more comments on, especially the changes related to V4L2. This patchset depends on Aaro Koskinen's N9 patchset [1] to actually function at least on the N9. That, to my understanding, is on its way to mainline. Comments and questions are very, very welcome. References: [1] http://www.spinics.net/lists/linux-omap/msg61295.html [2] http://www.spinics.net/lists/linux-media/msg40796.html [3] http://www.spinics.net/lists/linux-media/msg41503.html [4] http://www.spinics.net/lists/linux-media/msg41542.html [5] http://www.spinics.net/lists/linux-media/msg40861.html Kind regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
[RFC 02/17] v4l: Document integer menu controls
From: Sakari Ailus sakari.ai...@iki.fi Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- Documentation/DocBook/media/v4l/compat.xml | 10 + Documentation/DocBook/media/v4l/v4l2.xml |7 .../DocBook/media/v4l/vidioc-queryctrl.xml | 39 +++- 3 files changed, 54 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index b68698f..569efd1 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2379,6 +2379,16 @@ that used it. It was originally scheduled for removal in 2.6.35. /orderedlist /section +section + titleV4L2 in Linux 3.3/title + orderedlist +listitem + paraAdded integer menus, the new type will be + V4L2_CTRL_TYPE_INTEGER_MENU./para +/listitem + /orderedlist +/section + section id=other titleRelation of V4L2 to other Linux multimedia APIs/title diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 2ab365c..affe1ba 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -128,6 +128,13 @@ structs, ioctls) must be noted in more detail in the history chapter applications. -- revision + revnumber3.3/revnumber + date2011-11-24/date + authorinitialssa/authorinitials + revremarkAdded V4L2_CTRL_TYPE_INTEGER_MENU./revremark + /revision + + revision revnumber3.2/revnumber date2011-08-26/date authorinitialshv/authorinitials diff --git a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml index 0ac0057..02064b0 100644 --- a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml +++ b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml @@ -215,11 +215,12 @@ the array to zero./entry table pgwide=1 frame=none id=v4l2-querymenu titlestruct structnamev4l2_querymenu/structname/title - tgroup cols=3 + tgroup cols=4 cs-str; tbody valign=top row entry__u32/entry + entry/entry entrystructfieldid/structfield/entry entryIdentifies the control, set by the application from the respective v4l2-queryctrl; @@ -227,18 +228,38 @@ from the respective v4l2-queryctrl; /row row entry__u32/entry + entry/entry entrystructfieldindex/structfield/entry entryIndex of the menu item, starting at zero, set by the application./entry /row row + entryunion/entry + entry/entry + entry/entry + entry/entry + /row + row + entry/entry entry__u8/entry entrystructfieldname/structfield[32]/entry entryName of the menu item, a NUL-terminated ASCII -string. This information is intended for the user./entry +string. This information is intended for the user. This field is valid +for constantV4L2_CTRL_FLAG_MENU/constant type controls./entry + /row + row + entry/entry + entry__s64/entry + entrystructfieldvalue/structfield/entry + entry + Value of the integer menu item. This field is valid for + constantV4L2_CTRL_FLAG_INTEGER_MENU/constant type + controls. +/entry /row row entry__u32/entry + entry/entry entrystructfieldreserved/structfield/entry entryReserved for future extensions. Drivers must set the array to zero./entry @@ -292,6 +313,20 @@ the menu items can be enumerated with the constantVIDIOC_QUERYMENU/constant ioctl./entry /row row + entryconstantV4L2_CTRL_TYPE_INTEGER_MENU/constant/entry + entryge; 0/entry + entry1/entry + entryN-1/entry + entry + The control has a menu of N choices. The values of the + menu items can be enumerated with the + constantVIDIOC_QUERYMENU/constant ioctl. This is + similar to constantV4L2_CTRL_TYPE_MENU/constant + except that instead of strings, the menu items are + signed 64-bit integers. +/entry + /row + row entryconstantV4L2_CTRL_TYPE_BITMASK/constant/entry entry0/entry entryn/a/entry -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 01/17] v4l: Introduce integer menu controls
From: Sakari Ailus sakari.ai...@iki.fi
Create a new control type called V4L2_CTRL_TYPE_INTEGER_MENU. Integer menu
controls are just like menu controls but the menu items are 64-bit integers
rather than strings.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/v4l2-ctrls.c | 60 +++--
include/linux/videodev2.h|6 +++-
include/media/v4l2-ctrls.h |6 +++-
3 files changed, 54 insertions(+), 18 deletions(-)
diff --git a/drivers/media/video/v4l2-ctrls.c b/drivers/media/video/v4l2-ctrls.c
index 0f415da..083bb79 100644
--- a/drivers/media/video/v4l2-ctrls.c
+++ b/drivers/media/video/v4l2-ctrls.c
@@ -804,7 +804,8 @@ static void fill_event(struct v4l2_event *ev, struct
v4l2_ctrl *ctrl, u32 change
ev-u.ctrl.value64 = ctrl-cur.val64;
ev-u.ctrl.minimum = ctrl-minimum;
ev-u.ctrl.maximum = ctrl-maximum;
- if (ctrl-type == V4L2_CTRL_TYPE_MENU)
+ if (ctrl-type == V4L2_CTRL_TYPE_MENU
+ || ctrl-type == V4L2_CTRL_TYPE_INTEGER_MENU)
ev-u.ctrl.step = 1;
else
ev-u.ctrl.step = ctrl-step;
@@ -1035,10 +1036,13 @@ static int validate_new_int(const struct v4l2_ctrl
*ctrl, s32 *pval)
return 0;
case V4L2_CTRL_TYPE_MENU:
+ case V4L2_CTRL_TYPE_INTEGER_MENU:
if (val ctrl-minimum || val ctrl-maximum)
return -ERANGE;
- if (ctrl-qmenu[val][0] == '\0' ||
- (ctrl-menu_skip_mask (1 val)))
+ if (ctrl-menu_skip_mask (1 val))
+ return -EINVAL;
+ if (ctrl-type == V4L2_CTRL_TYPE_MENU
+ ctrl-qmenu[val][0] == '\0')
return -EINVAL;
return 0;
@@ -1295,7 +1299,8 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
const struct v4l2_ctrl_ops *ops,
u32 id, const char *name, enum v4l2_ctrl_type type,
s32 min, s32 max, u32 step, s32 def,
- u32 flags, const char * const *qmenu, void *priv)
+ u32 flags, const char * const *qmenu,
+ const s64 *qmenu_int, void *priv)
{
struct v4l2_ctrl *ctrl;
unsigned sz_extra = 0;
@@ -1308,6 +1313,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
(type == V4L2_CTRL_TYPE_INTEGER step == 0) ||
(type == V4L2_CTRL_TYPE_BITMASK max == 0) ||
(type == V4L2_CTRL_TYPE_MENU qmenu == NULL) ||
+ (type == V4L2_CTRL_TYPE_INTEGER_MENU qmenu_int == NULL) ||
(type == V4L2_CTRL_TYPE_STRING max == 0)) {
handler_set_err(hdl, -ERANGE);
return NULL;
@@ -1318,6 +1324,7 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
}
if ((type == V4L2_CTRL_TYPE_INTEGER ||
type == V4L2_CTRL_TYPE_MENU ||
+type == V4L2_CTRL_TYPE_INTEGER_MENU ||
type == V4L2_CTRL_TYPE_BOOLEAN)
(def min || def max)) {
handler_set_err(hdl, -ERANGE);
@@ -1352,7 +1359,10 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
v4l2_ctrl_handler *hdl,
ctrl-minimum = min;
ctrl-maximum = max;
ctrl-step = step;
- ctrl-qmenu = qmenu;
+ if (type == V4L2_CTRL_TYPE_MENU)
+ ctrl-qmenu = qmenu;
+ else if (type == V4L2_CTRL_TYPE_INTEGER_MENU)
+ ctrl-qmenu_int = qmenu_int;
ctrl-priv = priv;
ctrl-cur.val = ctrl-val = ctrl-default_value = def;
@@ -1379,6 +1389,7 @@ struct v4l2_ctrl *v4l2_ctrl_new_custom(struct
v4l2_ctrl_handler *hdl,
struct v4l2_ctrl *ctrl;
const char *name = cfg-name;
const char * const *qmenu = cfg-qmenu;
+ const s64 *qmenu_int = cfg-qmenu_int;
enum v4l2_ctrl_type type = cfg-type;
u32 flags = cfg-flags;
s32 min = cfg-min;
@@ -1390,18 +1401,24 @@ struct v4l2_ctrl *v4l2_ctrl_new_custom(struct
v4l2_ctrl_handler *hdl,
v4l2_ctrl_fill(cfg-id, name, type, min, max, step,
def, flags);
- is_menu = (cfg-type == V4L2_CTRL_TYPE_MENU);
+ is_menu = (cfg-type == V4L2_CTRL_TYPE_MENU ||
+ cfg-type == V4L2_CTRL_TYPE_INTEGER_MENU);
if (is_menu)
WARN_ON(step);
else
WARN_ON(cfg-menu_skip_mask);
- if (is_menu qmenu == NULL)
+ if (cfg-type == V4L2_CTRL_TYPE_MENU qmenu == NULL)
qmenu = v4l2_ctrl_get_menu(cfg-id);
+ else if (cfg-type == V4L2_CTRL_TYPE_INTEGER_MENU
+qmenu_int == NULL) {
+ handler_set_err(hdl, -EINVAL);
+ return NULL;
+ }
ctrl = v4l2_ctrl_new(hdl, cfg-ops, cfg-id, name,
type, min, max,
[RFC 04/17] v4l: VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION IOCTLs
From: Sakari Ailus sakari.ai...@iki.fi
Add support for VIDIOC_SUBDEV_S_SELECTION and VIDIOC_SUBDEV_G_SELECTION
IOCTLs. They replace functionality provided by VIDIOC_SUBDEV_S_CROP and
VIDIOC_SUBDEV_G_CROP IOCTLs and also add new functionality (composing).
VIDIOC_SUBDEV_G_CROP and VIDIOC_SUBDEV_S_CROP continue to be supported.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/v4l2-subdev.c | 26 -
include/linux/v4l2-subdev.h | 45 +
include/media/v4l2-subdev.h |5
3 files changed, 75 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c
index 65ade5f..e8ae098 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -36,13 +36,17 @@ static int subdev_fh_init(struct v4l2_subdev_fh *fh, struct
v4l2_subdev *sd)
{
#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
/* Allocate try format and crop in the same memory block */
- fh-try_fmt = kzalloc((sizeof(*fh-try_fmt) + sizeof(*fh-try_crop))
+ fh-try_fmt = kzalloc((sizeof(*fh-try_fmt) + sizeof(*fh-try_crop)
+ + sizeof(*fh-try_compose))
* sd-entity.num_pads, GFP_KERNEL);
if (fh-try_fmt == NULL)
return -ENOMEM;
fh-try_crop = (struct v4l2_rect *)
(fh-try_fmt + sd-entity.num_pads);
+
+ fh-try_compose = (struct v4l2_rect *)
+ (fh-try_crop + sd-entity.num_pads);
#endif
return 0;
}
@@ -281,6 +285,26 @@ static long subdev_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
return v4l2_subdev_call(sd, pad, enum_frame_interval, subdev_fh,
fie);
}
+
+ case VIDIOC_SUBDEV_G_SELECTION: {
+ struct v4l2_subdev_selection *sel = arg;
+
+ if (sel-pad = sd-entity.num_pads)
+ return -EINVAL;
+
+ return v4l2_subdev_call(
+ sd, pad, get_selection, subdev_fh, sel);
+ }
+
+ case VIDIOC_SUBDEV_S_SELECTION: {
+ struct v4l2_subdev_selection *sel = arg;
+
+ if (sel-pad = sd-entity.num_pads)
+ return -EINVAL;
+
+ return v4l2_subdev_call(
+ sd, pad, set_selection, subdev_fh, sel);
+ }
#endif
default:
return v4l2_subdev_call(sd, core, ioctl, cmd, arg);
diff --git a/include/linux/v4l2-subdev.h b/include/linux/v4l2-subdev.h
index ed29cbb..d53d775 100644
--- a/include/linux/v4l2-subdev.h
+++ b/include/linux/v4l2-subdev.h
@@ -123,6 +123,47 @@ struct v4l2_subdev_frame_interval_enum {
__u32 reserved[9];
};
+#define V4L2_SUBDEV_SEL_FLAG_SIZE_GE (1 0)
+#define V4L2_SUBDEV_SEL_FLAG_SIZE_LE (1 1)
+#define V4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG (1 2)
+
+/* active cropping area */
+#define V4L2_SUBDEV_SEL_TGT_CROP_ACTIVE0
+/* default cropping area */
+#define V4L2_SUBDEV_SEL_TGT_CROP_DEFAULT 1
+/* cropping bounds */
+#define V4L2_SUBDEV_SEL_TGT_CROP_BOUNDS2
+/* current composing area */
+#define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTIVE 256
+/* default composing area */
+#define V4L2_SUBDEV_SEL_TGT_COMPOSE_DEFAULT257
+/* composing bounds */
+#define V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS 258
+
+
+/**
+ * struct v4l2_subdev_selection - selection info
+ *
+ * @which: either V4L2_SUBDEV_FORMAT_ACTIVE or V4L2_SUBDEV_FORMAT_TRY
+ * @pad: pad number, as reported by the media API
+ * @target: selection target, used to choose one of possible rectangles
+ * @flags: constraints flags
+ * @r: coordinates of selection window
+ * @reserved: for future use, rounds structure size to 64 bytes, set to zero
+ *
+ * Hardware may use multiple helper window to process a video stream.
+ * The structure is used to exchange this selection areas between
+ * an application and a driver.
+ */
+struct v4l2_subdev_selection {
+ __u32 which;
+ __u32 pad;
+ __u32 target;
+ __u32 flags;
+ struct v4l2_rect r;
+ __u32 reserved[8];
+};
+
#define VIDIOC_SUBDEV_G_FMT_IOWR('V', 4, struct v4l2_subdev_format)
#define VIDIOC_SUBDEV_S_FMT_IOWR('V', 5, struct v4l2_subdev_format)
#define VIDIOC_SUBDEV_G_FRAME_INTERVAL \
@@ -137,5 +178,9 @@ struct v4l2_subdev_frame_interval_enum {
_IOWR('V', 75, struct v4l2_subdev_frame_interval_enum)
#define VIDIOC_SUBDEV_G_CROP _IOWR('V', 59, struct v4l2_subdev_crop)
#define VIDIOC_SUBDEV_S_CROP _IOWR('V', 60, struct v4l2_subdev_crop)
+#define VIDIOC_SUBDEV_G_SELECTION \
+ _IOWR('V', 61, struct v4l2_subdev_selection)
+#define VIDIOC_SUBDEV_S_SELECTION \
+ _IOWR('V', 62, struct v4l2_subdev_selection)
#endif
diff --git a/include/media/v4l2-subdev.h
[RFC 07/17] v4l: Add pixelrate to struct v4l2_mbus_framefmt
From: Sakari Ailus sakari.ai...@iki.fi
Pixelrate is an essential part of the image data parameters. Add this.
Together, the current parameters also define the frame rate.
Sensors do not have a concept of frame rate; pixelrate is much more
meaningful in this context. Also, it is best to combine the pixelrate with
the other format parameters since there are dependencies between them.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
Documentation/DocBook/media/v4l/subdev-formats.xml | 10 +-
include/linux/v4l2-mediabus.h |4 +++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml
b/Documentation/DocBook/media/v4l/subdev-formats.xml
index 49c532e..a6a6630 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -35,7 +35,15 @@
/row
row
entry__u32/entry
- entrystructfieldreserved/structfield[7]/entry
+ entrystructfieldpixelrate/structfield/entry
+ entryPixel rate in kp/s. This clock is the maximum rate at
+ which pixels are transferred on the bus. The
+ structfieldpixelrate/structfield field is
+ read-only./entry
+ /row
+ row
+ entry__u32/entry
+ entrystructfieldreserved/structfield[6]/entry
entryReserved for future extensions. Applications and drivers must
set the array to zero./entry
/row
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 5ea7f75..35c6b96 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -101,6 +101,7 @@ enum v4l2_mbus_pixelcode {
* @code: data format code (from enum v4l2_mbus_pixelcode)
* @field: used interlacing type (from enum v4l2_field)
* @colorspace:colorspace of the data (from enum v4l2_colorspace)
+ * @pixel_clock: pixel clock, in kHz
*/
struct v4l2_mbus_framefmt {
__u32 width;
@@ -108,7 +109,8 @@ struct v4l2_mbus_framefmt {
__u32 code;
__u32 field;
__u32 colorspace;
- __u32 reserved[7];
+ __u32 pixelrate;
+ __u32 reserved[6];
};
#endif
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 03/17] vivi: Add an integer menu test control
From: Sakari Ailus sakari.ai...@iki.fi
Add an integer menu test control for the vivi driver.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/vivi.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/vivi.c b/drivers/media/video/vivi.c
index 7d754fb..763ec23 100644
--- a/drivers/media/video/vivi.c
+++ b/drivers/media/video/vivi.c
@@ -177,6 +177,7 @@ struct vivi_dev {
struct v4l2_ctrl *menu;
struct v4l2_ctrl *string;
struct v4l2_ctrl *bitmask;
+ struct v4l2_ctrl *int_menu;
spinlock_t slock;
struct mutex mutex;
@@ -503,6 +504,10 @@ static void vivi_fillbuff(struct vivi_dev *dev, struct
vivi_buffer *buf)
dev-boolean-cur.val,
dev-menu-qmenu[dev-menu-cur.val],
dev-string-cur.string);
+ snprintf(str, sizeof(str), integer_menu %s, value %lld ,
+ dev-int_menu-qmenu[dev-int_menu-cur.val],
+ dev-int64-cur.val64);
+ gen_text(dev, vbuf, line++ * 16, 16, str);
mutex_unlock(dev-ctrl_handler.lock);
gen_text(dev, vbuf, line++ * 16, 16, str);
if (dev-button_pressed) {
@@ -1183,6 +1188,22 @@ static const struct v4l2_ctrl_config vivi_ctrl_bitmask =
{
.step = 0,
};
+static const s64 * const vivi_ctrl_int_menu_values[] = {
+ 1, 1, 2, 3, 5, 8, 13, 21, 42,
+};
+
+static const struct v4l2_ctrl_config vivi_ctrl_string = {
+ .ops = vivi_ctrl_ops,
+ .id = VIDI_CID_CUSTOM_BASE + 7
+ .name = Integer menu,
+ .type = V4L2_CTRL_TYPE_INTEGER_MENU,
+ .min = 1,
+ .max = 8,
+ .def = 4,
+ .menu_skip_mask = 0x02,
+ .qmenu_int = vivi_ctrl_int_menu_values,
+};
+
static const struct v4l2_file_operations vivi_fops = {
.owner = THIS_MODULE,
.open = v4l2_fh_open,
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 08/17] v4l: Image source control class
From: Sakari Ailus sakari.ai...@iki.fi Add image source control class. This control class is intended to contain low level controls which deal with control of the image capture process --- the A/D converter in image sensors, for example. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- Documentation/DocBook/media/v4l/controls.xml | 101 .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |6 + drivers/media/video/v4l2-ctrls.c | 10 ++ include/linux/videodev2.h | 10 ++ 4 files changed, 127 insertions(+), 0 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 3bc5ee8..69ede83 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -3356,6 +3356,107 @@ interface and may change in the future./para /table /section + +section id=image-source-controls + titleImage Source Control Reference/title + + note + titleExperimental/title + + paraThis is an link + linkend=experimentalexperimental/link interface and may + change in the future./para + /note + + para + The Image Source control class is intended for low-level + control of image source devices such as image sensors. The + devices feature an analogue to digital converter and a bus + transmitter to transmit the image data out of the device. + /para + + table pgwide=1 frame=none id=image-source-control-id + titleImage Source Control IDs/title + + tgroup cols=4 + colspec colname=c1 colwidth=1* / + colspec colname=c2 colwidth=6* / + colspec colname=c3 colwidth=2* / + colspec colname=c4 colwidth=6* / + spanspec namest=c1 nameend=c2 spanname=id / + spanspec namest=c2 nameend=c4 spanname=descr / + thead + row + entry spanname=id align=leftID/entry + entry align=leftType/entry + /rowrow rowsep=1entry spanname=descr align=leftDescription/entry + /row + /thead + tbody valign=top + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_IMAGE_SOURCE_CLASS/constant/entry + entryclass/entry + /row + row + entry spanname=descrThe IMAGE_SOURCE class descriptor./entry + /row + row + entry spanname=idconstantV4L2_CID_IMAGE_SOURCE_VBLANK/constant/entry + entryinteger/entry + /row + row + entry spanname=descrVertical blanking. The idle + preriod after every frame during which no image data is + produced. The unit of vertical blanking is a line. Every + line has length of the image width plus horizontal + blanking at the pixel clock specified by struct + v4l2_mbus_framefmt xref linkend=v4l2-mbus-framefmt + /./entry + /row + row + entry spanname=idconstantV4L2_CID_IMAGE_SOURCE_HBLANK/constant/entry + entryinteger/entry + /row + row + entry spanname=descrHorizontal blanking. The idle + preriod after every line of image data during which no + image data is produced. The unit of horizontal blanking is + pixels./entry + /row + row + entry spanname=idconstantV4L2_CID_IMAGE_SOURCE_LINK_FREQ/constant/entry + entryinteger menu/entry + /row + row + entry spanname=descrImage source's data bus frequency. + Together with the media bus pixel code, bus type (clock + cycles per sample), the data bus frequency defines the + pixel clock. xref linkend=v4l2-mbus-framefmt / The + frame rate can be calculated from the pixel clock, image + width and height and horizontal and vertical blanking. The + frame rate control is performed by selecting the desired + horizontal and vertical blanking. + /entry + /row + row + entry spanname=idconstantV4L2_CID_IMAGE_SOURCE_ANALOGUE_GAIN/constant/entry + entryinteger/entry + /row + row + entry spanname=descrAnalogue gain is gain affecting + all colour components in the pixel matrix. The gain + operation is performed in the analogue domain before A/D + conversion. + /entry + /row + rowentry/entry/row + /tbody + /tgroup + /table + +/section + /section !-- diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml index 5122ce8..250c1cf 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml @@ -257,6 +257,12 @@ These controls are described in xref These
[RFC 10/17] omap3: add definition for CONTROL_CAMERA_PHY_CTRL
From: Sakari Ailus sakari.ai...@iki.fi This register is available only in OMAP3630. The original patch was submitted by Vimarsh Zutshi. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- arch/arm/mach-omap2/control.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/control.h b/arch/arm/mach-omap2/control.h index d4ef75d..6a26a0d 100644 --- a/arch/arm/mach-omap2/control.h +++ b/arch/arm/mach-omap2/control.h @@ -183,6 +183,7 @@ #define OMAP3630_CONTROL_FUSE_OPP120_VDD1 (OMAP2_CONTROL_GENERAL + 0x0120) #define OMAP3630_CONTROL_FUSE_OPP50_VDD2(OMAP2_CONTROL_GENERAL + 0x0128) #define OMAP3630_CONTROL_FUSE_OPP100_VDD2 (OMAP2_CONTROL_GENERAL + 0x012C) +#define OMAP3630_CONTROL_CAMERA_PHY_CTRL (OMAP2_CONTROL_GENERAL + 0x02f0) /* OMAP44xx control efuse offsets */ #define OMAP44XX_CONTROL_FUSE_IVA_OPP500x22C -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 11/17] omap3isp: Implement validate_pipeline
From: Sakari Ailus sakari.ai...@iki.fi
Validate pipeline of any external entity connected to the ISP driver.
The validation of the pipeline for the part that involves links inside the
domain of another driver must be done by that very driver.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispvideo.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index f229057..0568234 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -355,6 +355,18 @@ static int isp_video_validate_pipeline(struct isp_pipeline
*pipe)
fmt_source.format.height != fmt_sink.format.height)
return -EPIPE;
+ if (subdev-host_priv) {
+ /*
+* host_priv != NULL: this is a sensor. Issue
+* validate_pipeline. We're at our end of the
+* pipeline so we quit now.
+*/
+ ret = v4l2_subdev_call(subdev, pad, validate_pipeline);
+ if (ret 0 ret != -ENOIOCTLCMD)
+ return -EPIPE;
+ break;
+ }
+
if (shifter_link) {
unsigned int parallel_shift = 0;
if (isp-isp_ccdc.input == CCDC_INPUT_PARALLEL) {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 12/17] omap3isp: Add lane configuration to platform data
From: Sakari Ailus sakari.ai...@iki.fi
Add lane configuration (order of clock and data lane) to platform data on
both CCP2 and CSI-2.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispcsiphy.h | 15 ++-
include/media/omap3isp.h | 15 +++
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispcsiphy.h
b/drivers/media/video/omap3isp/ispcsiphy.h
index 9596dc6..e93a661 100644
--- a/drivers/media/video/omap3isp/ispcsiphy.h
+++ b/drivers/media/video/omap3isp/ispcsiphy.h
@@ -27,22 +27,11 @@
#ifndef OMAP3_ISP_CSI_PHY_H
#define OMAP3_ISP_CSI_PHY_H
+#include media/omap3isp.h
+
struct isp_csi2_device;
struct regulator;
-struct csiphy_lane {
- u8 pos;
- u8 pol;
-};
-
-#define ISP_CSIPHY2_NUM_DATA_LANES 2
-#define ISP_CSIPHY1_NUM_DATA_LANES 1
-
-struct isp_csiphy_lanes_cfg {
- struct csiphy_lane data[ISP_CSIPHY2_NUM_DATA_LANES];
- struct csiphy_lane clk;
-};
-
struct isp_csiphy_dphy_cfg {
u8 ths_term;
u8 ths_settle;
diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
index e917b1d..8fe0bdf 100644
--- a/include/media/omap3isp.h
+++ b/include/media/omap3isp.h
@@ -86,6 +86,19 @@ enum {
ISP_CCP2_MODE_CCP2 = 1,
};
+struct csiphy_lane {
+ u8 pos;
+ u8 pol;
+};
+
+#define ISP_CSIPHY2_NUM_DATA_LANES 2
+#define ISP_CSIPHY1_NUM_DATA_LANES 1
+
+struct isp_csiphy_lanes_cfg {
+ struct csiphy_lane data[ISP_CSIPHY2_NUM_DATA_LANES];
+ struct csiphy_lane clk;
+};
+
/**
* struct isp_ccp2_platform_data - CCP2 interface platform data
* @strobe_clk_pol: Strobe/clock polarity
@@ -105,6 +118,7 @@ struct isp_ccp2_platform_data {
unsigned int ccp2_mode:1;
unsigned int phy_layer:1;
unsigned int vpclk_div:2;
+ struct isp_csiphy_lanes_cfg *lanecfg;
};
/**
@@ -115,6 +129,7 @@ struct isp_ccp2_platform_data {
struct isp_csi2_platform_data {
unsigned crc:1;
unsigned vpclk_div:2;
+ struct isp_csiphy_lanes_cfg *lanecfg;
};
struct isp_subdev_i2c_board_info {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 15/17] omap3isp: Move definitions required by board code under include/media.
From: Sakari Ailus sakari.ai...@iki.fi
XCLK definitions are often required by the board code. Move them to public
include file.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/isp.h |4
include/media/omap3isp.h |4
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h
index 7d73a39..dd1b61e 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -235,10 +235,6 @@ void omap3isp_configure_bridge(struct isp_device *isp,
const struct isp_parallel_platform_data *pdata,
unsigned int shift);
-#define ISP_XCLK_NONE 0
-#define ISP_XCLK_A 1
-#define ISP_XCLK_B 2
-
struct isp_device *omap3isp_get(struct isp_device *isp);
void omap3isp_put(struct isp_device *isp);
diff --git a/include/media/omap3isp.h b/include/media/omap3isp.h
index 8fe0bdf..deb3949 100644
--- a/include/media/omap3isp.h
+++ b/include/media/omap3isp.h
@@ -29,6 +29,10 @@
struct i2c_board_info;
struct isp_device;
+#define ISP_XCLK_NONE 0
+#define ISP_XCLK_A 1
+#define ISP_XCLK_B 2
+
enum isp_interface_type {
ISP_INTERFACE_PARALLEL,
ISP_INTERFACE_CSI2A_PHY2,
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 13/17] omap3isp: Configure CSI-2 phy based on platform data
From: Sakari Ailus sakari.ai...@iki.fi
Configure CSI-2 phy based on platform data in the ISP driver rather than in
platform code.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/isp.c | 38 --
drivers/media/video/omap3isp/isp.h |3 -
drivers/media/video/omap3isp/ispcsiphy.c | 83 ++
drivers/media/video/omap3isp/ispcsiphy.h |4 ++
4 files changed, 111 insertions(+), 17 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index b818cac..6020fd7 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -737,7 +737,7 @@ static int isp_pipeline_enable(struct isp_pipeline *pipe,
struct isp_device *isp = pipe-output-isp;
struct media_entity *entity;
struct media_pad *pad;
- struct v4l2_subdev *subdev;
+ struct v4l2_subdev *subdev = NULL, *prev_subdev;
unsigned long flags;
int ret;
@@ -759,11 +759,41 @@ static int isp_pipeline_enable(struct isp_pipeline *pipe,
break;
entity = pad-entity;
+ prev_subdev = subdev;
subdev = media_entity_to_v4l2_subdev(entity);
- ret = v4l2_subdev_call(subdev, video, s_stream, mode);
- if (ret 0 ret != -ENOIOCTLCMD)
- return ret;
+ /* Configure CSI-2 receiver based on sensor format. */
+ if (prev_subdev == isp-isp_csi2a.subdev
+ || prev_subdev == isp-isp_csi2c.subdev) {
+ struct v4l2_subdev_format fmt;
+
+ fmt.pad = pad-index;
+ fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ ret = v4l2_subdev_call(subdev, pad, get_fmt,
+ NULL, fmt);
+ if (ret 0)
+ return -EPIPE;
+
+ ret = omap3isp_csiphy_config(
+ isp, prev_subdev, subdev,
+ fmt.format);
+ if (ret 0)
+ return -EPIPE;
+
+ /* Start CSI-2 after configuration. */
+ ret = v4l2_subdev_call(prev_subdev, video,
+ s_stream, mode);
+ if (ret 0 ret != -ENOIOCTLCMD)
+ return ret;
+ }
+
+ /* Start any other subdev except the CSI-2 receivers. */
+ if (subdev != isp-isp_csi2a.subdev
+subdev != isp-isp_csi2c.subdev) {
+ ret = v4l2_subdev_call(subdev, video, s_stream, mode);
+ if (ret 0 ret != -ENOIOCTLCMD)
+ return ret;
+ }
if (subdev == isp-isp_ccdc.subdev) {
v4l2_subdev_call(isp-isp_aewb.subdev, video,
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h
index 705946e..c5935ae 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -126,9 +126,6 @@ struct isp_reg {
struct isp_platform_callback {
u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
- int (*csiphy_config)(struct isp_csiphy *phy,
-struct isp_csiphy_dphy_cfg *dphy,
-struct isp_csiphy_lanes_cfg *lanes);
void (*set_pixel_clock)(struct isp_device *isp, unsigned int pixelclk);
};
diff --git a/drivers/media/video/omap3isp/ispcsiphy.c
b/drivers/media/video/omap3isp/ispcsiphy.c
index 5be37ce..f027ece 100644
--- a/drivers/media/video/omap3isp/ispcsiphy.c
+++ b/drivers/media/video/omap3isp/ispcsiphy.c
@@ -28,6 +28,8 @@
#include linux/device.h
#include linux/regulator/consumer.h
+#include ../../../../arch/arm/mach-omap2/control.h
+
#include isp.h
#include ispreg.h
#include ispcsiphy.h
@@ -138,15 +140,78 @@ static void csiphy_dphy_config(struct isp_csiphy *phy)
isp_reg_writel(phy-isp, reg, phy-phy_regs, ISPCSIPHY_REG1);
}
-static int csiphy_config(struct isp_csiphy *phy,
-struct isp_csiphy_dphy_cfg *dphy,
-struct isp_csiphy_lanes_cfg *lanes)
+/*
+ * TCLK values are OK at their reset values
+ */
+#define TCLK_TERM 0
+#define TCLK_MISS 1
+#define TCLK_SETTLE14
+
+int omap3isp_csiphy_config(struct isp_device *isp,
+ struct v4l2_subdev *csi2_subdev,
+ struct v4l2_subdev *sensor,
+ struct v4l2_mbus_framefmt *sensor_fmt)
{
+ struct isp_v4l2_subdevs_group *subdevs = sensor-host_priv;
+ struct isp_csi2_device *csi2 = v4l2_get_subdevdata(csi2_subdev);
+ struct isp_csiphy_dphy_cfg csi2phy;
+ int csi2_ddrclk_khz;
+ struct
[RFC 09/17] v4l: Add pad op for pipeline validation
From: Sakari Ailus sakari.ai...@iki.fi
smiapp_pad_ops.validate_pipeline is intended to validate the full pipeline
which is implemented by the driver to which the subdev implementing this op
belongs to. The validate_pipeline op must also call validate_pipeline on
any external entity which is linked to its sink pads.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
include/media/v4l2-subdev.h |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 26eeaa4..a5ebe86 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -470,6 +470,7 @@ struct v4l2_subdev_pad_ops {
struct v4l2_subdev_selection *sel);
int (*set_selection)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
struct v4l2_subdev_selection *sel);
+ int (*validate_pipeline)(struct v4l2_subdev *sd);
};
struct v4l2_subdev_ops {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 14/17] omap3isp: Use pixelrate from sensor media bus frameformat
From: Sakari Ailus sakari.ai...@iki.fi
Configure the ISP based on the pixelrate in media bus frame format.
Previously the same was configured from the board code.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/isp.c | 24 +---
drivers/media/video/omap3isp/isp.h |1 -
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c
index 6020fd7..92f9716 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -749,10 +749,14 @@ static int isp_pipeline_enable(struct isp_pipeline *pipe,
entity = pipe-output-video.entity;
while (1) {
- pad = entity-pads[0];
- if (!(pad-flags MEDIA_PAD_FL_SINK))
+ /*
+* Is this an external subdev connected to us? If so,
+* we're done.
+*/
+ if (subdev subdev-host_priv)
break;
+ pad = entity-pads[0];
pad = media_entity_remote_source(pad);
if (pad == NULL ||
media_entity_type(pad-entity) != MEDIA_ENT_T_V4L2_SUBDEV)
@@ -762,6 +766,21 @@ static int isp_pipeline_enable(struct isp_pipeline *pipe,
prev_subdev = subdev;
subdev = media_entity_to_v4l2_subdev(entity);
+ /* Configure CCDC pixel clock */
+ if (subdev-host_priv) {
+ struct v4l2_subdev_format fmt;
+
+ fmt.pad = pad-index;
+ fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ ret = v4l2_subdev_call(subdev, pad, get_fmt,
+ NULL, fmt);
+ if (ret 0)
+ return -EINVAL;
+
+ isp_set_pixel_clock(isp,
+ fmt.format.pixelrate * 1000);
+ }
+
/* Configure CSI-2 receiver based on sensor format. */
if (prev_subdev == isp-isp_csi2a.subdev
|| prev_subdev == isp-isp_csi2c.subdev) {
@@ -2102,7 +2121,6 @@ static int isp_probe(struct platform_device *pdev)
isp-autoidle = autoidle;
isp-platform_cb.set_xclk = isp_set_xclk;
- isp-platform_cb.set_pixel_clock = isp_set_pixel_clock;
mutex_init(isp-isp_mutex);
spin_lock_init(isp-stat_lock);
diff --git a/drivers/media/video/omap3isp/isp.h
b/drivers/media/video/omap3isp/isp.h
index c5935ae..7d73a39 100644
--- a/drivers/media/video/omap3isp/isp.h
+++ b/drivers/media/video/omap3isp/isp.h
@@ -126,7 +126,6 @@ struct isp_reg {
struct isp_platform_callback {
u32 (*set_xclk)(struct isp_device *isp, u32 xclk, u8 xclksel);
- void (*set_pixel_clock)(struct isp_device *isp, unsigned int pixelclk);
};
/*
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 05/17] v4l: Support s_crop and g_crop through s/g_selection
From: Sakari Ailus sakari.ai...@iki.fi
Revert to s_selection if s_crop isn't implemented by a driver. Same for
g_selection / g_crop.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/v4l2-subdev.c | 37 +++--
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/v4l2-subdev.c
b/drivers/media/video/v4l2-subdev.c
index e8ae098..f8de551 100644
--- a/drivers/media/video/v4l2-subdev.c
+++ b/drivers/media/video/v4l2-subdev.c
@@ -226,6 +226,8 @@ static long subdev_do_ioctl(struct file *file, unsigned int
cmd, void *arg)
case VIDIOC_SUBDEV_G_CROP: {
struct v4l2_subdev_crop *crop = arg;
+ struct v4l2_subdev_selection sel;
+ int rval;
if (crop-which != V4L2_SUBDEV_FORMAT_TRY
crop-which != V4L2_SUBDEV_FORMAT_ACTIVE)
@@ -234,11 +236,27 @@ static long subdev_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
if (crop-pad = sd-entity.num_pads)
return -EINVAL;
- return v4l2_subdev_call(sd, pad, get_crop, subdev_fh, crop);
+ rval = v4l2_subdev_call(sd, pad, get_crop, subdev_fh, crop);
+ if (rval != -ENOIOCTLCMD)
+ return rval;
+
+ memset(sel, 0, sizeof(sel));
+ sel.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ sel.pad = crop-pad;
+ sel.target = V4L2_SUBDEV_SEL_TGT_CROP_ACTIVE;
+
+ rval = v4l2_subdev_call(
+ sd, pad, get_selection, subdev_fh, sel);
+
+ crop-rect = sel.r;
+
+ return rval;
}
case VIDIOC_SUBDEV_S_CROP: {
struct v4l2_subdev_crop *crop = arg;
+ struct v4l2_subdev_selection sel;
+ int rval;
if (crop-which != V4L2_SUBDEV_FORMAT_TRY
crop-which != V4L2_SUBDEV_FORMAT_ACTIVE)
@@ -247,7 +265,22 @@ static long subdev_do_ioctl(struct file *file, unsigned
int cmd, void *arg)
if (crop-pad = sd-entity.num_pads)
return -EINVAL;
- return v4l2_subdev_call(sd, pad, set_crop, subdev_fh, crop);
+ rval = v4l2_subdev_call(sd, pad, set_crop, subdev_fh, crop);
+ if (rval != -ENOIOCTLCMD)
+ return rval;
+
+ memset(sel, 0, sizeof(sel));
+ sel.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ sel.pad = crop-pad;
+ sel.target = V4L2_SUBDEV_SEL_TGT_CROP_ACTIVE;
+ sel.r = crop-rect;
+
+ rval = v4l2_subdev_call(
+ sd, pad, set_selection, subdev_fh, sel);
+
+ crop-rect = sel.r;
+
+ return rval;
}
case VIDIOC_SUBDEV_ENUM_MBUS_CODE: {
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 17/17] rm680: Add camera init
This currently introduces an extra file to the arch/arm/mach-omap2
directory: board-rm680-camera.c. Keeping the device tree in mind, the
context of the file could be represented as static data with one exception:
the external clock to the sensor.
This external clock is provided by the OMAP 3 SoC and required by the
sensor. The issue is that the clock originates from the ISP and not from
PRCM block as the other clocks and thus is not supported by the clock
framework. Otherwise the sensor driver could just clk_get() and clk_enable()
it, just like the regulators and gpios.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
---
arch/arm/mach-omap2/Makefile |3 +-
arch/arm/mach-omap2/board-rm680-camera.c | 408 ++
arch/arm/mach-omap2/board-rm680.c| 42 +++
3 files changed, 452 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-omap2/board-rm680-camera.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 69ab1c0..1444bc5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -201,7 +201,8 @@ obj-$(CONFIG_MACH_OMAP3_PANDORA)+= board-omap3pandora.o
obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o
obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
obj-$(CONFIG_MACH_NOKIA_RM680) += board-rm680.o \
- sdram-nokia.o
+ sdram-nokia.o \
+ board-rm680-camera.o
obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \
sdram-nokia.o \
board-rx51-peripherals.o \
diff --git a/arch/arm/mach-omap2/board-rm680-camera.c
b/arch/arm/mach-omap2/board-rm680-camera.c
new file mode 100644
index 000..4cc1ced
--- /dev/null
+++ b/arch/arm/mach-omap2/board-rm680-camera.c
@@ -0,0 +1,408 @@
+/**
+ * arch/arm/mach-omap2/board-rm680-camera.c
+ *
+ * Copyright (C) 2010--2011 Nokia Corporation
+ * Contact: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
+ *
+ * Based on board-rx71-camera.c by Vimarsh Zutshi
+ * Based on board-rx51-camera.c by Sakari Ailus
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/delay.h
+#include linux/mm.h
+#include linux/platform_device.h
+#include linux/videodev2.h
+
+#include linux/gpio.h
+#include plat/omap-pm.h
+
+#include ../../../drivers/media/video/omap3isp/isp.h
+
+#include media/omap3isp.h
+#include media/smiapp.h
+#include asm/mach-types.h
+
+#include ../../../drivers/media/video/smiapp.h
+
+#include devices.h
+
+#define SEC_CAMERA_RESET_GPIO 97
+
+#define RM680_PRI_SENSOR 1
+#define RM680_PRI_LENS 2
+#define RM680_SEC_SENSOR 3
+#define MAIN_CAMERA_XCLK ISP_XCLK_A
+#define SEC_CAMERA_XCLKISP_XCLK_B
+
+/*
+ *
+ * HW initialization
+ *
+ *
+ */
+static int __init rm680_sec_camera_init(void)
+{
+ if (gpio_request(SEC_CAMERA_RESET_GPIO, sec_camera reset) != 0) {
+ printk(KERN_INFO %s: unable to acquire secondary
+ camera reset gpio\n, __func__);
+ return -ENODEV;
+ }
+
+ /* XSHUTDOWN off, reset */
+ gpio_direction_output(SEC_CAMERA_RESET_GPIO, 0);
+ gpio_set_value(SEC_CAMERA_RESET_GPIO, 0);
+
+ return 0;
+}
+
+static int __init rm680_camera_hw_init(void)
+{
+ return rm680_sec_camera_init();
+}
+
+/*
+ *
+ * Main Camera Module EXTCLK
+ * Used by the sensor and the actuator driver.
+ *
+ */
+static struct camera_xclk {
+ u32 hz;
+ u32 lock;
+ u8 xclksel;
+} cameras_xclk;
+
+static DEFINE_MUTEX(lock_xclk);
+
+static int rm680_update_xclk(struct v4l2_subdev *subdev, u32 hz, u32 which,
+u8 xclksel)
+{
+ struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+ int ret;
+
+ mutex_lock(lock_xclk);
+
+ if (which == RM680_SEC_SENSOR) {
+ if (cameras_xclk.xclksel == MAIN_CAMERA_XCLK) {
+ ret = -EBUSY;
+ goto done;
+ }
+ } else {
+ if (cameras_xclk.xclksel == SEC_CAMERA_XCLK) {
+ ret = -EBUSY;
+ goto done;
+ }
+ }
+
+ if (hz) {
Re: [Linaro-mm-sig] [RFC v3 0/2] Introduce DMA buffer sharing mechanism
On Tue, Dec 20, 2011 at 2:20 PM, Dave Airlie airl...@gmail.com wrote: This is RFC v3 for DMA buffer sharing mechanism - changes from v2 are in the changelog below. Various subsystems - V4L2, GPU-accessors, DRI to name a few - have felt the need to have a common mechanism to share memory buffers across different devices - ARM, video hardware, GPU. This need comes forth from a variety of use cases including cameras, image processing, video recorders, sound processing, DMA engines, GPU and display buffers, and others. This RFC is an attempt to define such a buffer sharing mechanism- it is the result of discussions from a couple of memory-management mini-summits held by Linaro to understand and address common needs around memory management. [1] A new dma_buf buffer object is added, with operations and API to allow easy sharing of this buffer object across devices. The framework allows: - a new buffer-object to be created with fixed size. - different devices to 'attach' themselves to this buffer, to facilitate backing storage negotiation, using dma_buf_attach() API. - association of a file pointer with each user-buffer and associated allocator-defined operations on that buffer. This operation is called the 'export' operation. - this exported buffer-object to be shared with the other entity by asking for its 'file-descriptor (fd)', and sharing the fd across. - a received fd to get the buffer object back, where it can be accessed using the associated exporter-defined operations. - the exporter and user to share the scatterlist using map_dma_buf and unmap_dma_buf operations. Documentation present in the patch-set gives more details. This is based on design suggestions from many people at the mini-summits, most notably from Arnd Bergmann a...@arndb.de, Rob Clark r...@ti.com and Daniel Vetter dan...@ffwll.ch. The implementation is inspired from proof-of-concept patch-set from Tomasz Stanislawski t.stanisl...@samsung.com, who demonstrated buffer sharing between two v4l2 devices. [2] References: [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement [2]: http://lwn.net/Articles/454389 Patchset based on top of 3.2-rc3, the current version can be found at http://git.linaro.org/gitweb?p=people/sumitsemwal/linux-3.x.git Branch: dma-buf-upstr-v2 Earlier versions: v2 at: https://lkml.org/lkml/2011/12/2/53 v1 at: https://lkml.org/lkml/2011/10/11/92 Best regards, ~Sumit Semwal I think this is a really good v1 version of dma_buf. It contains all the required bits (with well-specified semantics in the doc patch) to implement some basic use-cases and start fleshing out the integration with various subsystem (like drm and v4l). All the things still under discussion like - userspace mmap support - more advanced (and more strictly specified) coherency models - and shared infrastructure for implementing exporters are imo much clearer once we have a few example drivers at hand and a better understanding of some of the insane corner cases we need to be able to handle. And I think any risk that the resulting clarifications will break a basic use-case is really minimal, so I think it'd be great if this could go into 3.3 (maybe as some kind of staging/experimental infrastructure). Hence for both patches: Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Yeah I'm with Daniel, I like this one, I can definitely build the drm buffer sharing layer on top of this. How do we see this getting merged? I'm quite happy to push it to Linus if we don't have an identified path, though it could go via a Linaro tree as well. so feel free to add: Reviewed-by: Dave Airlie airl...@redhat.com fwiw, patches to share buffers between drm and v4l2 are here: https://github.com/robclark/kernel-omap4/commits/drmplane-dmabuf (need a bit of cleanup before the vb2 patches are submitted.. but that is unrelated to the dmabuf patches) so, Reviewed-and-Tested-by: Rob Clark rob.cl...@linaro.org Dave. -- 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: [GIT PULL FOR 3.3] HDIC HD29L2 DMB-TH demodulator driver
On Tue, Dec 20, 2011 at 10:26 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
On 20-12-2011 12:52, Antti Palosaari wrote:
+ /* reset demod */
+ /* it is recommended to HW reset chip using RST_N pin */
+ if (fe-callback) {
+ ret = fe-callback(fe, 0, 0, 0);
This looks weird on my eyes. The fe-callback is tuner-dependent.
So, the command you should use there requires a test for the tuner
type.
In other words, if you're needing to use it, the code should be doing
something similar to:
if (fe-callback priv-tuner_type == TUNER_XC2028)
ret = fe-callback(fe, 0, XC2028_TUNER_RESET, 0);
(the actual coding will depend on how do you store the tuner type, and
what are the commands for the tuner you're using)
That's said, it probably makes sense to deprecate fe-callback in favor
or a more generic set of callbacks, like fe-tuner_reset().
Yes it is wrong because there was no DEMOD defined. But, the callback
itself is correctly. IIRC there was only TUNER defined and no DEMOD.
Look callback definition from the API. It is very simply to fix. But at
the time left it like that, because I wanted to avoid touching one file
more. I will fix it properly later (2 line change).
And it was not a bug, it was just my known decision. I just forget to
comment it as FIXME or TODO.
Feel free to touch on other files, provided that you fix that. There's
no default behavior for fe-callback, as it were written in order to
provide ways for the tuner to call the bridge driver for some device-specific
reasons. So, the commands are defined with macros, and the callback code
should be device-specific.
This generic callback was written for the BRIDGE driver to be called
by any frontend COMPONENT, not specifically the tuner, perhaps a demod
or LNB, but at the time of writing, we only needed it from the tuner
so the DVB_FRONTEND_COMPONENT_TUNER(0) was the only #define created at
the time. This was written with forward-compatibility in mind, so
lets please not deprecate it unless we actually have to -- I see
additional uses for this coming in the future.
In order to use fe callback properly, please add #define
DVB_FRONTEND_COMPONENT_DEMOD 1 to dvb-core/dvb_frontend.h , and
simply call your callback as fe-callback(adap_state,
DVB_FRONTEND_COMPONENT_DEMOD, CMD, ARG) ... This way, the callback
knows that it is being called by the demod and not the tuner, it is
receiving command CMD with argument ARG.
I can imagine a need one day to perhaps convert the int arg into a
void* arg, but such a need doesn't exist today. I don't think it
gets any more generic than this.
int (*callback)(void *adapter_priv, int component, int cmd, int arg);
Cheers,
Mike
--
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/2] media: add new mediabus format enums for dm365
Hi Manju,
On Friday 16 December 2011 15:20:24 Hadli, Manjunath wrote:
On Thu, Dec 15, 2011 at 18:32:44, Laurent Pinchart wrote:
On Thursday 15 December 2011 13:24:57 Manjunath Hadli wrote:
add new enum entry V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 into
mbus_pixel_code to represent A-LAW compressed Bayer format. This
corresponds to pixel format - V4L2_PIX_FMT_SGRBG10ALAW8.
add UV8 and NV12 ( Y and C separate with UV interleaved) which are
supported on dm365.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/v4l2-mediabus.h | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
Please also update the documentation in Documentation/DocBook/media/v4l.
diff --git a/include/linux/v4l2-mediabus.h
b/include/linux/v4l2-mediabus.h index 5ea7f75..d408654 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -47,7 +47,7 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007,
V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008,
- /* YUV (including grey) - next is 0x2014 */
+ /* YUV (including grey) - next is 0x2016 */
V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
@@ -67,8 +67,10 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
+ V4L2_MBUS_FMT_NV12_1X20 = 0x2014,
+ V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
NV12, on the bus ? How does that work ? (The documentation should answer
my question :-))
Well, this is on the internal bus not exposed outside, but nevertheless bus
between two subdevs or two independent hardware blocks. For example Resizer
supports NV12 on its pad. Is there any other way to treat this?
How is NV12 transferred on the bus in that case ? Are all luma samples
transferred first, followed by all chroma samples ?
- /* Bayer - next is 0x3015 */
+ /* Bayer - next is 0x3019 */
V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013,
V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
@@ -89,6 +91,10 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010,
V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011,
V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012,
+ V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015,
+ V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016,
+ V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017,
+ V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018,
Please keep the names sorted as described in the comment at the beginning
of the file.
/* JPEG compressed formats - next is 0x4002 */
V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
--
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 2/2] v4l2: add new pixel formats supported on dm365
Hi Manju,
On Friday 16 December 2011 14:42:48 Hadli, Manjunath wrote:
On Thu, Dec 15, 2011 at 18:30:47, Laurent Pinchart wrote:
On Thursday 15 December 2011 13:24:58 Manjunath Hadli wrote:
add new macro V4L2_PIX_FMT_SGRBG10ALAW8 to represent Bayer format
frames compressed by A-LAW alogorithm.
add V4L2_PIX_FMT_UV8 to represent storage of C (UV interleved) only.
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/linux/videodev2.h |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
Could you please also document these formats in
Documentation/DocBook/media/v4l ?
I will. Sorry to have missed that out.
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4b752d5..969112d 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -338,6 +338,9 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_HM12v4l2_fourcc('H', 'M', '1', '2') /* 8
YUV
4:2:0 16x16 macroblocks */ #define V4L2_PIX_FMT_M420
v4l2_fourcc('M', '4', '2', '0') /* 12 YUV 4:2:0 2 lines y, 1 line uv
interleaved */
+/* Chrominance formats */
+#define V4L2_PIX_FMT_UV8 v4l2_fourcc('U', 'V', '8', ' ') /* 8
UV 4:4 */ +
/* two planes -- one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12v4l2_fourcc('N', 'V', '1', '2') /* 12
Y/CbCr
4:2:0 */ #define V4L2_PIX_FMT_NV21v4l2_fourcc('N', 'V', '2', '1')
/* 12 Y/CrCb 4:2:0 */ @@ -366,6 +369,9 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12
RGRG.. GBGB.. */ /* 10bit raw bayer DPCM compressed to 8 bits */
#define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0')
+ /* 10bit raw bayer a-law compressed to 8 bits */ #define
+V4L2_PIX_FMT_SGRBG10ALAW8 v4l2_fourcc('A', 'L', 'W', '8')
+
That's not very future-proof, how would you describe SGBRG10ALAW8 for
instance ?
Maybe it's time to standardize FOURCCs for Bayer new formats. We have 4
characters, we could start with 'B' to denote Bayer, followed by one
character for the order, one for the compression, and one for the number
of bits.
I agree.
May be ('B', 'G', 'A', '8') is fine for the above?
We need to describe at last BGGR, GBRG, GRBG and RGGB. We could use 'B', 'g',
'G' and 'R' respectively for the second character. The third character would
be 'A' for A-law and 'D' for DPCM, and the fourth character could describe the
bus width in bits from 0 to 15 with '0' - '9', 'A' - 'F'. However, I suspect
that we will need 16-bit wide busses for raw Bayer at some point, and a 0
width is definitely not useful. We could thus offset the width by some value.
This is just a preliminary idea, I'm open to suggestions.
/*
* 10bit raw bayer, expanded to 16 bits
* rrgg ggbb...
--
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: [PATCHv4 1/2] v4l: Add new framesamples field to struct v4l2_mbus_framefmt
Hi Sylwester,
On Wednesday 14 December 2011 13:23:07 Sylwester Nawrocki wrote:
The purpose of the new field is to allow the video pipeline elements
to negotiate memory buffer size for compressed data frames, where
the buffer size cannot be derived from pixel width and height and
the pixel code.
For VIDIOC_SUBDEV_S_FMT and VIDIOC_SUBDEV_G_FMT ioctls, the
framesamples parameter should be calculated by the driver from pixel
width, height, color format and other parameters if required and
returned to the caller. This applies to compressed data formats only.
The application should propagate the framesamples value, whatever
returned at the first sub-device within a data pipeline, i.e. at the
pipeline's data source.
For compressed data formats the host drivers should internally
validate the framesamples parameter values before streaming is
enabled, to make sure the memory buffer size requirements are
satisfied along the pipeline.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
--
There is no changes in this patch comparing to v3.
---
Documentation/DocBook/media/v4l/dev-subdev.xml | 10 --
Documentation/DocBook/media/v4l/subdev-formats.xml |9 -
include/linux/v4l2-mediabus.h |4 +++-
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/dev-subdev.xml
b/Documentation/DocBook/media/v4l/dev-subdev.xml index 0916a73..b9d24eb
100644
--- a/Documentation/DocBook/media/v4l/dev-subdev.xml
+++ b/Documentation/DocBook/media/v4l/dev-subdev.xml
@@ -160,7 +160,13 @@
guaranteed to be supported by the device. In particular, drivers
guarantee that a returned format will not be further changed if passed to
an VIDIOC-SUBDEV-S-FMT; call as-is (as long as external parameters, such
as
- formats on other pads or links' configuration are not changed).
/para
+ formats on other pads or links' configuration are not changed). When
+ a device contains a data encoder, the structfield
+ link linkend=v4l2-mbus-framefmt-framesamplesframesamples/link
+ /structfield field value may be further changed, if parameters of
the
+ encoding process are changed after the format has been negotiated. In
+ such situation applications should use VIDIOC-SUBDEV-G-FMT; ioctl to
+ query an updated format./para
Sorry for answering so late. I've been thinking about this topic (as well as
the proposed new pixelclock field) quite a lot, and one question strikes me
here (please don't hate me): does userspace need to care about the
framesamples field ? It looks like the value is only used inside the kernel,
and we're relying on on userspace to propagate those values between subdevs.
If that's the case, wouldn't it be better to have an in-kernel API to handle
this ? I'm a bit concerned about forcing userspace to handle internal
information to userspace if there's no reason to do so.
What's the rationale between your solution, is there a need for the
framesamples information in userspace ?
paraDrivers automatically propagate formats inside sub-devices.
When a try or active format is set on a pad, corresponding formats on
other pads diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml
b/Documentation/DocBook/media/v4l/subdev-formats.xml index
49c532e..7c202a1 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -33,9 +33,16 @@
entryImage colorspace, from v4l2-colorspace;. See
xref linkend=colorspaces / for details./entry
/row
+ row id=v4l2-mbus-framefmt-framesamples
+ entry__u32/entry
+ entrystructfieldframesamples/structfield/entry
+ entryMaximum number of bus samples per frame for compressed data
+ formats. For uncompressed formats drivers and applications must
+ set this parameter to zero. /entry
+ /row
row
entry__u32/entry
- entrystructfieldreserved/structfield[7]/entry
+ entrystructfieldreserved/structfield[6]/entry
entryReserved for future extensions. Applications and drivers must
set the array to zero./entry
/row
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 5ea7f75..f18d6cd 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -101,6 +101,7 @@ enum v4l2_mbus_pixelcode {
* @code:data format code (from enum v4l2_mbus_pixelcode)
* @field: used interlacing type (from enum v4l2_field)
* @colorspace: colorspace of the data (from enum v4l2_colorspace)
+ * @framesamples: maximum number of bus samples per frame
*/
struct v4l2_mbus_framefmt {
__u32 width;
@@ -108,7 +109,8 @@ struct v4l2_mbus_framefmt {
__u32 code;
__u32
Re: V4L2 subdevice query
Hi Vinay,
On Monday 19 December 2011 21:08:31 vka...@codeaurora.org wrote:
I am trying to implement a video encoder v4l2 device and need your help to
find answers to some of the questions. There is one hardware core which can
do multiple sessions (multiple file handles) of encode simultaneously. The
encode functionalty needs to be exposed to userspace as well as kernel
through standard set of APIs. Userspace should be able to use this
functionality through V4l2 interface and another kernel module should be
able to use encoder as a subdevice. I am trying to explore the framework to
achieve this and have following questions:
1. I am planning to create a V4L2 device and also initializing it as a
subdev in the probe function i.e the probe function of this driver will
have:
struct venc_device {
struct v4l2_device v4l2_dev;
struct v4l2_subdev sd;
};
struct venc_device *vdev;
v4l2_device_register(vdev-v4l2_dev);
v4l2_subdev_init(vdev-sd, venc_sd_ops);
How do other modules discover this subdevice. Is there an API I can use
to find module by name?
2. Most of the subdevice interface functions have input parameters as
struct v4l2_subdev *sd and another API specific structure. How do I
distinguish between different instances (file handles) of a subdevice.
The short answer is that you don't.
If your hardware block can encode a fixed number of streams separately, one
possible solution would be to create N subdevices, or to create a single
subdevice with N input pads and N output pads, where N is the number of
logical streams. Input and output pads could then be connected to video nodes
or to other subdevices in the system.
Another solution is to use the mem-to-mem framework, which allows streams
multiplexing through multiple opens. However, there is no clear mapping to
subdevs (that I'm aware of) at the moment.
Can you share a bit more information about your hardware ? A block diagram
would be useful.
Do I always need to pass file handle/instance specific information in
void *arg of the ioctl subdev core ops.
3. Controls are instance specific, eg: one encoder application might encode
at bitrate of 4Mbps and another at 128kbps, so I want controls to be
specific to file handles. I see that the control handler has been moved
to v4l2_fh structure for this purpose. How do I do it for subdevices so
that the v4l2 device using this subdevice inherits the instance specific
controls defined by the subdevice.
--
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: query video dev node name using the V4L2 device driver name
Hi Mingcheng, On Monday 19 December 2011 19:09:18 Zhu, Mingcheng wrote: Hi Laurent, I have a problem here. Take following example that we have two video dev nodes as: /dev/video0: this node is for WIFI capture WIFI capture ? I'm curious about that, what do you mean exactly ? /dev/video1: this is the camera driver. Is it possible for the user space to find out video1 is the camera without open and query each video node's capabilities? If the drivers that expose those nodes are media-controller aware, one possible solution is to open the media controller device(s) and enumerate the entities. I'm not sure that would be faster than opening and querying the video nodes though. -- 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
Add signal information to xc4000 tuner
Documentation is included in patch, for now it will add signal level
only to analog FM radio for all xc4000 based tuner, but in the future
we can use this patch to get also digital signal level, measuring of
xc4000 tuner is very accurate (less then 1dB resolution).
This time with patch included :)
From 54428039e66870d85fef1c029dc4d019331439e6 Mon Sep 17 00:00:00 2001
From: Miroslav thunde...@email.cz
Date: Wed, 21 Dec 2011 01:18:38 +0100
Subject: [PATCH] In xc4000 chipsets real signal and noise level is stored in register 0x0A and 0x0B,
so we can use those registers to monitor signal strength.
I tested this patch on 2 different cards Leadtek DVR3200 and DTV2000H Plus, both
with same results, I used special antenna hubs (toner 4x, 6x, 8x and 12x) with mesured
signal lost, both registers are in dB value, first represent signal with limit
value -113.5dB (should be -114dB) and exactly match with test results. Second represents
noise level also in dB and there is no maximum value, but from tests we can drop
everything above 32dB which tuner realy can't use, signal was usable till 20dB noise level.
In digital mode we can take signal strength but sadly noise level is not relevant and
real value is stored in demodulator for now just zl10353, also digital mode is just for
testing, because it needs changing other parts of code which reads data only from
demodulator.
In analog mode I was able to test only FM radio, signal level is not important, it says
something about cable and hub losts, but nothing about real quality of reception, so even
if we have signal level at minimum 113dB we can still here radio, because of that it is
displaied only in debug mode, but for real signal level is used noise register which is
again very accurate, radio noise level was betwen 6-20dB for good signal, 20-25dB for
medium signal, and above 25dB signal is unusable.
For now real benefit of this patch is only for FM radio mode.
---
drivers/media/common/tuners/xc4000.c | 86 ++
1 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/drivers/media/common/tuners/xc4000.c b/drivers/media/common/tuners/xc4000.c
index 634f4d9..37581c3 100644
--- a/drivers/media/common/tuners/xc4000.c
+++ b/drivers/media/common/tuners/xc4000.c
@@ -154,6 +154,8 @@ struct xc4000_priv {
#define XREG_SNR 0x06
#define XREG_VERSION 0x07
#define XREG_PRODUCT_ID 0x08
+#define XREG_SIGNAL_LEVEL 0x0A
+#define XREG_NOISE_LEVEL 0x0B
/*
Basic firmware description. This will remain with
@@ -486,6 +488,16 @@ static int xc_get_quality(struct xc4000_priv *priv, u16 *quality)
return xc4000_readreg(priv, XREG_QUALITY, quality);
}
+static int xc_get_signal_level(struct xc4000_priv *priv, u16 *signal)
+{
+ return xc4000_readreg(priv, XREG_SIGNAL_LEVEL, signal);
+}
+
+static int xc_get_noise_level(struct xc4000_priv *priv, u16 *noise)
+{
+ return xc4000_readreg(priv, XREG_NOISE_LEVEL, noise);
+}
+
static u16 xc_wait_for_lock(struct xc4000_priv *priv)
{
u16 lock_state = 0;
@@ -1089,6 +1101,8 @@ static void xc_debug_dump(struct xc4000_priv *priv)
u32 hsync_freq_hz = 0;
u16 frame_lines;
u16 quality;
+ u16 signal = 0;
+ u16 noise = 0;
u8 hw_majorversion = 0, hw_minorversion = 0;
u8 fw_majorversion = 0, fw_minorversion = 0;
@@ -1119,6 +1133,12 @@ static void xc_debug_dump(struct xc4000_priv *priv)
xc_get_quality(priv, quality);
dprintk(1, *** Quality (0:8dB, 7:56dB) = %d\n, quality);
+
+ xc_get_signal_level(priv, signal);
+ dprintk(1, *** Signal level = -%ddB (%d)\n, signal 8, signal);
+
+ xc_get_noise_level(priv, noise);
+ dprintk(1, *** Noise level = %ddB (%d)\n, noise 8, noise);
}
static int xc4000_set_params(struct dvb_frontend *fe,
@@ -1451,6 +1471,71 @@ fail:
return ret;
}
+static int xc4000_get_signal(struct dvb_frontend *fe, u16 *strength)
+{
+ struct xc4000_priv *priv = fe-tuner_priv;
+ u16 value = 0;
+ int rc;
+
+ mutex_lock(priv-lock);
+ rc = xc4000_readreg(priv, XREG_SIGNAL_LEVEL, value);
+ mutex_unlock(priv-lock);
+
+ if (rc 0)
+ goto ret;
+
+ /* Informations from real testing of DVB-T and radio part,
+ coeficient for one dB is 0xff.
+ */
+ tuner_dbg(Signal strength: -%ddB (%05d)\n, value 8, value);
+
+ /* all known digital modes */
+ if ((priv-video_standard == XC4000_DTV6) ||
+ (priv-video_standard == XC4000_DTV7) ||
+ (priv-video_standard == XC4000_DTV7_8) ||
+ (priv-video_standard == XC4000_DTV8))
+ goto digital;
+
+ /* Analog mode has NOISE LEVEL important, signal
+ depends only on gain of antenna and amplifiers,
+ but it doesn't tell anything about real quality
+ of reception.
+ */
+ mutex_lock(priv-lock);
+ rc = xc4000_readreg(priv, XREG_NOISE_LEVEL, value);
+ mutex_unlock(priv-lock);
+
+ tuner_dbg(Noise level: %ddB (%05d)\n, value 8, value);
+
+ /* highest noise level: 32dB */
+ if (value = 0x2000) {
+ value = 0;
+ } else {
+ value = ~value 3;
+ }
+
+ goto ret;
+
+ /* Digital mode has SIGNAL LEVEL important and real
+
Re: [PATCH v4] v4l: Add driver for Micron MT9M032 camera sensor
Hi Martin, Thanks for the patch. On Saturday 17 December 2011 11:10:55 Martin Hostettler wrote: The MT9M032 is a parallel 1.6MP sensor from Micron controlled through I2C. The driver creates a V4L2 subdevice. It currently supports cropping, gain, exposure and v/h flipping controls in monochrome mode with an external pixel clock. There are still several small issues with this driver. Things like not using the module_i2c_driver() macro, some indentation, magic values in registers (I'm trying to get more documentation), PLL setup (although that can be fixed later, it's not a requirement for the driver to be mainlined), ... Would you be fine if I took the patch in my tree, fixed the remaining issues and pushed it to mainline for v3.4 (the time frame is too short for v3.3) ? Authorship will of course be preserved. The alternative would be to go through review/modification cycles, and I don't want to waste too much of your time :-) -- Best 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: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?
Hi Michael Laurent, On Thu, Dec 15, 2011 at 6:10 PM, Michael Jones michael.jo...@matrix-vision.de wrote: Hi James, Laurent has a program 'media-ctl' to set up the pipeline (see http://git.ideasonboard.org/?p=media-ctl.git). You will find many examples of its usage in the archives of this mailing list. It will look something like: media-ctl -r media-ctl -l 'OMAP3 ISP CCDC:1 - OMAP3 ISP CCDC output:0 [1]' media-ctl -l 'your-sensor-name:0 - OMAP3 ISP CCDC:0 [1]' you will also need to set the formats through the pipeline with 'media-ctl --set-format'. After you use media-ctl to set up the pipeline, you can use yavta to capture the data from the CCDC output (for me, this is /dev/video2). -Michael I encountered some obstacles with the driver testing of my monochrome sensor on top of Steve's 3.0-pm branch. An NXP SC16IS750 I2C-UART bridge is used to 'transform' the sensor into a I2C device. The PCLK, VSYNC, HSYNC (640x512, 30Hz, fixed output format) are free running upon power-on the sensor unlike MT9V032 which uses the XCLKA to 'power-on/off' it. My steps, 1) media-ctl -r -l 'mono640:0-OMAP3 ISP CCDC:0:[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Resetting all links to inactive Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] 2) media-ctl -f 'mono640:0[Y12 640x512], OMAP3 ISP CCDC:1[Y12 640x512]' Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/0 Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/1 3) yavta -p -f Y12 -s 640x512 -n 4 --capture=61 --skip 1 -F `media-ctl -e OMAP3 ISP CCDC output` --file=./DCIM/Y12 Unsupported video format 'Y12' Did I missed something? What parameters did you supplied to yavta to test the Y10/Y12 Many thanks in adv. Sorry if duplicated emails received. -- Regards, James -- 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: Why is the Y12 support 12-bit grey formats at the CCDC input (Y12) is truncated to Y10 at the CCDC output?
Hi Laurent Michael, On Wed, Dec 21, 2011 at 10:50 AM, James angweiy...@gmail.com wrote: Hi Michael Laurent, On Thu, Dec 15, 2011 at 6:10 PM, Michael Jones michael.jo...@matrix-vision.de wrote: Hi James, Laurent has a program 'media-ctl' to set up the pipeline (see http://git.ideasonboard.org/?p=media-ctl.git). You will find many examples of its usage in the archives of this mailing list. It will look something like: media-ctl -r media-ctl -l 'OMAP3 ISP CCDC:1 - OMAP3 ISP CCDC output:0 [1]' media-ctl -l 'your-sensor-name:0 - OMAP3 ISP CCDC:0 [1]' you will also need to set the formats through the pipeline with 'media-ctl --set-format'. After you use media-ctl to set up the pipeline, you can use yavta to capture the data from the CCDC output (for me, this is /dev/video2). -Michael I encountered some obstacles with the driver testing of my monochrome sensor on top of Steve's 3.0-pm branch. An NXP SC16IS750 I2C-UART bridge is used to 'transform' the sensor into a I2C device. The PCLK, VSYNC, HSYNC (640x512, 30Hz, fixed output format) are free running upon power-on the sensor unlike MT9V032 which uses the XCLKA to 'power-on/off' it. My steps, 1) media-ctl -r -l 'mono640:0-OMAP3 ISP CCDC:0:[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Resetting all links to inactive Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] 2) media-ctl -f 'mono640:0[Y12 640x512], OMAP3 ISP CCDC:1[Y12 640x512]' Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/0 Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/1 3) yavta -p -f Y12 -s 640x512 -n 4 --capture=61 --skip 1 -F `media-ctl -e OMAP3 ISP CCDC output` --file=./DCIM/Y12 Unsupported video format 'Y12' Did I missed something? What parameters did you supplied to yavta to test the Y10/Y12 Many thanks in adv. Sorry if duplicated emails received. -- Regards, James I changed the parameters for yavta from -f Y12 to -f Y16 yavta -p -f Y16 -s 640x512 -n 2 --capture=10 --skip 5 -F `media-ctl -e OMAP3 ISP CCDC output` --file=./DCIM/Y16 and there are 2 chunks of message at the console now and it ended with Unable to request buffers: Invalid argument (22).. I've attached the logfile here. (mono640.log) Hope you can assist me to grab the raw Y12 data to file. Many thanks in adv. -- Regards, James root@overo:media-ctl -r -v -l 'mono640:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Resetting all links to inactive Setting up link 16:0 - 5:0 [1] Setting up link 5:1 - 6:0 [1] root@overo:media-ctl -v -f 'mono640:0[Y12 640x512], OMAP3 ISP CCDC:1[SGRBG12 640x512]' Opening media device /dev/media0 Enumerating entities Found 16 entities Enumerating pads and links Setting up format Y12 640x512 on pad mono640 3-004d/0 Format set: Y12 640x512 Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/0 Format set: Y12 640x512 Setting up format Y12 640x512 on pad OMAP3 ISP CCDC/1 Format set: Y12 640x512 root@overo:yavta -p -f Y16 -s 640x512 -n 2 --capture=10 --skip 5 -F `media-ctl -e OMAP3 ISP CCDC output` --file=./DCIM/Y16 Device /dev/video2 opened. [ cut here ] WARNING: at drivers/media/video/omap3isp/ispvideo.c:218 isp_video_set_format+0x50/0x88 [omap3_isp]() Device `OMAP3 ISP CCDC output' on `media' is a video omaplfb capture device. Modules linked in: bufferclass_ti pvrsrvkm ipv6 mono640 libertas_sdio omap3_isp libertas v4l2_common cfg80211 videodev media lib80211 firmware_class ads7846 [c0045dc4] (unwind_backtrace+0x0/0x128) from [c006ba9c] (warn_slowpath_common+0x4c/0x64) [c006ba9c] (warn_slowpath_common+0x4c/0x64) from [c006bad0] (warn_slowpath_null+0x1c/0x24) [c006bad0] (warn_slowpath_null+0x1c/0x24) from [bf099e90] (isp_video_set_format+0x50/0x88 [omap3_isp]) [bf099e90] (isp_video_set_format+0x50/0x88 [omap3_isp]) from [bf01d778] (__video_do_ioctl+0x11a4/0x516c [videodev]) [bf01d778] (__video_do_ioctl+0x11a4/0x516c [videodev]) from [bf01c458] (video_usercopy+0x340/0x450 [videodev]) [bf01c458] (video_usercopy+0x340/0x450 [videodev]) from [bf01b448] (v4l2_ioctl+0x7c/0x12c [videodev]) [bf01b448] (v4l2_ioctl+0x7c/0x12c [videodev]) from [c00e4110] (do_vfs_ioctl+0x4b0/0x51c) [c00e4110] (do_vfs_ioctl+0x4b0/0x51c) from [c00e41b4] (sys_ioctl+0x38/0x5c) [c00e41b4] (sys_ioctl+0x38/0x5c) from [c0041240] (ret_fast_syscall+0x0/0x30) ---[ end trace 6824b735bee150b5 ]--- [ cut here ] WARNING: at drivers/media/video/omap3isp/ispvideo.c:178 isp_video_mbus_to_pix+0x78/0x144 [omap3_isp]() Modules linked in: bufferclass_ti omaplfb pvrsrvkm ipv6 mono640 libertas_sdio omap3_isp libertas v4l2_common cfg80211 videodev media lib80211 firmware_class ads7846 [c0045dc4] (unwind_backtrace+0x0/0x128) from [c006ba9c] (warn_slowpath_common+0x4c/0x64) [c006ba9c] (warn_slowpath_common+0x4c/0x64) from [c006bad0] (warn_slowpath_null+0x1c/0x24) [c006bad0]
[PATCH] v4l2: v4l2-fh: v4l2_fh_is_singular should use list head to test
list_is_singular accepts a list head to test whether a list has just one entry. fh-list is the entry, fh-vdev-fh_list is the list head. Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com --- drivers/media/video/v4l2-fh.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/v4l2-fh.c b/drivers/media/video/v4l2-fh.c index 9e3fc04..8292c4a 100644 --- a/drivers/media/video/v4l2-fh.c +++ b/drivers/media/video/v4l2-fh.c @@ -113,7 +113,7 @@ int v4l2_fh_is_singular(struct v4l2_fh *fh) if (fh == NULL || fh-vdev == NULL) return 0; spin_lock_irqsave(fh-vdev-fh_lock, flags); - is_singular = list_is_singular(fh-list); + is_singular = list_is_singular(fh-vdev-fh_list); spin_unlock_irqrestore(fh-vdev-fh_lock, flags); return is_singular; } -- 1.7.0.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: [GIT PULL FOR 3.3] HDIC HD29L2 DMB-TH demodulator driver
On 12/21/2011 12:35 AM, Michael Krufky wrote:
On Tue, Dec 20, 2011 at 10:26 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
On 20-12-2011 12:52, Antti Palosaari wrote:
+/* reset demod */
+/* it is recommended to HW reset chip using RST_N pin */
+if (fe-callback) {
+ret = fe-callback(fe, 0, 0, 0);
This looks weird on my eyes. The fe-callback is tuner-dependent.
So, the command you should use there requires a test for the tuner
type.
In other words, if you're needing to use it, the code should be doing
something similar to:
if (fe-callbackpriv-tuner_type == TUNER_XC2028)
ret = fe-callback(fe, 0, XC2028_TUNER_RESET, 0);
(the actual coding will depend on how do you store the tuner type, and
what are the commands for the tuner you're using)
That's said, it probably makes sense to deprecate fe-callback in favor
or a more generic set of callbacks, like fe-tuner_reset().
Yes it is wrong because there was no DEMOD defined. But, the callback
itself is correctly. IIRC there was only TUNER defined and no DEMOD.
Look callback definition from the API. It is very simply to fix. But at
the time left it like that, because I wanted to avoid touching one file
more. I will fix it properly later (2 line change).
And it was not a bug, it was just my known decision. I just forget to comment
it as FIXME or TODO.
Feel free to touch on other files, provided that you fix that. There's
no default behavior for fe-callback, as it were written in order to
provide ways for the tuner to call the bridge driver for some device-specific
reasons. So, the commands are defined with macros, and the callback code
should be device-specific.
This generic callback was written for the BRIDGE driver to be called
by any frontend COMPONENT, not specifically the tuner, perhaps a demod
or LNB, but at the time of writing, we only needed it from the tuner
so the DVB_FRONTEND_COMPONENT_TUNER(0) was the only #define created at
the time. This was written with forward-compatibility in mind, so
lets please not deprecate it unless we actually have to -- I see
additional uses for this coming in the future.
In order to use fe callback properly, please add #define
DVB_FRONTEND_COMPONENT_DEMOD 1 to dvb-core/dvb_frontend.h , and
simply call your callback as fe-callback(adap_state,
DVB_FRONTEND_COMPONENT_DEMOD, CMD, ARG) ... This way, the callback
knows that it is being called by the demod and not the tuner, it is
receiving command CMD with argument ARG.
I can imagine a need one day to perhaps convert the int arg into a
void* arg, but such a need doesn't exist today. I don't think it
gets any more generic than this.
int (*callback)(void *adapter_priv, int component, int cmd, int arg);
Cheers,
Mike
+1 for that. It was just what I also was thinking :) I will add that
demod component define to the internal API and it is fixed properly.
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] qt1010: Fix tuner frequency selection for 546 to 578 MHz range
Hello, You can try to fix it like that, but it is not proper way. It is kinda of hack which can just work or not. Proper way is to fix that tuner driver correctly and if it was used with zl10353 demoed fix that driver too to support IIRC IF/RF agc settings. regards Antti On 12/20/2011 12:50 PM, Carlos Corbacho wrote: The patch fixes frequency selection for some UHF frequencies e.g. channel 32 (562 MHz) on the qt1010 tuner. For those in the UK, this now means they can tune to the BBC channels (tested on a Compro Vista T750F). One example of problem reports of the bug this fixes can be read at http://www.freak-search.com/de/thread/330303/linux-dvb_tuning_problem_with_some_frequencies_qt1010,_dvb Based on an original patch by Jyrki Kuoppalaj...@iki.fi Signed-off-by: Carlos Corbachocar...@strangeworlds.co.uk Cc: Jyrki Kuoppalaj...@iki.fi Cc: Mauro Carvalho Chehabmche...@infradead.org --- drivers/media/common/tuners/qt1010.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/media/common/tuners/qt1010.c b/drivers/media/common/tuners/qt1010.c index 9f5dba2..8c57d8c 100644 --- a/drivers/media/common/tuners/qt1010.c +++ b/drivers/media/common/tuners/qt1010.c @@ -200,7 +200,8 @@ static int qt1010_set_params(struct dvb_frontend *fe, if (freq 45000) rd[15].val = 0xd0; /* 450 MHz */ else if (freq 48200) rd[15].val = 0xd1; /* 482 MHz */ else if (freq 51400) rd[15].val = 0xd4; /* 514 MHz */ - else if (freq 54600) rd[15].val = 0xd7; /* 546 MHz */ + else if (freq 54600) rd[15].val = 0xd6; /* 546 MHz */ + else if (freq 57800) rd[15].val = 0xd8; /* 578 MHz */ else if (freq 61000) rd[15].val = 0xda; /* 610 MHz */ else rd[15].val = 0xd0; -- 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: [PATCH v4] v4l: Add driver for Micron MT9M032 camera sensor
On Wed, Dec 21, 2011 at 02:06:20AM +0100, Laurent Pinchart wrote: Hi Martin, Thanks for the patch. On Saturday 17 December 2011 11:10:55 Martin Hostettler wrote: The MT9M032 is a parallel 1.6MP sensor from Micron controlled through I2C. The driver creates a V4L2 subdevice. It currently supports cropping, gain, exposure and v/h flipping controls in monochrome mode with an external pixel clock. There are still several small issues with this driver. Things like not using the module_i2c_driver() macro, some indentation, magic values in registers (I'm trying to get more documentation), PLL setup (although that can be fixed later, it's not a requirement for the driver to be mainlined), ... Would you be fine if I took the patch in my tree, fixed the remaining issues and pushed it to mainline for v3.4 (the time frame is too short for v3.3) ? Sure, that would be much appreciated. Thanks for reviewing and takeing these patches! Best regards, - Martin Hostettler Authorship will of course be preserved. The alternative would be to go through review/modification cycles, and I don't want to waste too much of your time :-) -- Best 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
