Re: [PATCH v3 1/3] drm: add bus_formats and nbus_formats fields to drm_display_info
Hi Laurent,
On Sat, 29 Nov 2014 00:13:47 +0200
Laurent Pinchart laurent.pinch...@ideasonboard.com wrote:
Hi Boris,
Thank you for the patch. I just have two small comments.
On Tuesday 18 November 2014 14:46:18 Boris Brezillon wrote:
Add bus_formats and nbus_formats fields and
drm_display_info_set_bus_formats helper function to specify the bus
formats supported by a given display.
This information can be used by display controller drivers to configure
the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
RGB or LVDS busses).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
drivers/gpu/drm/drm_crtc.c | 30 ++
include/drm/drm_crtc.h | 7 +++
2 files changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e79c8d3..17e3acf 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -763,6 +763,36 @@ static void drm_mode_remove(struct drm_connector
*connector, drm_mode_destroy(connector-dev, mode);
}
+/*
+ * drm_display_info_set_bus_formats - set the supported bus formats
+ * @info: display info to store bus formats in
+ * @fmts: array containing the supported bus formats
+ * @nfmts: the number of entries in the fmts array
+ *
+ * Store the suppported bus formats in display info structure.
Could you document that the formats are specified as MEDIA_BUS_FMT_* values ?
Sure, I'll clearly state that.
+ */
+int drm_display_info_set_bus_formats(struct drm_display_info *info, const
u32 *fmts, + unsigned int num_fmts)
+{
+ u32 *formats = NULL;
+
+ if (!fmts num_fmts)
+ return -EINVAL;
+
+ if (fmts num_fmts) {
+ formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL);
+ if (!formats)
+ return -ENOMEM;
+ }
+
+ kfree(info-bus_formats);
+ info-bus_formats = formats;
+ info-num_bus_formats = num_fmts;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_display_info_set_bus_formats);
+
/**
* drm_connector_get_cmdline_mode - reads the user's cmdline mode
* @connector: connector to quwery
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index c40070a..2e0a3e8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -31,6 +31,7 @@
#include linux/idr.h
#include linux/fb.h
#include linux/hdmi.h
+#include linux/media-bus-format.h
#include uapi/drm/drm_mode.h
#include uapi/drm/drm_fourcc.h
#include drm/drm_modeset_lock.h
@@ -130,6 +131,9 @@ struct drm_display_info {
enum subpixel_order subpixel_order;
u32 color_formats;
+ const u32 *bus_formats;
+ int num_bus_formats;
As the number of formats is never negative, I would make it an unsigned int.
Okay, I'll make it an unsigned int.
Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.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: [PATCH v3 0/3] drm: describe display bus format
Hi Laurent, On Sat, 29 Nov 2014 00:29:10 +0200 Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Boris, On Thursday 27 November 2014 14:37:50 Boris Brezillon wrote: On Tue, 18 Nov 2014 14:46:17 +0100 Boris Brezillon wrote: Hello, This series makes use of the MEDIA_BUS_FMT definition to describe how the data are transmitted to the display. This will allow drivers to configure their output display bus according to the display capabilities. For example some display controllers support DPI (or raw RGB) connectors and need to specify which format will be transmitted on the DPI bus (RGB444, RGB565, RGB888, ...). This series also adds a field to the panel_desc struct so that one can specify which format is natevely supported by a panel. Thierry, Laurent, Dave, can you take a look at this patch series: this is the last missing dependency to get the atmel-hlcdc DRM driver mainlined, and I was expecting to get this driver in 3.19... I've reviewed the series, it looks globally fine to me. I just had two small comments on patch 1/3. Thanks for the review, I'll address your comments in the next version. Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.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: ISDB caption support
With regards to CC decoding, IMHO, the best would be to add a parser for ISDB CC at libdvbv5. It probably makes more sense to extend one of the existing libraries that supports captions/subtitles to include support for ISDB (such as libzvbi or ccextractor). The libdvbv5 library has no infrastructure today for subtitle rendering for any other formats, so generating a generic caption/subtitle API within libdvbv5 that is extensible enough to support other formats seems redundant. It also means that applications that already use libzvbi will get the support for ISDB effectively for free (in fact, I'm considering moving VLC over to using libzvbi for CC rendering - it's already used today for raw VBI slicing). Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[REVIEW PATCH v2.1 08/11] of: smiapp: Add documentation
Document the smiapp device tree properties.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
since v2:
- Cleanups
- Removed clock-names property documentation
- Port node documentation was really endpoint node documentation
- Added remote-endpoint as mandatory endpoint node properties
.../devicetree/bindings/media/i2c/nokia,smia.txt | 64
MAINTAINERS|1 +
2 files changed, 65 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
b/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
new file mode 100644
index 000..2114a4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
@@ -0,0 +1,64 @@
+SMIA/SMIA++ sensor
+
+SMIA (Standard Mobile Imaging Architecture) is an image sensor standard
+defined jointly by Nokia and ST. SMIA++, defined by Nokia, is an extension
+of that. These definitions are valid for both types of sensors.
+
+More detailed documentation can be found in
+Documentation/devicetree/bindings/media/video-interfaces.txt .
+
+
+Mandatory properties
+
+
+- compatible: nokia,smia
+- reg: I2C address (0x10, or an alternative address)
+- vana-supply: Analogue voltage supply (VANA), typically 2,8 volts (sensor
+ dependent).
+- clocks: External clock phandle
+- clock-frequency: Frequency of the external clock to the sensor
+- link-frequency: List of allowed data link frequencies. An array of 64-bit
+ elements.
+
+
+Optional properties
+---
+
+- nokia,nvm-size: The size of the NVM, in bytes. If the size is not given,
+ the NVM contents will not be read.
+- reset-gpios: XSHUTDOWN GPIO
+
+
+Endpoint node mandatory properties
+--
+
+- clock-lanes: 0
+- data-lanes: 1..n
+- remote-endpoint: A phandle to the bus receiver's endpoint node.
+
+
+Example
+---
+
+i2c2 {
+ clock-frequency = 40;
+
+ smiapp_1: camera@10 {
+ compatible = nokia,smia;
+ reg = 0x10;
+ reset-gpios = gpio3 20 0;
+ vana-supply = vaux3;
+ clocks = omap3_isp 0;
+ clock-names = ext_clk;
+ clock-frequency = 960;
+ nokia,nvm-size = 512; /* 8 * 64 */
+ link-frequency = /bits/ 64 19920 21000 49920;
+ port {
+ smiapp_1_1: endpoint {
+ clock-lanes = 0;
+ data-lanes = 1 2;
+ remote-endpoint = csi2a_ep;
+ };
+ };
+ };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 2378a5f..285c1ba 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8619,6 +8619,7 @@ F:include/media/smiapp.h
F: drivers/media/i2c/smiapp-pll.c
F: drivers/media/i2c/smiapp-pll.h
F: include/uapi/linux/smiapp.h
+F: Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
SMM665 HARDWARE MONITOR DRIVER
M: Guenter Roeck li...@roeck-us.net
--
1.7.10.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
[REVIEW PATCH v2.1 09/11] smiapp: Obtain device information from the Device Tree if OF node exists
Platform data support is retained.
of_property_read_u64_array() isn't used yet as it's not in yet.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
since v2:
- Don't use of_property_read_u64_array() yet.
drivers/media/i2c/smiapp/smiapp-core.c | 114 +++-
1 file changed, 112 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index b02fa64..465c42f 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -25,11 +25,13 @@
#include linux/device.h
#include linux/gpio.h
#include linux/module.h
+#include linux/of_gpio.h
#include linux/regulator/consumer.h
#include linux/slab.h
#include linux/smiapp.h
#include linux/v4l2-mediabus.h
#include media/v4l2-device.h
+#include media/v4l2-of.h
#include smiapp.h
@@ -2921,19 +2923,121 @@ static int smiapp_resume(struct device *dev)
#endif /* CONFIG_PM */
+static struct smiapp_platform_data *smiapp_get_pdata(struct device *dev)
+{
+ struct smiapp_platform_data *pdata;
+ struct v4l2_of_endpoint bus_cfg;
+ struct device_node *ep;
+ struct property *prop;
+ __be32 *val;
+ uint32_t asize;
+ unsigned int i;
+ int rval;
+
+ if (!dev-of_node)
+ return dev-platform_data;
+
+ ep = of_graph_get_next_endpoint(dev-of_node, NULL);
+ if (!ep)
+ return NULL;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ rval = -ENOMEM;
+ goto out_err;
+ }
+
+ v4l2_of_parse_endpoint(ep, bus_cfg);
+
+ switch (bus_cfg.bus_type) {
+ case V4L2_MBUS_CSI2:
+ pdata-csi_signalling_mode = SMIAPP_CSI_SIGNALLING_MODE_CSI2;
+ break;
+ /* FIXME: add CCP2 support. */
+ default:
+ rval = -EINVAL;
+ goto out_err;
+ }
+
+ pdata-lanes = bus_cfg.bus.mipi_csi2.num_data_lanes;
+ dev_dbg(dev, lanes %u\n, pdata-lanes);
+
+ /* xshutdown GPIO is optional */
+ pdata-xshutdown = of_get_named_gpio(dev-of_node, reset-gpios, 0);
+
+ /* NVM size is not mandatory */
+ of_property_read_u32(dev-of_node, nokia,nvm-size,
+ pdata-nvm_size);
+
+ rval = of_property_read_u32(dev-of_node, clock-frequency,
+ pdata-ext_clk);
+ if (rval) {
+ dev_warn(dev, can't get clock-frequency\n);
+ goto out_err;
+ }
+
+ dev_dbg(dev, reset %d, nvm %d, clk %d, csi %d\n, pdata-xshutdown,
+ pdata-nvm_size, pdata-ext_clk, pdata-csi_signalling_mode);
+
+ rval = of_get_property(
+ dev-of_node, link-frequency, asize) ? 0 : -ENOENT;
+ if (rval) {
+ dev_warn(dev, can't get link-frequency array size\n);
+ goto out_err;
+ }
+
+ pdata-op_sys_clock = devm_kzalloc(dev, asize, GFP_KERNEL);
+ if (!pdata-op_sys_clock) {
+ rval = -ENOMEM;
+ goto out_err;
+ }
+
+ asize /= sizeof(*pdata-op_sys_clock);
+ /*
+* Read a 64-bit array --- this will be replaced with a
+* of_property_read_u64_array() once it's merged.
+*/
+ prop = of_find_property(dev-of_node, link-frequency, NULL);
+ if (!prop)
+ goto out_err;
+ if (!prop-value)
+ goto out_err;
+ if (asize * sizeof(*pdata-op_sys_clock) prop-length)
+ goto out_err;
+ val = prop-value;
+ if (IS_ERR(val))
+ goto out_err;
+
+ for (i = 0; i asize; i++)
+ pdata-op_sys_clock[i] = of_read_number(val + i * 2, 2);
+
+ for (; asize 0; asize--)
+ dev_dbg(dev, freq %d: %lld\n, asize - 1,
+ pdata-op_sys_clock[asize - 1]);
+
+ of_node_put(ep);
+ return pdata;
+
+out_err:
+ of_node_put(ep);
+ return NULL;
+}
+
static int smiapp_probe(struct i2c_client *client,
const struct i2c_device_id *devid)
{
struct smiapp_sensor *sensor;
+ struct smiapp_platform_data *pdata = smiapp_get_pdata(client-dev);
+ int rval;
- if (client-dev.platform_data == NULL)
+ if (pdata == NULL)
return -ENODEV;
sensor = devm_kzalloc(client-dev, sizeof(*sensor), GFP_KERNEL);
if (sensor == NULL)
return -ENOMEM;
- sensor-platform_data = client-dev.platform_data;
+ sensor-platform_data = pdata;
mutex_init(sensor-mutex);
mutex_init(sensor-power_mutex);
sensor-src = sensor-ssds[sensor-ssds_used];
@@ -2992,6 +3096,11 @@ static int smiapp_remove(struct i2c_client *client)
return 0;
}
+static const struct of_device_id smiapp_of_table[] = {
+ { .compatible = nokia,smia },
+ { },
+};
+
static const struct
Re: [PATCH] drivers:media: Add proper sanity checking for register setting to variable in lg2160.c
On Sat, Nov 29, 2014 at 10:04 PM, Nicholas Krause xerofo...@gmail.com wrote: Fixs issue with setting the variable value of val in the functionm,lg2161_set_output_interface and not sanity checking if the value has been correctly set with the correct value of the struct state of type lg216x_state passed to the function by the calling code. Signed-off-by: Nicholas Krause xerofo...@gmail.com --- drivers/media/dvb-frontends/lg2160.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/media/dvb-frontends/lg2160.c b/drivers/media/dvb-frontends/lg2160.c index 5fd14f8..9aec63a 100644 --- a/drivers/media/dvb-frontends/lg2160.c +++ b/drivers/media/dvb-frontends/lg2160.c @@ -459,7 +459,9 @@ static int lg2161_set_output_interface(struct lg216x_state *state) goto fail; val = ~0x07; - val |= state-cfg-output_if; /* FIXME: needs sanity check */ + val |= state-cfg-output_if; + if (lg_fail(val)) + goto fail; ret = lg216x_write_reg(state, 0x0014, val); lg_fail(ret); -- 2.1.0 NACK. Thank you for the patch, Nicholas, but the change that you propose won't actually help here -- val is a u8, and the lg_fail() macro tests for negative values. val can never be negative, and that's why I didn't add the lg_fail() test myself when I wrote this function. What's actually happening in this function is that the value is first set when reading register 0014, we take that value, unset the three lowest bits, then we raise the bits in state-cfg-output_if, and write it back to the same register. In fact, the FIXME comment should be removed -- this is not a bug anymore and the sanity check is built-in. That FIXME comment is a remnant of an older version of this function :-P If you want to send a patch that just removes the FIXME comment, that would be accepted, but this patch should not be merged. Cheers, Michael Ira Krufky -- 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: Kernel 3.17.0 broke xc4000-based DTV1800h
On 16 Oct 2014, at 17:33, Rodney Baker rodney.baker at iinet.net.au wrote: Since installing kernel 3.17.0-1.gc467423-desktop (on openSuSE 13.1) my xc4000/zl10353/cx88 based DTV card has failed to initialise on boot. Apparently, the default firmware file name has been changed to dvb-fe-xc4000-1.4.1.fw, and the firmware package for the kernel now includes this file from kernellabs.com. However, this firmware file is incomplete (only includes minimal DVB-T support for the PCTV 340e), and also incompatible with the driver. That is why trying to load it results in i2c errors. To get a firmware file that actually works, download this package, and build it: http://juropnet.hu/~istvan_v/xc4000_firmware.tar.gz Actually, it was posted to the linux-media list in the past, but the file did not end up being included with the kernel firmware packages for some reason. The include path to tuner-xc2028-types.h needs to be changed in build_fw.c, since the tuners subdirectory is now in drivers/media, rather than drivers/media/common. After that, running make will produce a correct firmware file named dvb-fe-xc4000-1.4.fw. Some distributions include older firmware files from this page: http://istvanv.users.sourceforge.net/v4l/xc4000.html These are slightly different from the newer one, and are extracted from the Windows drivers, rather than from the xc4000_firmwares.h file provided by Xceive, but should still work nevertheless. -- 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: Kernel 3.17.0 broke xc4000-based DTV1800h
By the way, from the xc4000_firmware.tar.gz package, the only files that are actually needed are: build_fw.c (source code of simple program to write the firmware file) xc4000_firmwares.h (header file from Xceive) xc4000_scodes.h (also from Xceive) Everything else is related to extracting the firmware from Windows drivers, and was included only for completeness. The license for the Xceive header files can be found here: http://www.kernellabs.com/firmware/xc4000/README.xc4000 -- 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 0/2] [media] tuners: Deletion of two unnecessary checks
From: Markus Elfring elfr...@users.sourceforge.net Date: Sun, 30 Nov 2014 20:50:15 +0100 Another update suggestion was taken into account after a patch was applied from static source code analysis. Markus Elfring (2): Deletion of unnecessary checks before the function call release_firmware One function call less in si2157_init() after error detection drivers/media/tuners/si2157.c | 9 - drivers/media/tuners/xc5000.c | 3 +-- 2 files changed, 5 insertions(+), 7 deletions(-) -- 2.1.3 -- 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] [media] tuners: Deletion of unnecessary checks before the function call release_firmware
From: Markus Elfring elfr...@users.sourceforge.net
Date: Sun, 30 Nov 2014 19:05:48 +0100
The release_firmware() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
---
drivers/media/tuners/si2157.c | 3 +--
drivers/media/tuners/xc5000.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 8e57696..e17ab1f 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -196,8 +196,7 @@ warm:
return 0;
err:
- if (fw)
- release_firmware(fw);
+ release_firmware(fw);
dev_dbg(s-client-dev, failed=%d\n, ret);
return ret;
diff --git a/drivers/media/tuners/xc5000.c b/drivers/media/tuners/xc5000.c
index 705c258..2a039de 100644
--- a/drivers/media/tuners/xc5000.c
+++ b/drivers/media/tuners/xc5000.c
@@ -1336,8 +1336,7 @@ static int xc5000_release(struct dvb_frontend *fe)
if (priv) {
cancel_delayed_work(priv-timer_sleep);
- if (priv-firmware)
- release_firmware(priv-firmware);
+ release_firmware(priv-firmware);
hybrid_tuner_release_state(priv);
}
--
2.1.3
--
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] [media] tuners-si2157: One function call less in si2157_init() after error detection
From: Markus Elfring elfr...@users.sourceforge.net Date: Sun, 30 Nov 2014 20:48:24 +0100 The release_firmware() function was called in some cases by the si2157_init() function during error handling even if the passed variable contained still a null pointer. This implementation detail could be improved by the introduction of another jump label. Signed-off-by: Markus Elfring elfr...@users.sourceforge.net --- drivers/media/tuners/si2157.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c index e17ab1f..2180de9 100644 --- a/drivers/media/tuners/si2157.c +++ b/drivers/media/tuners/si2157.c @@ -157,7 +157,7 @@ static int si2157_init(struct dvb_frontend *fe) dev_err(s-client-dev, firmware file '%s' is invalid\n, fw_file); ret = -EINVAL; - goto err; + goto fw_release_exit; } dev_info(s-client-dev, downloading firmware from file '%s'\n, @@ -173,7 +173,7 @@ static int si2157_init(struct dvb_frontend *fe) dev_err(s-client-dev, firmware download failed=%d\n, ret); - goto err; + goto fw_release_exit; } } @@ -195,9 +195,9 @@ warm: s-active = true; return 0; -err: +fw_release_exit: release_firmware(fw); - +err: dev_dbg(s-client-dev, failed=%d\n, ret); return ret; } -- 2.1.3 -- 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: v4l2-subdev.h: drop the guard CONFIG_VIDEO_V4L2_SUBDEV_API for v4l2_subdev_get_try_*()
Hi Laurent, On Sat, Nov 29, 2014 at 7:12 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Prabhakar, [Snip] Sure. That's a better choice than removing the config option dependency of the fields struct v4l2_subdev. Decoupling CONFIG_VIDEO_V4L2_SUBDEV_API from the availability of the in-kernel pad format and selection rectangles helpers is definitely a good idea. I was thinking about decoupling the try format and rectangles from v4l2_subdev_fh by creating a kind of configuration store structure to store them, and embedding that structure in v4l2_subdev_fh. The pad-level operations would then take a pointer to the configuration store instead of the v4l2_subdev_fh. Bridge drivers that want to implement TRY_FMT based on pad-level operations would create a configuration store, use the pad-level operations, and destroy the configuration store. The userspace subdev API would use the configuration store from the file handle. are planning to work/post any time soon ? Or are you OK with suggestion from Hans ? Thanks, --Prabhakar Lad -- 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: v4l2-subdev.h: drop the guard CONFIG_VIDEO_V4L2_SUBDEV_API for v4l2_subdev_get_try_*()
On Sunday 30 November 2014 21:05:50 Prabhakar Lad wrote: On Sat, Nov 29, 2014 at 7:12 PM, Laurent Pinchart wrote: Hi Prabhakar, [Snip] Sure. That's a better choice than removing the config option dependency of the fields struct v4l2_subdev. Decoupling CONFIG_VIDEO_V4L2_SUBDEV_API from the availability of the in-kernel pad format and selection rectangles helpers is definitely a good idea. I was thinking about decoupling the try format and rectangles from v4l2_subdev_fh by creating a kind of configuration store structure to store them, and embedding that structure in v4l2_subdev_fh. The pad-level operations would then take a pointer to the configuration store instead of the v4l2_subdev_fh. Bridge drivers that want to implement TRY_FMT based on pad-level operations would create a configuration store, use the pad-level operations, and destroy the configuration store. The userspace subdev API would use the configuration store from the file handle. are planning to work/post any time soon ? Or are you OK with suggestion from Hans ? I have no plan to work on that myself now, I was hoping you could implement it ;-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: v4l2-subdev.h: drop the guard CONFIG_VIDEO_V4L2_SUBDEV_API for v4l2_subdev_get_try_*()
Hi Laurent, On Sun, Nov 30, 2014 at 9:16 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Sunday 30 November 2014 21:05:50 Prabhakar Lad wrote: On Sat, Nov 29, 2014 at 7:12 PM, Laurent Pinchart wrote: Hi Prabhakar, [Snip] Sure. That's a better choice than removing the config option dependency of the fields struct v4l2_subdev. Decoupling CONFIG_VIDEO_V4L2_SUBDEV_API from the availability of the in-kernel pad format and selection rectangles helpers is definitely a good idea. I was thinking about decoupling the try format and rectangles from v4l2_subdev_fh by creating a kind of configuration store structure to store them, and embedding that structure in v4l2_subdev_fh. The pad-level operations would then take a pointer to the configuration store instead of the v4l2_subdev_fh. Bridge drivers that want to implement TRY_FMT based on pad-level operations would create a configuration store, use the pad-level operations, and destroy the configuration store. The userspace subdev API would use the configuration store from the file handle. are planning to work/post any time soon ? Or are you OK with suggestion from Hans ? I have no plan to work on that myself now, I was hoping you could implement it ;-) OK will implement it. Can you please elaborate a more on this The userspace subdev API would use the configuration store from the file handle. Thanks, --Prabhakar Lad -- 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/1] [media] ddbridge: Deletion of an unnecessary check before the function call dvb_unregister_device
From: Markus Elfring elfr...@users.sourceforge.net
Date: Sun, 30 Nov 2014 22:50:20 +0100
The dvb_unregister_device() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
---
drivers/media/pci/ddbridge/ddbridge-core.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/pci/ddbridge/ddbridge-core.c
b/drivers/media/pci/ddbridge/ddbridge-core.c
index c82e855..9e3492e 100644
--- a/drivers/media/pci/ddbridge/ddbridge-core.c
+++ b/drivers/media/pci/ddbridge/ddbridge-core.c
@@ -1118,8 +1118,7 @@ static void ddb_ports_detach(struct ddb *dev)
dvb_input_detach(port-input[1]);
break;
case DDB_PORT_CI:
- if (port-output-dev)
- dvb_unregister_device(port-output-dev);
+ dvb_unregister_device(port-output-dev);
if (port-en) {
ddb_input_stop(port-input[0]);
ddb_output_stop(port-output);
--
2.1.3
--
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/1] [media] V4L2: Deletion of an unnecessary check before the function call vb2_put_vma
From: Markus Elfring elfr...@users.sourceforge.net
Date: Sun, 30 Nov 2014 23:10:51 +0100
The vb2_put_vma() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring elfr...@users.sourceforge.net
---
drivers/media/v4l2-core/videobuf2-vmalloc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-vmalloc.c
b/drivers/media/v4l2-core/videobuf2-vmalloc.c
index 3966b12..fba944e 100644
--- a/drivers/media/v4l2-core/videobuf2-vmalloc.c
+++ b/drivers/media/v4l2-core/videobuf2-vmalloc.c
@@ -154,8 +154,7 @@ static void vb2_vmalloc_put_userptr(void *buf_priv)
}
kfree(buf-pages);
} else {
- if (buf-vma)
- vb2_put_vma(buf-vma);
+ vb2_put_vma(buf-vma);
iounmap(buf-vaddr);
}
kfree(buf);
--
2.1.3
--
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
Random memory corruption of fe[1]-dvb pointer
While working on a driver I noticed that I had trouble unloading the
module after testing, it crashed while running
dvb_usbv2_adapter_frontend_exit. So I added a print out of some pointers
and got this:
Init:
usb 1-1: dvb_usbv2_adapter_frontend_init: adap=fe[0] 88006afa6818
usb 1-1: dvb_usbv2_adapter_frontend_init: adap=fe[0]-dvb 880078cba580
usb 1-1: dvb_usbv2_adapter_frontend_init: adap=fe[1] 88003698e830
usb 1-1: dvb_usbv2_adapter_frontend_init: adap=fe[1]-dvb 880078cba580
ok looking 64bit pointers
Deinit:
usb 1-1: dvb_usbv2_exit:
usb 1-1: dvb_usbv2_remote_exit:
usb 1-1: dvb_usbv2_adapter_exit:
usb 1-1: dvb_usbv2_adapter_exit: fe0[0]= 88006afa6818
usb 1-1: dvb_usbv2_adapter_exit: fe0[0]-dvb= 880078cba580
usb 1-1: dvb_usbv2_adapter_exit: fe1[0]= 88003698e830
usb 1-1: dvb_usbv2_adapter_exit: fe1[0]-dvb= 003a746165733a3d
usb 1-1: dvb_usbv2_adapter_frontend_exit: adap=0
usb 1-1: dvb_usbv2_adapter_frontend_exit: fe[1]= 88003698e830
usb 1-1: dvb_usbv2_adapter_frontend_exit: fe[1]-dvb= 003a746165733a3d
Later on in dvb_usbv2_adapter_frontend_exit() fe[1]-dvb is dereferenced
and thus causes a kernel crash.
So for some reason fe[1]-dvb gets corrupted. It doesn't happen all the
time but after max 3 times I get this crash. I have reproduced this on
my main machine running Ubuntu 14.04, 14.10 and a VM running Ubuntu
14.04 all running stock kernel (3.13 and 3.16) and the media_build back
port code.
After some investigation I saw that fe[1]-demodulator_priv also gets
corrupted. Something is overwriting the pointers.
So with that knowledge I wrote the following patch and now I can freely
reload the driver without a crash. This of course doesn't fix the issue
but just corrupts unused dummy memory.
So does anyone have any hunch on what might be causing this issue or how
to track it down ?
Keep in mind that this could be caused by me running the media_build
code or some bug in the driver. Or it could also affect the regular tree
when unplugging devices with more then 1 frontend.
MvH
Benjamin Larsson
diff --git a/drivers/media/dvb-core/dvb_frontend.h
b/drivers/media/dvb-core/dvb_frontend.h
index 816269e..e0ba434 100644
--- a/drivers/media/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb-core/dvb_frontend.h
@@ -413,19 +413,30 @@ struct dtv_frontend_properties {
#define DVB_FE_DEVICE_RESUME3
struct dvb_frontend {
- struct dvb_frontend_ops ops;
- struct dvb_adapter *dvb;
void *demodulator_priv;
+ int dummy1[16000];
void *tuner_priv;
+ int dummy2[16000];
void *frontend_priv;
+ int dummy3[16000];
void *sec_priv;
+ int dummy4[16000];
void *analog_demod_priv;
+ int dummy5[16000];
struct dtv_frontend_properties dtv_property_cache;
+ int dummy6[16000];
#define DVB_FRONTEND_COMPONENT_TUNER 0
#define DVB_FRONTEND_COMPONENT_DEMOD 1
int (*callback)(void *adapter_priv, int component, int cmd, int
arg);
+ int dummy7[16000];
int id;
+ int dummy8[16000];
unsigned int exit;
+ int dummy9[16000];
+ struct dvb_frontend_ops ops;
+ int dummy10[16000];
+ struct dvb_adapter *dvb;
+ int dummy11[16000];
};
--
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] linux-firmware: Add firmware files for Siano DTV devices
On Sun, Nov 09, 2014 at 09:58:19PM -0200, Mauro Carvalho Chehab wrote: From: Mauro Carvalho Chehab mche...@infradead.org Acked-by: Rainer Miethling rmiethl...@pctvsystems.com Signed-off-by: Mauro Carvalho Chehab mche...@infradead.org --- LICENCE.siano | 31 +++ WHENCE| 18 ++ cmmb_vega_12mhz.inp | Bin 0 - 62780 bytes cmmb_venice_12mhz.inp | Bin 0 - 97016 bytes dvb_nova_12mhz.inp| Bin 0 - 93516 bytes dvb_nova_12mhz_b0.inp | Bin 0 - 101888 bytes isdbt_nova_12mhz.inp | Bin 0 - 75876 bytes isdbt_nova_12mhz_b0.inp | Bin 0 - 98384 bytes isdbt_rio.inp | Bin 0 - 85840 bytes sms1xxx-hcw-55xxx-dvbt-02.fw | Bin 0 - 85656 bytes sms1xxx-hcw-55xxx-isdbt-02.fw | Bin 0 - 70472 bytes sms1xxx-nova-a-dvbt-01.fw | Bin 0 - 85656 bytes sms1xxx-nova-b-dvbt-01.fw | Bin 0 - 76364 bytes sms1xxx-stellar-dvbt-01.fw| Bin 0 - 39900 bytes tdmb_nova_12mhz.inp | Bin 0 - 40096 bytes 15 files changed, 49 insertions(+) bleh, it would have been nice to have made a dvb/ namespace for some of these to group them all... in any event, i've applied this patch (After a slight fixup to WHENCE.) regards, Kyle -- 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] [media] gspca_touptek: Add support for ToupTek UCMOS series USB cameras
Adds support for AmScope MU800 / ToupTek UCMOS08000KPB USB microscope camera. Signed-off-by: John McMaster johndmcmas...@gmail.com --- drivers/media/usb/gspca/Kconfig | 10 + drivers/media/usb/gspca/Makefile |2 + drivers/media/usb/gspca/touptek.c | 729 + 3 files changed, 741 insertions(+) create mode 100644 drivers/media/usb/gspca/touptek.c diff --git a/drivers/media/usb/gspca/Kconfig b/drivers/media/usb/gspca/Kconfig index eed10d7..60af3b1 100644 --- a/drivers/media/usb/gspca/Kconfig +++ b/drivers/media/usb/gspca/Kconfig @@ -395,6 +395,16 @@ config USB_GSPCA_TOPRO To compile this driver as a module, choose M here: the module will be called gspca_topro. +config USB_GSPCA_TOUPTEK + tristate Touptek USB Camera Driver + depends on VIDEO_V4L2 USB_GSPCA + help + Say Y here if you want support for cameras based on the ToupTek UCMOS + / AmScope MU series camera. + + To compile this driver as a module, choose M here: the + module will be called gspca_touptek. + config USB_GSPCA_TV8532 tristate TV8532 USB Camera Driver depends on VIDEO_V4L2 USB_GSPCA diff --git a/drivers/media/usb/gspca/Makefile b/drivers/media/usb/gspca/Makefile index f46975e..9f5ccec 100644 --- a/drivers/media/usb/gspca/Makefile +++ b/drivers/media/usb/gspca/Makefile @@ -39,6 +39,7 @@ obj-$(CONFIG_USB_GSPCA_STK1135) += gspca_stk1135.o obj-$(CONFIG_USB_GSPCA_STV0680) += gspca_stv0680.o obj-$(CONFIG_USB_GSPCA_T613) += gspca_t613.o obj-$(CONFIG_USB_GSPCA_TOPRO)+= gspca_topro.o +obj-$(CONFIG_USB_GSPCA_TOUPTEK) += gspca_touptek.o obj-$(CONFIG_USB_GSPCA_TV8532) += gspca_tv8532.o obj-$(CONFIG_USB_GSPCA_VC032X) += gspca_vc032x.o obj-$(CONFIG_USB_GSPCA_VICAM)+= gspca_vicam.o @@ -86,6 +87,7 @@ gspca_stv0680-objs := stv0680.o gspca_sunplus-objs := sunplus.o gspca_t613-objs := t613.o gspca_topro-objs:= topro.o +gspca_touptek-objs := touptek.o gspca_tv8532-objs := tv8532.o gspca_vc032x-objs := vc032x.o gspca_vicam-objs:= vicam.o diff --git a/drivers/media/usb/gspca/touptek.c b/drivers/media/usb/gspca/touptek.c new file mode 100644 index 000..2fd876c --- /dev/null +++ b/drivers/media/usb/gspca/touptek.c @@ -0,0 +1,729 @@ +/* + * ToupTek UCMOS / AmScope MU series camera driver + * TODO: contrast with ScopeTek / AmScope MDC cameras + * + * Copyright (C) 2012-2014 John McMaster johndmcmas...@gmail.com + * + * Special thanks to Bushing for helping with the decrypt algorithm and + * Sean O'Sullivan / the Rensselaer Center for Open Source + * Software (RCOS) for helping me learn kernel development + * + * 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 + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include gspca.h + +#define MODULE_NAME touptek + +MODULE_AUTHOR(John McMaster); +MODULE_DESCRIPTION(ToupTek UCMOS / Amscope MU microscope camera driver); +MODULE_LICENSE(GPL); + +/* +Exposure reg is linear with exposure time +Exposure (sec), E (reg) +0.000400, 0x0002 +0.001000, 0x0005 +0.005000, 0x0019 +0.02, 0x0064 +0.08, 0x0190 +0.40, 0x07D0 +1.00, 0x1388 +2.00, 0x2710 + +Three gain stages +0x1000: master channel enable bit +0x007F: low gain bits +0x0080: medium gain bit +0x0100: high gain bit +gain = enable * (1 + regH) * (1 + regM) * z * regL + +Gain implementation +Want to do something similar to mt9v011.c's set_balance + +Gain does not vary with resolution (checked 640x480 vs 1600x1200) + +Constant derivation: + +Raw data: +Gain, GTOP, B, R, GBOT +1.00, 0x105C, 0x1068, 0x10C8, 0x105C +1.20, 0x106E, 0x107E, 0x10D6, 0x106E +1.40, 0x10C0, 0x10CA, 0x10E5, 0x10C0 +1.60, 0x10C9, 0x10D4, 0x10F3, 0x10C9 +1.80, 0x10D2, 0x10DE, 0x11C1, 0x10D2 +2.00, 0x10DC, 0x10E9, 0x11C8, 0x10DC +2.20, 0x10E5, 0x10F3, 0x11CF, 0x10E5 +2.40, 0x10EE, 0x10FE, 0x11D7, 0x10EE +2.60, 0x10F7, 0x11C4, 0x11DE, 0x10F7 +2.80, 0x11C0, 0x11CA, 0x11E5, 0x11C0 +3.00, 0x11C5, 0x11CF, 0x11ED, 0x11C5 + +zR = 0.0069605943152454778 + about 3/431 = 0.0069605568445475635 +zB = 0.0095695970695970703 + about 6/627 = 0.0095693779904306216 +zG = 0.010889328063241107 + about 6/551 = 0.010889292196007259 +about 10 bits for constant + 7 bits for value = at least 17 bit intermediate +with 32 bit ints should be fine for overflow etc +Essentially
Re: [PATCH] [media] gspca_touptek: Add support for ToupTek UCMOS series USB cameras
On 10/23/2014 06:09 AM, Hans de Goede wrote:
Hi,
On 10/05/2014 08:43 AM, John McMaster wrote:
Adds support for AmScope MU800 / ToupTek UCMOS08000KPB USB microscope camera.
First of all many thanks for writing this driver, and also for submitting it
upstream. We always appreciate it a lot when people put in the effort to
write a driver to support new webcams, and it is also greatly appreciated
when people go the extra mile to make the driver clean enough to submit it
upstream!
Overall the driver looks fine, you've clearly spend a lot of time on this!
3 small remarks though:
1) Please replace all the pr_foo calls with calls to the gspca specific
PERR (v4l2_err wrapper) and PDEBUG (v4l2_dbg) macros. using PDEBUG will
allow you to specify one of the D_foo values as debug level and then at
runtime select which messages to log. The following levels are available:
#define D_PROBE 1
Use this for probing info, e.g. print which type of sensors / extra
features you've detected.
#define D_CONF 2
This is used to log configuration info, e.g. for format negotation,
typically this is used by the gspca core and not by your driver
#define D_STREAM 3
Use this to log debug messages at stream start / stop
#define D_FRAM 4
Use this to log debug messages occuring once each frame
#define D_PACK 5
Use this to log debug messages occuring once each video packet
#define D_USBI 6
Use this to log ctrl register reads
#define D_USBO 7
Use this to log ctrl register writes
When you use this, you can use the gspca_main.debug module parameter
to select a log level between 0 - 7.
Done
2) As for the XXX: seems done automaticly, should rmeove bit, yes
controls are set automatically at the start of streaming, so please
remove this (and double check things still work with it removed).
Done, seems to still work
3) In some places you do:
rc = reg_w(gspca_dev, 0x, REG_SCALING_MODE);
if (rc)
return rc;
rc = reg_w(gspca_dev, 0x0010, REG_SCALE_M);
if (rc)
return rc;
rc = reg_w(gspca_dev, w, REG_X_OUTPUT_SIZE);
if (rc)
return rc;
rc = reg_w(gspca_dev, gspca_dev-pixfmt.height, REG_Y_OUTPUT_SIZE);
if (rc)
return rc;
The way we typically handle this in gspca is through gspca_dev-usb_err
which you use in sd_s_ctrl but never set, here is an example of another reg_w
function indicating how this is typically used:
static void pac207_write_reg(struct gspca_dev *gspca_dev, u16 index, u16
value)
{
struct usb_device *udev = gspca_dev-dev;
int err;
if (gspca_dev-usb_err 0)
return;
err = usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0x00,
USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_INTERFACE,
value, index, NULL, 0, PAC207_CTRL_TIMEOUT);
if (err) {
pr_err(Failed to write a register (index 0x%04X, value
0x%02X,
index, value, err);
gspca_dev-usb_err = err;
}
}
And the above code would be changed into:
gspca_dev-usb_err = 0;
reg_w(gspca_dev, 0x, REG_SCALING_MODE);
reg_w(gspca_dev, 0x0010, REG_SCALE_M);
reg_w(gspca_dev, w, REG_X_OUTPUT_SIZE);
reg_w(gspca_dev, gspca_dev-pixfmt.height, REG_Y_OUTPUT_SIZE);
return gspca_dev-usb_err;
The idea being that we can simply chain as many reg_w calls as we need,
and the first one failing turns all the next ones into nops, and at the
end we simply return gspca_dev-usb_err which on success is still 0.
If you make this change then the return of gspca_dev-usb_err at the end
of sd_s_ctrl also actually starts making sense :)
Changed. This does change the error handing though: you continue to
send commands in some cases even if a previous one failed. I guess it
shouldn't really matter though.
If you can fix these 3 issues then I'll happily merge this driver for
3.19.
Regards,
Hans
Busy with work, took a while longer to get back to this than I hoped.
Posted new version, let me know if this looks better. No worries if it
doesn't make 3.19.
I found that depending on the microscope filters I use I cannot get the
full color range. At some point in the future I'd like to tweak the
gain model.
John
Signed-off-by: John McMaster johndmcmas...@gmail.com
---
drivers/media/usb/gspca/Kconfig | 10 +
drivers/media/usb/gspca/Makefile |2 +
drivers/media/usb/gspca/touptek.c | 859
+
3 files changed, 871 insertions(+)
create mode 100644 drivers/media/usb/gspca/touptek.c
diff --git a/drivers/media/usb/gspca/Kconfig
b/drivers/media/usb/gspca/Kconfig
index eed10d7..60af3b1 100644
--- a/drivers/media/usb/gspca/Kconfig
+++ b/drivers/media/usb/gspca/Kconfig
@@ -395,6 +395,16 @@ config USB_GSPCA_TOPRO
To compile this driver as a module, choose
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: Mon Dec 1 04:00:14 CET 2014 git branch: test git hash: 504febc3f98c87a8bebd8f2f274f32c0724131e4 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-35-gc1c3f96 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.17-3.slh.2-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: WARNINGS 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: OK linux-3.9.2-i686: OK 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-i686: OK linux-3.17-i686: OK linux-3.18-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: OK linux-3.9.2-x86_64: OK 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-x86_64: OK linux-3.17-x86_64: OK linux-3.18-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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
