cx23885: DVBSky S952 dvb_register failed err = -22
Hi, using linux-3.19.1-1 (Archlinux) I get the following output while booting without the media-build-tree provided by DVBSky: cx23885 driver version 0.0.4 loaded cx23885 :04:00.0: enabling device ( - 0002) CORE cx23885[0]: subsystem: 4254:0952, board: DVBSky S952 [card=50,autodetected] cx25840 3-0044: cx23885 A/V decoder found @ 0x88 (cx23885[0]) cx25840 3-0044: loaded v4l-cx23885-avcore-01.fw firmware (16382 bytes) cx23885_dvb_register() allocating 1 frontend(s) cx23885[0]: cx23885 based dvb card i2c i2c-2: m88ds3103_attach: chip_id=70 i2c i2c-2: Added multiplexed i2c bus 4 cx23885_dvb_register() dvb_register failed err = -22 cx23885_dev_setup() Failed to register dvb adapters on VID_B cx23885_dvb_register() allocating 1 frontend(s) cx23885[0]: cx23885 based dvb card i2c i2c-1: m88ds3103_attach: chip_id=70 i2c i2c-1: Added multiplexed i2c bus 4 cx23885_dvb_register() dvb_register failed err = -22 cx23885_dev_setup() Failed to register dvb on VID_C cx23885_dev_checkrevision() Hardware revision = 0xa5 cx23885[0]/0: found at :04:00.0, rev: 4, irq: 17, latency: 0, mmio: 0xf720 Obviously there are no device in /dev/dvb. Using the media-build-tree works just fine though. The following firmware files are installed in /usr/lib/firmware: dvb-demod-m88ds3103.fw dvb-demod-m88rs6000.fw dvb-demod-si2168-a20-01.fw dvb-demod-si2168-a30-01.fw dvb-demod-si2168-b40-01.fw dvb-fe-ds300x.fw dvb-fe-ds3103.fw dvb-fe-rs6000.fw dvb-tuner-si2158-a20-01.fw Output of lspci -vvvnn: https://gist.githubusercontent.com/olebowle/6a4108363a9d1f7dd033/raw/lscpi I also set the module parameters debug, i2c_debug, irq_debug and irq_debug in cx23885. The output is pretty verbose and can be found here: https://gist.githubusercontent.com/olebowle/6a4108363a9d1f7dd033/raw/debug.log Thanks, Ole -- 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] v4l2-ioctl: allow all controls if ctrl_class == 0
On Sat, Mar 14, 2015 at 05:28:25PM +0100, Hans Verkuil wrote: The check_ext_ctrls() function in v4l2-ioctl.c checks if all controls in the control array are from the same control class as c-ctrl_class. However, that check should only be done if c-ctrl_class != 0. A 0 value means that this restriction does not apply. So return 1 (OK) if c-ctrl_class == 0. Found by running v4l2-compliance on the uvc driver. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Sakari Ailus sakari.ai...@linux.intel.com -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] v4l: mt9v032: Add OF support
Hi Laurent,
On Sat, Mar 14, 2015 at 04:57:37PM +0200, Laurent Pinchart wrote:
...
diff --git a/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
new file mode 100644
index 000..68b134e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
@@ -0,0 +1,45 @@
+* Aptina 1/3-Inch WVGA CMOS Digital Image Sensor
+
+The Aptina MT9V032 is a 1/3-inch CMOS active pixel digital image sensor with
+an active array size of 752H x 480V. It is programmable through a simple
+two-wire serial interface.
+
+Required Properties:
+
+- compatible: value should be either one among the following
+ (a) aptina,mt9v022 for MT9V022 color sensor
+ (b) aptina,mt9v022m for MT9V022 monochrome sensor
+ (c) aptina,mt9v024 for MT9V024 color sensor
+ (d) aptina,mt9v024m for MT9V024 monochrome sensor
+ (e) aptina,mt9v032 for MT9V032 color sensor
+ (f) aptina,mt9v032m for MT9V032 monochrome sensor
+ (g) aptina,mt9v034 for MT9V034 color sensor
+ (h) aptina,mt9v034m for MT9V034 monochrome sensor
+
+Optional Properties:
+
+- link-frequencies: List of allowed link frequencies in Hz. Each frequency is
+ expressed as a 64-bit big-endian integer.
+
+For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ mt9v032@5c {
+ compatible = aptina,mt9v032;
+ reg = 0x5c;
+
+ port {
+ mt9v032_1: endpoint {
+ link-frequencies =
+ 0 1300, 0 2660,
How about:
/bits/ 64 1300 ...
+ 0 2700;
+ };
+ };
+ };
+ ...
+ };
diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
index 255ea91..139eeef 100644
--- a/drivers/media/i2c/mt9v032.c
+++ b/drivers/media/i2c/mt9v032.c
@@ -17,6 +17,8 @@
#include linux/i2c.h
#include linux/log2.h
#include linux/mutex.h
+#include linux/of.h
+#include linux/of_gpio.h
#include linux/regmap.h
#include linux/slab.h
#include linux/videodev2.h
@@ -26,6 +28,7 @@
#include media/mt9v032.h
#include media/v4l2-ctrls.h
#include media/v4l2-device.h
+#include media/v4l2-of.h
#include media/v4l2-subdev.h
/* The first four rows are black rows. The active area spans 753x481 pixels.
*/
@@ -876,10 +879,59 @@ static const struct regmap_config mt9v032_regmap_config
= {
* Driver initialization and probing
*/
+static struct mt9v032_platform_data *
+mt9v032_get_pdata(struct i2c_client *client)
+{
+ struct mt9v032_platform_data *pdata;
+ struct v4l2_of_endpoint endpoint;
+ struct device_node *np;
+ struct property *prop;
+
+ if (!IS_ENABLED(CONFIG_OF) || !client-dev.of_node)
+ return client-dev.platform_data;
+
+ np = of_graph_get_next_endpoint(client-dev.of_node, NULL);
+ if (!np)
+ return NULL;
+
+ if (v4l2_of_parse_endpoint(np, endpoint) 0)
+ goto done;
+
+ pdata = devm_kzalloc(client-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ goto done;
+
+ prop = of_find_property(np, link-frequencies, NULL);
+ if (prop) {
+ size_t size = prop-length / 8;
+ u64 *link_freqs;
+
+ link_freqs = devm_kzalloc(client-dev,
+ size * sizeof(*link_freqs),
You could simply use prop-length here. I think that'd look nicer.
+ GFP_KERNEL);
+ if (!link_freqs)
+ goto done;
+
+ if (of_property_read_u64_array(np, link-frequencies,
+link_freqs, size) 0)
+ goto done;
+
+ pdata-link_freqs = link_freqs;
+ pdata-link_def_freq = link_freqs[0];
+ }
+
+ pdata-clk_pol = !!(endpoint.bus.parallel.flags
+ V4L2_MBUS_PCLK_SAMPLE_RISING);
+
+done:
+ of_node_put(np);
+ return pdata;
+}
+
static int mt9v032_probe(struct i2c_client *client,
const struct i2c_device_id *did)
{
- struct mt9v032_platform_data *pdata = client-dev.platform_data;
+ struct mt9v032_platform_data *pdata = mt9v032_get_pdata(client);
struct mt9v032 *mt9v032;
unsigned int i;
int ret;
@@ -1037,9 +1089,25 @@ static const struct i2c_device_id mt9v032_id[] = {
};
MODULE_DEVICE_TABLE(i2c, mt9v032_id);
+#if IS_ENABLED(CONFIG_OF)
+static const struct of_device_id mt9v032_of_match[] = {
+ { .compatible = aptina,mt9v022 },
+ { .compatible = aptina,mt9v022m },
+ { .compatible =
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sun Mar 15 04:00:17 CET 2015 git branch: test git hash: 3d945be05ac1e806af075e9315bc1b3409adae2b gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.19.0-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-rc1-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: au0828 - add vidq busy checks to s_std and s_input
On 03/14/2015 03:18 AM, Shuah Khan wrote:
au0828 s_std and s_input are missing queue busy checks. Add
vb2_is_busy() calls to s_std and s_input and return -EBUSY
if found busy.
I agree with Devin that for this particular driver this patch isn't necessary.
Regards,
Hans
Signed-off-by: Shuah Khan shua...@osg.samsung.com
---
drivers/media/usb/au0828/au0828-video.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/media/usb/au0828/au0828-video.c
b/drivers/media/usb/au0828/au0828-video.c
index f47ee90..42c49c2 100644
--- a/drivers/media/usb/au0828/au0828-video.c
+++ b/drivers/media/usb/au0828/au0828-video.c
@@ -1214,6 +1214,11 @@ static int vidioc_s_std(struct file *file, void *priv,
v4l2_std_id norm)
if (norm == dev-std)
return 0;
+ if (vb2_is_busy(dev-vb_vidq)) {
+ pr_info(%s queue busy\n, __func__);
+ return -EBUSY;
+ }
+
if (dev-streaming_users 0)
return -EBUSY;
@@ -1364,6 +1369,14 @@ static int vidioc_s_input(struct file *file, void
*priv, unsigned int index)
return -EINVAL;
if (AUVI_INPUT(index).type == 0)
return -EINVAL;
+ /*
+ * Changing the input implies a format change, which is not allowed
+ * while buffers for use with streaming have already been allocated.
+ */
+ if (vb2_is_busy(dev-vb_vidq)) {
+ pr_info(%s queue busy\n, __func__);
+ return -EBUSY;
+ }
dev-ctrl_input = index;
au0828_s_input(dev, index);
return 0;
--
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: [PATCHv2 00/21] marvell-ccic: drop and fix formats
On 03/13/2015 10:59 PM, Hans Verkuil wrote: Hi Jon, On 03/13/2015 10:28 PM, Jonathan Corbet wrote: On Wed, 11 Mar 2015 09:10:24 +0100 Hans Verkuil hverk...@xs4all.nl wrote: After some more testing I realized that the 422P format produced wrong colors and I couldn't get it to work. Since it never worked and nobody complained about it (and it is a fairly obscure format as well) I've dropped it. I'm not sure how that format came in anymore; I didn't add it. No objections to its removal. It came in with the patches from Marvell. I also tested RGB444 format for the first time, and that had wrong colors as well, but that was easy to fix. Finally there was a Bayer format reported, but it was never implemented. So that too was dropped. The RGB444 change worries me somewhat; that was the default format on the XO1 and worked for years. I vaguely remember some discussions about the ordering of the colors there, but that was a while ago. Did you test it with any of the Sugar apps? I've tested with the 'Record' app, and that picks a YUV format, not RGB444. Are there other apps that I can test with where you can select the capture format? Urgh. I did some more digging and this driver really supported a big endian version of RGB444. So the description in the documentation of the RGB444 format and what this driver returns is different. It looks like Michael Schimek's question regarding endianness went unanswered: http://www.spinics.net/lists/vfl/msg28921.html He probably assumed the same order as for RGB555/565 formats. I have three options: 1) fix the driver as I did in my patch so RGB444 follows the documentation. 2) add a new RGB444X big endian pixel format and switch the driver to that. So RGB444 is no longer supported, instead RGB444X is now supported. Apps will have to change PIX_FMT_RGB444 to PIX_FMT_RGB444X. 3) add support for both RGB444 and RGB444X to the driver. Note that it is not possible to change the RGB444 documentation since this format is used in other drivers as well, and there it is in proper little endian format. I am actually favoring option 2, since that prevents current applications using RGB444 from working with the new kernel, but it is easy to fix by changing RGB444 to RGB444X. OLPC specific apps can even just assume that RGB444 and RGB444X are the same, and so they will work with both the new and old driver. Let me know what you prefer. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 00/21] marvell-ccic: drop and fix formats
On 03/14/2015 10:15 AM, Hans Verkuil wrote: On 03/13/2015 10:59 PM, Hans Verkuil wrote: Hi Jon, On 03/13/2015 10:28 PM, Jonathan Corbet wrote: On Wed, 11 Mar 2015 09:10:24 +0100 Hans Verkuil hverk...@xs4all.nl wrote: After some more testing I realized that the 422P format produced wrong colors and I couldn't get it to work. Since it never worked and nobody complained about it (and it is a fairly obscure format as well) I've dropped it. I'm not sure how that format came in anymore; I didn't add it. No objections to its removal. It came in with the patches from Marvell. I also tested RGB444 format for the first time, and that had wrong colors as well, but that was easy to fix. Finally there was a Bayer format reported, but it was never implemented. So that too was dropped. The RGB444 change worries me somewhat; that was the default format on the XO1 and worked for years. I vaguely remember some discussions about the ordering of the colors there, but that was a while ago. Did you test it with any of the Sugar apps? I've tested with the 'Record' app, and that picks a YUV format, not RGB444. Are there other apps that I can test with where you can select the capture format? Urgh. I did some more digging and this driver really supported a big endian version of RGB444. So the description in the documentation of the RGB444 format and what this driver returns is different. OK, after some more research it turns out that it is not actually the big endian format at all. This is the actual format compared to RGB444 and big endian RGB444: Byte 0 in memoryByte 1 in memory RGB444 RGB444 BE Marvell RGB444 Basically RGB444 but with R and B reversed. It looks like Michael Schimek's question regarding endianness went unanswered: http://www.spinics.net/lists/vfl/msg28921.html He probably assumed the same order as for RGB555/565 formats. I have three options: 1) fix the driver as I did in my patch so RGB444 follows the documentation. 2) add a new RGB444X big endian pixel format and switch the driver to that. So RGB444 is no longer supported, instead RGB444X is now supported. Apps will have to change PIX_FMT_RGB444 to PIX_FMT_RGB444X. 3) add support for both RGB444 and RGB444X to the driver. I stick with this proposal, except instead of an RGB444X (big endian) version I create a BGR444 format. BTW, I'm using this code written for the OLPC as a reference as to what apps expect: https://bitbucket.org/pygame/pygame/src/db67108d6a8e6064884549f471c22fab21bdbfa6/src/_camera.c?at=default At line 491-495 it is clear what format is expected. Regards, Hans Note that it is not possible to change the RGB444 documentation since this format is used in other drivers as well, and there it is in proper little endian format. I am actually favoring option 2, since that prevents current applications using RGB444 from working with the new kernel, but it is easy to fix by changing RGB444 to RGB444X. OLPC specific apps can even just assume that RGB444 and RGB444X are the same, and so they will work with both the new and old driver. Let me know what you prefer. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 15/18] omap3isp: Add support for the Device Tree
Hi Laurent, On Thu, Mar 12, 2015 at 01:48:02AM +0200, Laurent Pinchart wrote: Hi Sakari, Thank you for the patch. On Saturday 07 March 2015 23:41:12 Sakari Ailus wrote: Add the ISP device to omap3 DT include file and add support to the driver to use it. Also obtain information on the external entities and the ISP configuration related to them through the Device Tree in addition to the platform data. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- drivers/media/platform/omap3isp/isp.c | 206 ++-- drivers/media/platform/omap3isp/isp.h | 11 ++ drivers/media/platform/omap3isp/ispcsiphy.c |7 + 3 files changed, 213 insertions(+), 11 deletions(-) [snip] @@ -2358,14 +2541,6 @@ static int isp_probe(struct platform_device *pdev) isp-mmio_hist_base_phys = mem-start + isp_res_maps[m].offset[OMAP3_ISP_IOMEM_HIST]; - isp-syscon = syscon_regmap_lookup_by_pdevname(syscon.0); - isp-syscon_offset = isp_res_maps[m].syscon_offset; You're removing syscon_offset initialization here but not adding it anywhere else. This patch doesn't match the commit in your rm696-053-upstream branch, could you send the right version ? I'll then review it. Yeah, there have been quite a few changes since I posted this RFC set, this including. I'll post a new version once I've been able to take into account all the comments I've got so far. It'd be nice if someone could test the pdata support; I haven't had a chance to do that in a few years now. :-) -- Cheers, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] vivid: allow s_dv_timings if it is the same as the current
Allow setting the same timings as the current timings (i.e., do nothing in that case). The code was actually there, but the vb2_is_busy() call was done before the timings check instead of afterwards. Found by v4l2-compliance. Signed-off-by: Hans Verkuil hans.verk...@cisco.com diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c b/drivers/media/platform/vivid/vivid-vid-cap.c index 1d9ea2d..c942bf7 100644 --- a/drivers/media/platform/vivid/vivid-vid-cap.c +++ b/drivers/media/platform/vivid/vivid-vid-cap.c @@ -1585,13 +1585,13 @@ int vivid_vid_cap_s_dv_timings(struct file *file, void *_fh, if (!vivid_is_hdmi_cap(dev)) return -ENODATA; - if (vb2_is_busy(dev-vb_vid_cap_q)) - return -EBUSY; if (!v4l2_find_dv_timings_cap(timings, vivid_dv_timings_cap, 0, NULL, NULL)) return -EINVAL; if (v4l2_match_dv_timings(timings, dev-dv_timings_cap, 0)) return 0; + if (vb2_is_busy(dev-vb_vid_cap_q)) + return -EBUSY; dev-dv_timings_cap = *timings; vivid_update_format_cap(dev, false); return 0; diff --git a/drivers/media/platform/vivid/vivid-vid-out.c b/drivers/media/platform/vivid/vivid-vid-out.c index 917cc69..5782b7d 100644 --- a/drivers/media/platform/vivid/vivid-vid-out.c +++ b/drivers/media/platform/vivid/vivid-vid-out.c @@ -1125,13 +1125,13 @@ int vivid_vid_out_s_dv_timings(struct file *file, void *_fh, if (!vivid_is_hdmi_out(dev)) return -ENODATA; - if (vb2_is_busy(dev-vb_vid_out_q)) - return -EBUSY; if (!v4l2_find_dv_timings_cap(timings, vivid_dv_timings_cap, 0, NULL, NULL)) return -EINVAL; if (v4l2_match_dv_timings(timings, dev-dv_timings_out, 0)) return 0; + if (vb2_is_busy(dev-vb_vid_out_q)) + return -EBUSY; dev-dv_timings_out = *timings; vivid_update_format_out(dev); return 0; -- 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
[PATCHv3 19/22] marvell-ccic: drop support for PIX_FMT_422P
From: Hans Verkuil hans.verk...@cisco.com
I cannot get this format to work, the colors keep coming out wrong.
Since this has never worked I just drop support for this.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/platform/marvell-ccic/mcam-core.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 3f016fb..5b60da1 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -124,13 +124,6 @@ static struct mcam_format_struct {
.planar = false,
},
{
- .desc = YUV 4:2:2 PLANAR,
- .pixelformat= V4L2_PIX_FMT_YUV422P,
- .mbus_code = MEDIA_BUS_FMT_YUYV8_2X8,
- .bpp= 1,
- .planar = true,
- },
- {
.desc = YUV 4:2:0 PLANAR,
.pixelformat= V4L2_PIX_FMT_YUV420,
.mbus_code = MEDIA_BUS_FMT_YUYV8_2X8,
@@ -352,10 +345,6 @@ static void mcam_write_yuv_bases(struct mcam_camera *cam,
y = base;
switch (fmt-pixelformat) {
- case V4L2_PIX_FMT_YUV422P:
- u = y + pixel_count;
- v = u + pixel_count / 2;
- break;
case V4L2_PIX_FMT_YUV420:
u = y + pixel_count;
v = u + pixel_count / 4;
@@ -755,7 +744,6 @@ static void mcam_ctlr_image(struct mcam_camera *cam)
widthy = fmt-width * 2;
widthuv = 0;
break;
- case V4L2_PIX_FMT_YUV422P:
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
widthy = fmt-width;
@@ -776,10 +764,6 @@ static void mcam_ctlr_image(struct mcam_camera *cam)
* Tell the controller about the image format we are using.
*/
switch (fmt-pixelformat) {
- case V4L2_PIX_FMT_YUV422P:
- mcam_reg_write_mask(cam, REG_CTRL0,
- C0_DF_YUV | C0_YUV_PLANAR | C0_YUVE_YVYU, C0_DF_MASK);
- break;
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
mcam_reg_write_mask(cam, REG_CTRL0,
@@ -1373,9 +1357,6 @@ static int mcam_vidioc_try_fmt_vid_cap(struct file *filp,
void *priv,
v4l2_fill_pix_format(pix, mbus_fmt);
pix-bytesperline = pix-width * f-bpp;
switch (f-pixelformat) {
- case V4L2_PIX_FMT_YUV422P:
- pix-sizeimage = pix-height * pix-bytesperline * 2;
- break;
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
pix-sizeimage = pix-height * pix-bytesperline * 3 / 2;
--
2.1.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
[PATCHv3 18/22] marvell-ccic: fix Y'CbCr ordering
From: Hans Verkuil hans.verk...@cisco.com
Various formats had their byte ordering implemented incorrectly, and
the V4L2_PIX_FMT_UYVY is actually impossible to create, instead you
get V4L2_PIX_FMT_YVYU.
This was working before commit ad6ac452227b7cb93ac79beec092850d178740b1
(add new formats support for marvell-ccic driver). That commit broke
the original format support and the OLPC XO-1 laptop showed wrong
colors ever since (if you are crazy enough to attempt to run the latest
kernel on it, like I did).
The email addresses of the authors of that patch are no longer valid,
so without a way to reach them and ask them about their test setup
I am going with what I can test on the OLPC laptop.
If this breaks something for someone on their non-OLPC setup, then
contact the linux-media mailinglist. My suspicion however is that
that commit went in untested.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Acked-by: Jonathan Corbet cor...@lwn.net
---
drivers/media/platform/marvell-ccic/mcam-core.c | 14 +++---
drivers/media/platform/marvell-ccic/mcam-core.h | 8
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 9343051..3f016fb 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -117,8 +117,8 @@ static struct mcam_format_struct {
.planar = false,
},
{
- .desc = UYVY 4:2:2,
- .pixelformat= V4L2_PIX_FMT_UYVY,
+ .desc = YVYU 4:2:2,
+ .pixelformat= V4L2_PIX_FMT_YVYU,
.mbus_code = MEDIA_BUS_FMT_YUYV8_2X8,
.bpp= 2,
.planar = false,
@@ -751,7 +751,7 @@ static void mcam_ctlr_image(struct mcam_camera *cam)
switch (fmt-pixelformat) {
case V4L2_PIX_FMT_YUYV:
- case V4L2_PIX_FMT_UYVY:
+ case V4L2_PIX_FMT_YVYU:
widthy = fmt-width * 2;
widthuv = 0;
break;
@@ -783,15 +783,15 @@ static void mcam_ctlr_image(struct mcam_camera *cam)
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
mcam_reg_write_mask(cam, REG_CTRL0,
- C0_DF_YUV | C0_YUV_420PL | C0_YUVE_YVYU, C0_DF_MASK);
+ C0_DF_YUV | C0_YUV_420PL | C0_YUVE_VYUY, C0_DF_MASK);
break;
case V4L2_PIX_FMT_YUYV:
mcam_reg_write_mask(cam, REG_CTRL0,
- C0_DF_YUV | C0_YUV_PACKED | C0_YUVE_UYVY, C0_DF_MASK);
+ C0_DF_YUV | C0_YUV_PACKED | C0_YUVE_NOSWAP, C0_DF_MASK);
break;
- case V4L2_PIX_FMT_UYVY:
+ case V4L2_PIX_FMT_YVYU:
mcam_reg_write_mask(cam, REG_CTRL0,
- C0_DF_YUV | C0_YUV_PACKED | C0_YUVE_YUYV, C0_DF_MASK);
+ C0_DF_YUV | C0_YUV_PACKED | C0_YUVE_SWAP24, C0_DF_MASK);
break;
case V4L2_PIX_FMT_RGB444:
mcam_reg_write_mask(cam, REG_CTRL0,
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.h
b/drivers/media/platform/marvell-ccic/mcam-core.h
index 2847e06..97167f6 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.h
+++ b/drivers/media/platform/marvell-ccic/mcam-core.h
@@ -331,10 +331,10 @@ int mccic_resume(struct mcam_camera *cam);
#define C0_YUVE_YVYU0x0001/* Y1CrY0Cb */
#define C0_YUVE_VYUY0x0002/* CrY1CbY0 */
#define C0_YUVE_UYVY0x0003/* CbY1CrY0 */
-#define C0_YUVE_XYUV0x/* 420: .YUV*/
-#define C0_YUVE_XYVU0x0001/* 420: .YVU*/
-#define C0_YUVE_XUVY0x0002/* 420: .UVY*/
-#define C0_YUVE_XVUY0x0003/* 420: .VUY*/
+#define C0_YUVE_NOSWAP 0x/* no bytes swapping*/
+#define C0_YUVE_SWAP13 0x0001/* swap byte 1 and 3*/
+#define C0_YUVE_SWAP24 0x0002/* swap byte 2 and 4*/
+#define C0_YUVE_SWAP1324 0x0003 /* swap bytes 13 and 24 */
/* Bayer bits 18,19 if needed */
#define C0_EOF_VSYNC0x0040/* Generate EOF by VSYNC */
#define C0_VEDGE_CTRL 0x0080/* Detect falling edge of VSYNC
*/
--
2.1.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
[PATCHv3 20/22] videodev2.h: add V4L2_PIX_FMT_XBGR444
From: Hans Verkuil hans.verk...@cisco.com
This is similar to XRGB444 but with the red and blue components swapped. It
turns out that the RGB444 format in marvell-ccic driver really was this
variant, so we need a proper definition of that.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
.../DocBook/media/v4l/pixfmt-packed-rgb.xml| 22 ++
include/uapi/linux/videodev2.h | 7 ---
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
index 6ab4f0f..cd6cc81 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
@@ -171,6 +171,28 @@ for a pixel lie next to each other in memory./para
entryrsubscript1/subscript/entry
entryrsubscript0/subscript/entry
/row
+ row id=V4L2-PIX-FMT-XBGR444
+ entryconstantV4L2_PIX_FMT_XBGR444/constant/entry
+ entry'XB12'/entry
+ entry/entry
+ entryg/entry
+ entryg/entry
+ entryg/entry
+ entryg/entry
+ entryrsubscript3/subscript/entry
+ entryrsubscript2/subscript/entry
+ entryrsubscript1/subscript/entry
+ entryrsubscript0/subscript/entry
+ entry/entry
+ entry-subscript3/subscript/entry
+ entry-subscript2/subscript/entry
+ entry-subscript1/subscript/entry
+ entry-subscript0/subscript/entry
+ entrybsubscript3/subscript/entry
+ entrybsubscript2/subscript/entry
+ entrybsubscript1/subscript/entry
+ entrybsubscript0/subscript/entry
+ /row
row id=V4L2-PIX-FMT-ARGB555
entryconstantV4L2_PIX_FMT_ARGB555/constant/entry
entry'AR15'/entry
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index fbdc360..0b015c1 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -375,9 +375,10 @@ struct v4l2_pix_format {
/* RGB formats */
#define V4L2_PIX_FMT_RGB332 v4l2_fourcc('R', 'G', 'B', '1') /* 8 RGB-3-3-2
*/
-#define V4L2_PIX_FMT_RGB444 v4l2_fourcc('R', '4', '4', '4') /* 16
*/
-#define V4L2_PIX_FMT_ARGB444 v4l2_fourcc('A', 'R', '1', '2') /* 16
*/
-#define V4L2_PIX_FMT_XRGB444 v4l2_fourcc('X', 'R', '1', '2') /* 16
*/
+#define V4L2_PIX_FMT_RGB444 v4l2_fourcc('R', '4', '4', '4') /* 16 RGB-4-4-4
*/
+#define V4L2_PIX_FMT_ARGB444 v4l2_fourcc('A', 'R', '1', '2') /* 16
RGB-4-4-4-4 */
+#define V4L2_PIX_FMT_XRGB444 v4l2_fourcc('X', 'R', '1', '2') /* 16
RGB-4-4-4-4 */
+#define V4L2_PIX_FMT_XBGR444 v4l2_fourcc('X', 'B', '1', '2') /* 16
BGR-4-4-4-4 */
#define V4L2_PIX_FMT_RGB555 v4l2_fourcc('R', 'G', 'B', 'O') /* 16 RGB-5-5-5
*/
#define V4L2_PIX_FMT_ARGB555 v4l2_fourcc('A', 'R', '1', '5') /* 16
ARGB-1-5-5-5 */
#define V4L2_PIX_FMT_XRGB555 v4l2_fourcc('X', 'R', '1', '5') /* 16
XRGB-1-5-5-5 */
--
2.1.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
[PATCHv3 00/22] marvell-ccic: drop and fix formats
This v3 patch series replaces patch 18 from the first series. Patch 18 and 19 are unchanged from patches 18 and 21 from the second series. Patches 20-21 replace the RGB444 format by the newly defined XBGR444 format (X means that the 'alpha' channel should be ignored and is not filled in). The actual layout in memory remains unchanged. Patch 22 fixes the Bayer format. All tested on my OLPC XO-1 laptop. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 21/22] marvell-ccic: replace RGB444 by XBGR444
From: Hans Verkuil hans.verk...@cisco.com
The RGB444 pixel format as implemented in this driver really implements
the variant where R and B are swapped, XBGR444. So replace RGB444 by XBGR444.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/marvell-ccic/mcam-core.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 5b60da1..55b3563 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -138,8 +138,8 @@ static struct mcam_format_struct {
.planar = true,
},
{
- .desc = RGB 444,
- .pixelformat= V4L2_PIX_FMT_RGB444,
+ .desc = BGR 444,
+ .pixelformat= V4L2_PIX_FMT_XBGR444,
.mbus_code = MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE,
.bpp= 2,
.planar = false,
@@ -777,10 +777,9 @@ static void mcam_ctlr_image(struct mcam_camera *cam)
mcam_reg_write_mask(cam, REG_CTRL0,
C0_DF_YUV | C0_YUV_PACKED | C0_YUVE_SWAP24, C0_DF_MASK);
break;
- case V4L2_PIX_FMT_RGB444:
+ case V4L2_PIX_FMT_XBGR444:
mcam_reg_write_mask(cam, REG_CTRL0,
C0_DF_RGB | C0_RGBF_444 | C0_RGB4_XRGB, C0_DF_MASK);
- /* Alpha value? */
break;
case V4L2_PIX_FMT_RGB565:
mcam_reg_write_mask(cam, REG_CTRL0,
--
2.1.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
[PATCHv3 22/22] Fix V4L2_PIX_FMT_SBGGR8 support
From: Hans Verkuil hans.verk...@cisco.com The REG_CTRL0 register was never written if this format was selected, instead an error was logged and whatever was last set in that register was used. Surprisingly, that seems to work if YUYV was selected, but we should program this register explicitly. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/media/platform/marvell-ccic/mcam-core.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c b/drivers/media/platform/marvell-ccic/mcam-core.c index 55b3563..6b62be1 100644 --- a/drivers/media/platform/marvell-ccic/mcam-core.c +++ b/drivers/media/platform/marvell-ccic/mcam-core.c @@ -785,6 +785,10 @@ static void mcam_ctlr_image(struct mcam_camera *cam) mcam_reg_write_mask(cam, REG_CTRL0, C0_DF_RGB | C0_RGBF_565 | C0_RGB5_BGGR, C0_DF_MASK); break; + case V4L2_PIX_FMT_SBGGR8: + mcam_reg_write_mask(cam, REG_CTRL0, + C0_DF_RGB | C0_RGB5_GRBG, C0_DF_MASK); + break; default: cam_err(cam, camera: unknown format: %#x\n, fmt-pixelformat); break; -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 40/40] vivid: add support for 8-bit Bayer formats
Add support for: PIX_FMT_SBGGR8, SGBRG8, SGRBG8 and SRGGB8.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/vivid/vivid-tpg.c| 57 +++--
drivers/media/platform/vivid/vivid-tpg.h| 17 +---
drivers/media/platform/vivid/vivid-vid-common.c | 32 ++
3 files changed, 97 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/vivid/vivid-tpg.c
b/drivers/media/platform/vivid/vivid-tpg.c
index 246c3e7..142b3c0 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -181,6 +181,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg-planes = 1;
tpg-buffers = 1;
tpg-recalc_colors = true;
+ tpg-interleaved = false;
tpg-vdownsampling[0] = 1;
tpg-hdownsampling[0] = 1;
tpg-hmask[0] = ~0;
@@ -188,6 +189,15 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
tpg-hmask[2] = ~0;
switch (fourcc) {
+ case V4L2_PIX_FMT_SBGGR8:
+ case V4L2_PIX_FMT_SGBRG8:
+ case V4L2_PIX_FMT_SGRBG8:
+ case V4L2_PIX_FMT_SRGGB8:
+ tpg-interleaved = true;
+ tpg-vdownsampling[1] = 1;
+ tpg-hdownsampling[1] = 1;
+ tpg-planes = 2;
+ /* fall through */
case V4L2_PIX_FMT_RGB332:
case V4L2_PIX_FMT_RGB565:
case V4L2_PIX_FMT_RGB565X:
@@ -326,13 +336,14 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_NV21:
case V4L2_PIX_FMT_NV12M:
case V4L2_PIX_FMT_NV21M:
- tpg-twopixelsize[0] = 2;
- tpg-twopixelsize[1] = 2;
- break;
case V4L2_PIX_FMT_NV16:
case V4L2_PIX_FMT_NV61:
case V4L2_PIX_FMT_NV16M:
case V4L2_PIX_FMT_NV61M:
+ case V4L2_PIX_FMT_SBGGR8:
+ case V4L2_PIX_FMT_SGBRG8:
+ case V4L2_PIX_FMT_SGRBG8:
+ case V4L2_PIX_FMT_SRGGB8:
tpg-twopixelsize[0] = 2;
tpg-twopixelsize[1] = 2;
break;
@@ -1011,6 +1022,35 @@ static void gen_twopix(struct tpg_data *tpg,
buf[0][offset + 2] = r_y;
buf[0][offset + 3] = alpha;
break;
+ case V4L2_PIX_FMT_SBGGR8:
+ buf[0][offset] = odd ? g_u : b_v;
+ buf[1][offset] = odd ? r_y : g_u;
+ break;
+ case V4L2_PIX_FMT_SGBRG8:
+ buf[0][offset] = odd ? b_v : g_u;
+ buf[1][offset] = odd ? g_u : r_y;
+ break;
+ case V4L2_PIX_FMT_SGRBG8:
+ buf[0][offset] = odd ? r_y : g_u;
+ buf[1][offset] = odd ? g_u : b_v;
+ break;
+ case V4L2_PIX_FMT_SRGGB8:
+ buf[0][offset] = odd ? g_u : r_y;
+ buf[1][offset] = odd ? b_v : g_u;
+ break;
+ }
+}
+
+unsigned tpg_g_interleaved_plane(const struct tpg_data *tpg, unsigned buf_line)
+{
+ switch (tpg-fourcc) {
+ case V4L2_PIX_FMT_SBGGR8:
+ case V4L2_PIX_FMT_SGBRG8:
+ case V4L2_PIX_FMT_SGRBG8:
+ case V4L2_PIX_FMT_SRGGB8:
+ return buf_line 1;
+ default:
+ return 0;
}
}
@@ -1610,6 +1650,8 @@ void tpg_calc_text_basep(struct tpg_data *tpg,
basep[p][1] += h * stride / 2;
else if (tpg-field == V4L2_FIELD_SEQ_BT)
basep[p][0] += h * stride / 2;
+ if (p == 0 tpg-interleaved)
+ tpg_calc_text_basep(tpg, basep, 1, vbuf);
}
static int tpg_pattern_avg(const struct tpg_data *tpg,
@@ -1986,6 +2028,13 @@ void tpg_fill_plane_buffer(struct tpg_data *tpg,
v4l2_std_id std,
src_y++;
}
+ /*
+* For line-interleaved formats determine the 'plane'
+* based on the buffer line.
+*/
+ if (tpg_g_interleaved(tpg))
+ p = tpg_g_interleaved_plane(tpg, buf_line);
+
if (tpg-vdownsampling[p] 1) {
/*
* When doing vertical downsampling the field setting
@@ -2032,7 +2081,7 @@ void tpg_fillbuffer(struct tpg_data *tpg, v4l2_std_id
std, unsigned p, u8 *vbuf)
return;
}
- for (i = 0; i tpg-planes; i++) {
+ for (i = 0; i tpg_g_planes(tpg); i++) {
tpg_fill_plane_buffer(tpg, std, i, vbuf + offset);
offset += tpg_calc_plane_size(tpg, i);
}
diff --git a/drivers/media/platform/vivid/vivid-tpg.h
b/drivers/media/platform/vivid/vivid-tpg.h
index 82ce9bf..a50cd2e 100644
--- a/drivers/media/platform/vivid/vivid-tpg.h
+++ b/drivers/media/platform/vivid/vivid-tpg.h
@@ -140,6 +140,7 @@ struct tpg_data {
unsignedreal_rgb_range;
unsignedbuffers;
unsignedplanes;
+ bool
Re: rt-mutex usage in i2c
Hi Sebastian,
- i2c_transfer() has this piece:
2091 if (in_atomic() || irqs_disabled()) {
2092 ret = i2c_trylock_adapter(adap);
is this irqs_disabled() is what bothers me and should not be there.
pxa does a spin_lock_irq() which would enable interrupts on return /
too early.
mxs has a wait_for_completion() which needs irqs enabled _and_ makes
in_atomic() problematic, too. I have't checked other drivers but the
commit, that introduced it, does not explain why it is required.
I haven't really looked into it, but a quick search gave me this thread
explaining the intention of the code in question:
http://lists.lm-sensors.org/pipermail/i2c/2007-November/002268.html
Regards,
Wolfram
signature.asc
Description: Digital signature
Re: rt-mutex usage in i2c
On Sat, Mar 14, 2015 at 12:27:03PM +0100, Wolfram Sang wrote:
Hi Sebastian,
- i2c_transfer() has this piece:
2091 if (in_atomic() || irqs_disabled()) {
2092 ret = i2c_trylock_adapter(adap);
is this irqs_disabled() is what bothers me and should not be there.
pxa does a spin_lock_irq() which would enable interrupts on return /
too early.
mxs has a wait_for_completion() which needs irqs enabled _and_ makes
in_atomic() problematic, too. I have't checked other drivers but the
commit, that introduced it, does not explain why it is required.
I haven't really looked into it, but a quick search gave me this thread
explaining the intention of the code in question:
http://lists.lm-sensors.org/pipermail/i2c/2007-November/002268.html
Regards,
Wolfram
And adding a recent mail address from Mike to cc.
signature.asc
Description: Digital signature
Re: [RFC 14/18] dt: bindings: Add bindings for omap3isp
Hi Sebastian,
Thanks for the comments!
On Fri, Mar 13, 2015 at 10:34:53AM +0100, Sebastian Reichel wrote:
Hi,
On Fri, Mar 13, 2015 at 01:03:21AM +0200, Sakari Ailus wrote:
[...]
+Required properties
+===
+
+compatible : ti,omap3-isp
I would rephrase that using the usual wording as compatible: Must
contain
ti,omap3-isp.
[...]
+ti,phy-type: 0 -- 3430; 1 -- 3630
Would it make sense to add #define's for this ?
I'll use OMAP3ISP_PHY_TYPE_COMPLEX_IO and OMAP3ISP_PHY_TYPE_CSIPHY as
discussed.
It could also make sense to document/name them Complex I/O and CSIPHY
to
avoid referring to the SoC that implements them, as the ISP is also found
in
SoCs other than 3430 and 3630.
Could the PHY type be derived from the ES revision that we query at
runtime ?
I think this would work on 3430 and 3630 but I'm not certain about others.
We should also take into account the fact that the DM3730 has officially
no
CSIPHY, but still seems to implement them in practice.
The DT sources are for 36xx, but I'd guess it works on 37xx as well, doesn't
it?
In other drivers this kind of information is often extracted from the
compatible string. For example:
{ .compatible = ti,omap34xx-isp, .data = OMAP3ISP_PHY_TYPE_COMPLEX_IO, },
{ .compatible = ti,omap36xx-isp, .data = OMAP3ISP_PHY_TYPE_CSIPHY, },
...
As Laurent said, I'd prefer to keep it as it is now; they phy selection
isn't really a part of the ISP in hardware either. It just happens to be
that the first phy selection logic can be found in 3430 (isp rev 2.0) and
latter in 3630 (isp rev 15.0).
[...]
+Example
+===
+
+ omap3_isp: omap3_isp@480bc000 {
DT node names traditionally use - as a separator. Furthermore the phandle
isn't needed. This should thus probably be
omap3-isp@480bc000 {
Fixed.
According to ePAPR this should be a generic name (page 19); For
example the i2c node name should be i2c@address instead of
omap3-i2c@address. There is no recommended generic term for an
image signal processor, isp looks ok to me and seems to be
already used in NVIDIA Tegra's device tree files. So maybe:
isp@480bc000 {
Thanks for the suggestion. I'll fix that.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 16/18] arm: dts: omap3: Add DT entries for OMAP 3
On Sun, Mar 08, 2015 at 01:51:51AM +0200, Laurent Pinchart wrote:
Hi Sakari,
Thank you for the patch.
On Saturday 07 March 2015 23:41:13 Sakari Ailus wrote:
The resources the ISP needs are slightly different on 3[45]xx and 3[67]xx.
Especially the phy-type property is different.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
arch/arm/boot/dts/omap34xx.dtsi | 15 +++
arch/arm/boot/dts/omap36xx.dtsi | 15 +++
2 files changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/omap34xx.dtsi
b/arch/arm/boot/dts/omap34xx.dtsi index 3819c1e..4c034d0 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -37,6 +37,21 @@
pinctrl-single,register-width = 16;
pinctrl-single,function-mask = 0xff1f;
};
+
+ omap3_isp: omap3_isp@480bc000 {
+ compatible = ti,omap3-isp;
+ reg = 0x480bc000 0x12fc
+ 0x480bd800 0x017c;
+ interrupts = 24;
+ iommus = mmu_isp;
+ syscon = omap3_scm_general 0xdc;
+ ti,phy-type = 0;
+ #clock-cells = 1;
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
How about predefining the ports too ?
After a short discussion, we decided not to add port nodes. The arguments
considered were:
- Port nodes could help integrators writing the DT nodes. However the port
nodes are easier to construct than endpoint nodes. Board specific
configuration would also still need to be added.
- Extra port nodes take space which could be spent more usefully for other
purposes.
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: omap3isp: video: Use v4l2_get_timestamp()
Thanks! On Fri, Mar 13, 2015 at 02:31:27AM +0200, Laurent Pinchart wrote: Replace the open-coded copy by a function call. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Sakari Ailus sakari.ai...@iki.fi -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: omap3isp: video: Don't call vb2 mmap with queue lock held
On Fri, Mar 13, 2015 at 02:33:35AM +0200, Laurent Pinchart wrote: videobuf2 has long been subject to AB-BA style deadlocks due to the queue lock and mmap_sem being taken in different orders for the mmap operation. The problem has been fixed by making this operation callable without taking the queue lock, using an mmap_lock internal to videobuf2. The omap3isp driver still calls the mmap operation with the queue lock held, resulting in a potential deadlock. As the operation can now be called without locking the queue, fix it. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Sakari Ailus sakari.ai...@iki.fi -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] v4l: mt9v032: Add OF support
Parse DT properties into a platform data structure when a DT node is
available.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
Changes since v2:
- Use of_graph_get_next_endpoint()
Changes since v1:
- Add MT9V02[24] compatible strings
- Prefix all compatible strings with aptina,
- Use link-frequencies instead of link-freqs
Open questions:
- Should the color/monochrome model be inferred from the compatible string, or
should a separate DT property be used for that ?
---
.../devicetree/bindings/media/i2c/mt9v032.txt | 45 ++
MAINTAINERS| 1 +
drivers/media/i2c/mt9v032.c| 70 +-
3 files changed, 115 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/mt9v032.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
new file mode 100644
index 000..68b134e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/mt9v032.txt
@@ -0,0 +1,45 @@
+* Aptina 1/3-Inch WVGA CMOS Digital Image Sensor
+
+The Aptina MT9V032 is a 1/3-inch CMOS active pixel digital image sensor with
+an active array size of 752H x 480V. It is programmable through a simple
+two-wire serial interface.
+
+Required Properties:
+
+- compatible: value should be either one among the following
+ (a) aptina,mt9v022 for MT9V022 color sensor
+ (b) aptina,mt9v022m for MT9V022 monochrome sensor
+ (c) aptina,mt9v024 for MT9V024 color sensor
+ (d) aptina,mt9v024m for MT9V024 monochrome sensor
+ (e) aptina,mt9v032 for MT9V032 color sensor
+ (f) aptina,mt9v032m for MT9V032 monochrome sensor
+ (g) aptina,mt9v034 for MT9V034 color sensor
+ (h) aptina,mt9v034m for MT9V034 monochrome sensor
+
+Optional Properties:
+
+- link-frequencies: List of allowed link frequencies in Hz. Each frequency is
+ expressed as a 64-bit big-endian integer.
+
+For further reading on port node refer to
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c0@1c22000 {
+ ...
+ ...
+ mt9v032@5c {
+ compatible = aptina,mt9v032;
+ reg = 0x5c;
+
+ port {
+ mt9v032_1: endpoint {
+ link-frequencies =
+ 0 1300, 0 2660,
+ 0 2700;
+ };
+ };
+ };
+ ...
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index ddc5a8c..180f6fb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6535,6 +6535,7 @@ M:Laurent Pinchart
laurent.pinch...@ideasonboard.com
L: linux-media@vger.kernel.org
T: git git://linuxtv.org/media_tree.git
S: Maintained
+F: Documentation/devicetree/bindings/media/i2c/mt9v032.txt
F: drivers/media/i2c/mt9v032.c
F: include/media/mt9v032.h
diff --git a/drivers/media/i2c/mt9v032.c b/drivers/media/i2c/mt9v032.c
index 255ea91..139eeef 100644
--- a/drivers/media/i2c/mt9v032.c
+++ b/drivers/media/i2c/mt9v032.c
@@ -17,6 +17,8 @@
#include linux/i2c.h
#include linux/log2.h
#include linux/mutex.h
+#include linux/of.h
+#include linux/of_gpio.h
#include linux/regmap.h
#include linux/slab.h
#include linux/videodev2.h
@@ -26,6 +28,7 @@
#include media/mt9v032.h
#include media/v4l2-ctrls.h
#include media/v4l2-device.h
+#include media/v4l2-of.h
#include media/v4l2-subdev.h
/* The first four rows are black rows. The active area spans 753x481 pixels. */
@@ -876,10 +879,59 @@ static const struct regmap_config mt9v032_regmap_config =
{
* Driver initialization and probing
*/
+static struct mt9v032_platform_data *
+mt9v032_get_pdata(struct i2c_client *client)
+{
+ struct mt9v032_platform_data *pdata;
+ struct v4l2_of_endpoint endpoint;
+ struct device_node *np;
+ struct property *prop;
+
+ if (!IS_ENABLED(CONFIG_OF) || !client-dev.of_node)
+ return client-dev.platform_data;
+
+ np = of_graph_get_next_endpoint(client-dev.of_node, NULL);
+ if (!np)
+ return NULL;
+
+ if (v4l2_of_parse_endpoint(np, endpoint) 0)
+ goto done;
+
+ pdata = devm_kzalloc(client-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ goto done;
+
+ prop = of_find_property(np, link-frequencies, NULL);
+ if (prop) {
+ size_t size = prop-length / 8;
+ u64 *link_freqs;
+
+ link_freqs = devm_kzalloc(client-dev,
+ size * sizeof(*link_freqs),
+ GFP_KERNEL);
+ if (!link_freqs)
+ goto done;
+
+ if
[PATCH v3 1/2] of: Add vendor prefix for Aptina Imaging
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) Aptina has recently been acquired by ON Semiconductor, but the name Aptina is still widely used. Should the onnn prefix be used instead ? diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 389ca13..4326f52 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -20,6 +20,7 @@ amlogic Amlogic, Inc. amsAMS AG amstaosAMS-Taos Inc. apmApplied Micro Circuits Corporation (APM) +aptina Aptina Imaging armARM Ltd. armadeus ARMadeus Systems SARL asahi-kaseiAsahi Kasei Corp. -- 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
[GIT PULL FOR v4.1] OMAP3 ISP fixes
Hi Mauro, The following changes since commit 3d945be05ac1e806af075e9315bc1b3409adae2b: [media] mn88473: simplify bandwidth registers setting code (2015-03-03 13:09:12 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git omap3isp/next for you to fetch changes up to ba779f69a9af4e44117f6197d3f18812a5748631: media: omap3isp: hist: Move histogram DMA to DMA engine (2015-03-14 16:58:33 +0200) Lad, Prabhakar (1): media: omap3isp: video: drop setting of vb2 buffer state to VB2_BUF_STATE_ACTIVE Laurent Pinchart (3): media: omap3isp: video: Don't call vb2 mmap with queue lock held media: omap3isp: video: Use v4l2_get_timestamp() media: omap3isp: hist: Move histogram DMA to DMA engine drivers/media/platform/omap3isp/isph3a_aewb.c | 1 - drivers/media/platform/omap3isp/isph3a_af.c | 1 - drivers/media/platform/omap3isp/isphist.c | 128 +++-- drivers/media/platform/omap3isp/ispstat.c | 2 +- drivers/media/platform/omap3isp/ispstat.h | 5 +- drivers/media/platform/omap3isp/ispvideo.c| 14 +--- 6 files changed, 82 insertions(+), 69 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL 4.0] rtl28xx fixes for 4.0
The following changes since commit 41f03a00536ebb3d72c051f9e7efe2d4ab76ebc8: [media] s5p-mfc: Fix NULL pointer dereference caused by not set q-lock (2015-03-04 08:59:58 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git rtl28xx_fixes for you to fetch changes up to 536c12e1da3491d6ee263995ac267b487a9cd33b: rtl28xxu: return success for unimplemented FE callback (2015-03-14 18:03:55 +0200) Antti Palosaari (2): rtl2832: disable regmap register cache rtl28xxu: return success for unimplemented FE callback drivers/media/dvb-frontends/rtl2832.c | 2 +- drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 -- 2 files changed, 1 insertion(+), 3 deletions(-) -- 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
[PATCH] uvcvideo: add support for VIDIOC_QUERY_EXT_CTRL
Add support for the new VIDIOC_QUERY_EXT_CTRL ioctl. Since uvc doesn't use
the control framework, support for this ioctl isn't automatic.
This is makes v4l2-compliance happy as well.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/usb/uvc/uvc_v4l2.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
index 43e953f..100e5c1 100644
--- a/drivers/media/usb/uvc/uvc_v4l2.c
+++ b/drivers/media/usb/uvc/uvc_v4l2.c
@@ -882,6 +882,33 @@ static int uvc_ioctl_queryctrl(struct file *file, void *fh,
return uvc_query_v4l2_ctrl(chain, qc);
}
+static int uvc_ioctl_query_ext_ctrl(struct file *file, void *fh,
+ struct v4l2_query_ext_ctrl *qec)
+{
+ struct uvc_fh *handle = fh;
+ struct uvc_video_chain *chain = handle-chain;
+ struct v4l2_queryctrl qc = { qec-id };
+ int ret;
+
+ ret = uvc_query_v4l2_ctrl(chain, qc);
+ if (ret)
+ return ret;
+ qec-id = qc.id;
+ qec-type = qc.type;
+ strlcpy(qec-name, qc.name, sizeof(qec-name));
+ qec-minimum = qc.minimum;
+ qec-maximum = qc.maximum;
+ qec-step = qc.step;
+ qec-default_value = qc.default_value;
+ qec-flags = qc.flags;
+ qec-elem_size = 4;
+ qec-elems = 1;
+ qec-nr_of_dims = 0;
+ memset(qec-dims, 0, sizeof(qec-dims));
+ memset(qec-reserved, 0, sizeof(qec-reserved));
+ return 0;
+}
+
static int uvc_ioctl_g_ctrl(struct file *file, void *fh,
struct v4l2_control *ctrl)
{
@@ -1443,6 +1470,7 @@ const struct v4l2_ioctl_ops uvc_ioctl_ops = {
.vidioc_g_input = uvc_ioctl_g_input,
.vidioc_s_input = uvc_ioctl_s_input,
.vidioc_queryctrl = uvc_ioctl_queryctrl,
+ .vidioc_query_ext_ctrl = uvc_ioctl_query_ext_ctrl,
.vidioc_g_ctrl = uvc_ioctl_g_ctrl,
.vidioc_s_ctrl = uvc_ioctl_s_ctrl,
.vidioc_g_ext_ctrls = uvc_ioctl_g_ext_ctrls,
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 10/18] omap3isp: Move the syscon register out of the ISP register maps
Hi Tony,
Thanks for the comments!!
On Mon, Mar 09, 2015 at 08:20:38AM -0700, Tony Lindgren wrote:
* Sakari Ailus sakari.ai...@iki.fi [150307 15:44]:
Hi Laurent,
On Sun, Mar 08, 2015 at 01:34:17AM +0200, Laurent Pinchart wrote:
Hi Sakari,
Thank you for the patch.
(CC'ing linux-omap and Tony)
Thanks.
On Saturday 07 March 2015 23:41:07 Sakari Ailus wrote:
The syscon register isn't part of the ISP, use it through the syscom
driver
regmap instead. The syscom block is considered to be from 343x on ISP
revision 2.0 whereas 15.0 is assumed to have 3630 syscon.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
arch/arm/boot/dts/omap3.dtsi|2 +-
arch/arm/mach-omap2/devices.c | 10 --
drivers/media/platform/omap3isp/isp.c | 19 +++
drivers/media/platform/omap3isp/isp.h | 19 +--
drivers/media/platform/omap3isp/ispcsiphy.c | 20 +---
You might be asked to split the patch into two, let's see what Tony says.
5 files changed, 42 insertions(+), 28 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 01b7111..fe0b293 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -183,7 +183,7 @@
omap3_scm_general: tisyscon@48002270 {
compatible = syscon;
- reg = 0x48002270 0x2f0;
+ reg = 0x48002270 0x2f4;
};
pbias_regulator: pbias_regulator {
Can you please send the above dts change separately as a fix describing
what goes wrong? Let's get that out of the way for the -rc, otherwise
we're going to probably get conflicts with Tero's dts changes.
Sure.
There's one register that didn't used to be mapped to syscon.
diff --git a/arch/arm/mach-omap2/devices.c
b/arch/arm/mach-omap2/devices.c
index 1afb50d..e945957 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -143,16 +143,6 @@ static struct resource omap3isp_resources[] = {
.flags = IORESOURCE_MEM,
},
{
- .start = OMAP343X_CTRL_BASE +
OMAP343X_CONTROL_CSIRXFE,
- .end= OMAP343X_CTRL_BASE +
OMAP343X_CONTROL_CSIRXFE + 3,
- .flags = IORESOURCE_MEM,
- },
- {
- .start = OMAP343X_CTRL_BASE +
OMAP3630_CONTROL_CAMERA_PHY_CTRL,
- .end= OMAP343X_CTRL_BASE +
OMAP3630_CONTROL_CAMERA_PHY_CTRL + 3,
- .flags = IORESOURCE_MEM,
- },
- {
.start = 24 + OMAP_INTC_START,
.flags = IORESOURCE_IRQ,
}
Looks good to me, teel free to merge this part along with the other
isp changes:
Acked-by: Tony Lindgren t...@atomide.com
Thanks!
--
Regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] v4l2-ioctl: allow all controls if ctrl_class == 0
The check_ext_ctrls() function in v4l2-ioctl.c checks if all controls in the
control array are from the same control class as c-ctrl_class. However,
that check should only be done if c-ctrl_class != 0. A 0 value means
that this restriction does not apply.
So return 1 (OK) if c-ctrl_class == 0.
Found by running v4l2-compliance on the uvc driver.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 09ad8dd..7731499 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -901,6 +901,8 @@ static int check_ext_ctrls(struct v4l2_ext_controls *c, int
allow_priv)
*/
if (!allow_priv c-ctrl_class == V4L2_CID_PRIVATE_BASE)
return 0;
+ if (c-ctrl_class == 0)
+ return 1;
/* Check that all controls are from the same control class. */
for (i = 0; i c-count; i++) {
if (V4L2_CTRL_ID2CLASS(c-controls[i].id) != c-ctrl_class) {
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] rtl28xxu: return success for unimplemented FE callback
Return success for FE callback on case we don't have any special implementation. fc0013 tuner driver calls that callback in order to switch antenna input, even we don't provide antenna switch. Returning error caused fc0013 driver given up tuning. Signed-off-by: Antti Palosaari cr...@iki.fi --- drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c index 77dcfdf..87fc0fe 100644 --- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c +++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c @@ -780,8 +780,6 @@ static int rtl2832u_frontend_callback(void *adapter_priv, int component, case TUNER_RTL2832_TUA9001: return rtl2832u_tua9001_tuner_callback(d, cmd, arg); } - default: - return -EINVAL; } return 0; -- 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
[PATCH 1/2] rtl2832: disable regmap register cache
Caching register reads causes some random I/O errors on channel
change. Disable caching now in order to avoid those errors.
Reverts partly commit dcadb82
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/rtl2832.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/rtl2832.c
b/drivers/media/dvb-frontends/rtl2832.c
index 5d2d8f4..67faa8d 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -1240,7 +1240,7 @@ static int rtl2832_probe(struct i2c_client *client,
dev-regmap_config.max_register = 5 * 0x100,
dev-regmap_config.ranges = regmap_range_cfg,
dev-regmap_config.num_ranges = ARRAY_SIZE(regmap_range_cfg),
- dev-regmap_config.cache_type = REGCACHE_RBTREE,
+ dev-regmap_config.cache_type = REGCACHE_NONE,
dev-regmap = regmap_init(client-dev, regmap_bus, client,
dev-regmap_config);
if (IS_ERR(dev-regmap)) {
--
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
