Re: TT-connect CT2-4650 CI: DVB-C: no signal, no QAM
Hi Pavol, Thanks. As said, I have not had any time to look into this, but will definitely do so. I own the same device, but do not have cable TV at home. Am using Conax CAM also successfully, so I believe that CI is not the issue. Some things that came to my mind still: Can you share the results of w_scan with very verbose output with both TT driver and the kernel driver? Also, make sure you use a recent version of w_scan - some distributions come with a rather old version... w_scan -v -v -v 2>&1 | tee logfile.txt Also, if you want to try a later firmware for Si2168, have a look at this patch: http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?id=1b97dc98b58dad98f13fa0a4cdc819b60f3f3bff It is in media_tree already. Cheers, -olli On 8 December 2014 at 18:56, Pavol Domin wrote: > Hi Olli, > > Thanks for feedback. >> Are you able to provide me a trace of the USB bus when using Windows? This >> is what I have been doing. >> >> 1) install USBlyzer >> 2) start it and select the option Capture hot plugged in the menus >> 3) start capture >> 4) plug in the device >> 5) start watching tv >> 6) stop capture after 1 sec to avoid the capture file growing too much > I've done that and shared at: > https://drive.google.com/open?id=0B94Ll0t460PoSTdKR0xiZlU2S0E&authuser=0 > >> Would be also good to know if gnutv -cammenu works with the open source > Yes, it seems to work (except it coredumps after ctrl-c on fedora), e.g. > $ gnutv -channels channels.xine.conf -cammenu "Eurosport HD" > CAM Application type: 01 > CAM Application manufacturer: 0b00 > CAM Manufacturer code: 0001 > CAM Menu string: Conax Conditional Access > CAM supports the following ca system ids: > 0x0b00 > -- > Conax Conditional Access > Main menu > 0. Quit menu > 1. Subscription status > 2. Event status > 3. Tokens status > 4. Change CA PIN > 5. Maturity Rating > 6. Ordering online > 7. About Conax CA > 8. Messages > 9. Language > 10. Loader status > 11. CI Plus Info > Press OK to select, or press RETURN > >> driver. Are all your channels encrypted? Is there any difference between >> them? > No, some are unencrypted. I cannot tell there are some other > differences, windows application 'tt-viewer' does not show details > about scanned channels. Also, the multiplex frequencies listed by > provider do not seem to match much with what the w_scan initially found. > Also, w_scan only scanned at QAM256, tv provider page suggests there are > some channels at QAM64 (I havent tried to scan those). > But again, it worked (with the TechnoTrend driver) for a short while > from linux, even the encryted channels I think. > > Regards > > Pavol > >> >> Cheers, >> -olli >> On 7 Dec 2014 19:41, "Pavol Domin" wrote: >> >> > Hello, >> > >> > I recently purchased "TechnoTrend TT-connect CT2-4650 CI" in order to >> > watch DVB-C cable TV. I have obtained CAM and smart card from my cable >> > TV provider. >> > >> > Initially, I tried the closed-source driver from the manufacturer; I have >> > scanned (w_scan) over hundred of channels and I was able to watch few >> > channels (vlc >> > or xine) for several minutes. After couple of channels switches however, >> > xine started to report 'DVB Signal Lost' for any channel. The w_scan >> > founds nothing anymore - tried multiple kernels on different machines, >> > during several days, nothing ;) >> > >> > Manufacturer is not providing linux support and directed me to >> > linux_media instead. >> > >> > The situation with linux_media is not better however (tried recent >> > media_build on ubuntu 3.16 and fedora 3.17 kernels) >> > >> > 1. the device is detected without any problems, no single error reported: >> > [ 1957.068871] dvb-usb: found a 'TechnoTrend TT-connect CT2-4650 CI' in >> > warm state. >> > [ 1957.068999] dvb-usb: will pass the complete MPEG2 transport stream to >> > the software demuxer. >> > [ 1957.069182] DVB: registering new adapter (TechnoTrend TT-connect >> > CT2-4650 CI) >> > [ 1957.070518] dvb-usb: MAC address: bc:ea:2b:65:02:3b >> > [ 1957.283195] i2c i2c-9: Added multiplexed i2c bus 10 >> > [ 1957.283205] si2168 9-0064: Silicon Labs Si2168 successfully attached >> > [ 1957.287689] si2157 10-0060: Silicon Labs Si2147/2148/2157/2158 >> > successfully attached >> > [ 1957.498312] sp2 9-0040: CIMaX SP2 successfully attached >> > [ 1957.498348] usb 1-1.3: DVB: registering adapter 0 frontend 0 (Silicon >> > Labs Si2168)... >> > [ 1957.498835] Registered IR keymap rc-tt-1500 >> > [ 1957.499038] input: IR-receiver inside an USB DVB receiver as >> > /devices/pci:00/:00:1a.0/usb1/1-1/1-1.3/rc/rc0/input23 >> > [ 1957.499408] rc0: IR-receiver inside an USB DVB receiver as >> > /devices/pci:00/:00:1a.0/usb1/1-1/1-1.3/rc/rc0 >> > [ 1957.499413] dvb-usb: schedule remote query interval to 150 msecs. >> > [ 1957.499419] dvb-usb: TechnoTrend TT-connect CT2-4650 CI successfully >> > initialized and connected. >> > [ 1963.73] dvb_ca a
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Tue Dec 9 04:00:19 CET 2014 git branch: test git hash: 71947828caef0c83d4245f7d1eaddc799b4ff1d1 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: 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: 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/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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 5/5] media: ov2640: dt: add the device tree binding document
Hi, Laurent
On 12/9/2014 2:59 AM, Laurent Pinchart wrote:
Hi Josh,
Thank you for the patch.
On Monday 08 December 2014 19:29:07 Josh Wu wrote:
Add the document for ov2640 dt.
Cc: devicet...@vger.kernel.org
Signed-off-by: Josh Wu
---
v1 -> v2:
1. change the compatible string to be consistent with verdor file.
That's nice, but you still need to send a patch to add the ovti vendor prefix
to Documentation/devicetree/bindings/vendor-prefixes.txt. It's not there yet.
As Fabio already send a patch to fix the vendor file.
See URL: http://patchwork.ozlabs.org/patch/416685/
I think it will go to mainline soon.
2. change the clock and pins' name.
3. add missed pinctrl in example.
.../devicetree/bindings/media/i2c/ov2640.txt | 44 +++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2640.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/ov2640.txt
b/Documentation/devicetree/bindings/media/i2c/ov2640.txt new file mode
100644
index 000..15be3cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2640.txt
@@ -0,0 +1,44 @@
+* Omnivision ov2640 CMOS sensor
+
+The Omnivision OV2640 sensor support multiple resolutions output, such as
+CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
+output format.
+
+Required Properties :
+- compatible: Must be "ovti,ov2640"
+- clocks: reference master clock, if using external fixed clock, you
+ no need to have such property.
That's not true anymore, the clocks property is mandatory in all cases. Just
describe it as
- clocks: reference to the xvclk input clock.
+- clock-names: Must be "xvclk", it means the master clock for ov2640.
I would drop "it means the master clock for ov2640".
+Optional Properties:
+- resetb-gpios: reset pin
- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.
+- pwdn-gpios: power down pin
- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.
I'll fix all above that you mentioned in next version.
Thank a lot for the review.
Best Regards,
Josh Wu
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c1: i2c@f0018000 {
+ ov2640: camera@0x30 {
+ compatible = "ovti,ov2640";
+ reg = <0x30>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck1 &pinctrl_ov2640_pwdn
&pinctrl_ov2640_reset>;
+
+ resetb-gpios = <&pioE 24 GPIO_ACTIVE_HIGH>;
+ pwdn-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
+
+ clocks = <&pck1>;
+ clock-names = "xvclk";
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint = <&isi_0>;
+ bus-width = <8>;
+ };
+ };
+ };
+ };
--
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 3/5] media: ov2640: add primary dt support
Hi, Laurent
On 12/9/2014 2:39 AM, Laurent Pinchart wrote:
Hi Josh,
Thank you for the patch.
On Monday 08 December 2014 19:29:05 Josh Wu wrote:
Add device tree support for ov2640.
Cc: devicet...@vger.kernel.org
Signed-off-by: Josh Wu
---
v1 -> v2:
1. use gpiod APIs.
2. change the gpio pin's name according to datasheet.
3. reduce the delay for .reset() function.
drivers/media/i2c/soc_camera/ov2640.c | 86 +---
1 file changed, 80 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/ov2640.c
b/drivers/media/i2c/soc_camera/ov2640.c index 9ee910d..2a57979 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -283,6 +285,10 @@ struct ov2640_priv {
u32 cfmt_code;
struct v4l2_clk *clk;
const struct ov2640_win_size*win;
+
+ struct soc_camera_subdev_desc ssdd_dt;
+ struct gpio_desc *resetb_gpio;
+ struct gpio_desc *pwdn_gpio;
};
/*
@@ -1047,6 +1053,61 @@ static struct v4l2_subdev_ops ov2640_subdev_ops = {
.video = &ov2640_subdev_video_ops,
};
+/* OF probe functions */
+static int ov2640_hw_power(struct device *dev, int on)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct ov2640_priv *priv = to_ov2640(client);
+
+ dev_dbg(&client->dev, "%s: %s the camera\n",
+ __func__, on ? "ENABLE" : "DISABLE");
+
+ if (priv->pwdn_gpio && !IS_ERR(priv->pwdn_gpio))
No need to test for IS_ERR, as the probe function would have failed in that
case.
right. I'll change it.
+ gpiod_direction_output(priv->pwdn_gpio, !on);
+
+ return 0;
+}
+
+static int ov2640_hw_reset(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct ov2640_priv *priv = to_ov2640(client);
+
+ /* If enabled, give a reset impulse */
+ if (priv->resetb_gpio && !IS_ERR(priv->resetb_gpio)) {
Same here.
ditto.
+ gpiod_direction_output(priv->resetb_gpio, 0);
Given that your DT should specify the active low GPIO flag, and that the gpiod
API inverts the value in that case, you should set the value to 1 here.
Thanks for the information. I'll fix it.
+ usleep_range(3000, 5000);
+ gpiod_direction_output(priv->resetb_gpio, 1);
And to 0 here.
yes.
+ }
+
+ return 0;
+}
+
+static int ov2640_probe_dt(struct i2c_client *client,
+ struct ov2640_priv *priv)
+{
+ priv->resetb_gpio = devm_gpiod_get_optional(&client->dev, "resetb",
+ GPIOD_OUT_HIGH);
+ if (!priv->resetb_gpio)
+ dev_warn(&client->dev, "resetb gpio not found!\n");
No need to warn here, it's perfectly fine if the reset signal isn't connected
to a GPIO.
I want to print some information if no GPIO is assigned. So I'd like use
dev_dbg() here.
What do you feel?
+ else if (IS_ERR(priv->resetb_gpio))
+ return -EINVAL;
+
+ priv->pwdn_gpio = devm_gpiod_get_optional(&client->dev, "pwdn",
+ GPIOD_OUT_HIGH);
+ if (!priv->pwdn_gpio)
+ dev_warn(&client->dev, "pwdn gpio not found!\n");
Same here.
ditto.
+ else if (IS_ERR(priv->pwdn_gpio))
+ return -EINVAL;
+
+ /* Initialize the soc_camera_subdev_desc */
+ priv->ssdd_dt.power = ov2640_hw_power;
+ priv->ssdd_dt.reset = ov2640_hw_reset;
+ client->dev.platform_data = &priv->ssdd_dt;
+
+ return 0;
+}
+
/*
* i2c_driver functions
*/
@@ -1058,12 +1119,6 @@ static int ov2640_probe(struct i2c_client *client,
struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
int ret;
- if (!ssdd) {
- dev_err(&adapter->dev,
- "OV2640: Missing platform_data for driver\n");
- return -EINVAL;
- }
-
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA)) {
dev_err(&adapter->dev,
"OV2640: I2C-Adapter doesn't support SMBUS\n");
@@ -1077,6 +1132,18 @@ static int ov2640_probe(struct i2c_client *client,
return -ENOMEM;
}
+ if (!ssdd) {
+ if (client->dev.of_node) {
+ ret = ov2640_probe_dt(client, priv);
+ if (ret)
+ return ret;
+ } else {
+ dev_err(&client->dev,
+ "Missing platform_data for driver\n");
+ return -EINVAL;
+ }
I would test for !client->dev.of_node and return the error, you could then get
rid of the else and lower the indentation level for the call to
ov2640_probe_dt().
Okay. I'll change it in next version.
Best Regards,
Josh Wu
Re: [PATCH 4/5] media: ov2640: add a master clock for sensor
Hi, Fabio On 12/8/2014 11:10 PM, Fabio Estevam wrote: On Mon, Dec 8, 2014 at 9:29 AM, Josh Wu wrote: + priv->master_clk = devm_clk_get(&client->dev, "xvclk"); + if (IS_ERR(priv->master_clk)) + return -EINVAL; You should return PTR_ERR(priv->master_clk) instead. sure. I'll fix it in next version. Thanks. Best Regards, Josh Wu -- 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 v3 07/12] smiapp: The sensor only needs a single clock, name may be NULL
The SMIA compatible sensors only need a single clock.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp/smiapp-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index 9852c5f..2f13735 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2482,7 +2482,7 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
}
if (!sensor->platform_data->set_xclk) {
- sensor->ext_clk = devm_clk_get(&client->dev, "ext_clk");
+ sensor->ext_clk = devm_clk_get(&client->dev, NULL);
if (IS_ERR(sensor->ext_clk)) {
dev_err(&client->dev, "could not get clock\n");
return PTR_ERR(sensor->ext_clk);
--
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 v3 05/12] smiapp: Don't give the source sub-device a temporary name
The source sub-device's name will be overwritten shortly. Don't give it a name in the meantime. Signed-off-by: Sakari Ailus --- drivers/media/i2c/smiapp/smiapp-core.c |2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/i2c/smiapp/smiapp-core.c b/drivers/media/i2c/smiapp/smiapp-core.c index ab917a6..92a7840 100644 --- a/drivers/media/i2c/smiapp/smiapp-core.c +++ b/drivers/media/i2c/smiapp/smiapp-core.c @@ -2458,8 +2458,6 @@ static int smiapp_identify_module(struct v4l2_subdev *subdev) minfo->name, minfo->manufacturer_id, minfo->model_id, minfo->revision_number_major); - strlcpy(subdev->name, sensor->minfo.name, sizeof(subdev->name)); - return 0; } -- 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 v3 08/12] of: v4l: Document link-frequencies property in video-interfaces.txt
link-frequencies is a 64-bit unsigned integer array of allowed link frequencies. Signed-off-by: Sakari Ailus --- Documentation/devicetree/bindings/media/video-interfaces.txt |3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index ce719f8..52a14cf 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -103,6 +103,9 @@ Optional endpoint properties array contains only one entry. - clock-noncontinuous: a boolean property to allow MIPI CSI-2 non-continuous clock mode. +- link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for + instance, this is the actual frequency of the bus, not bits per clock per + lane value. An array of 64-bit unsigned integers. Example -- 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 v3 06/12] smiapp: Register async subdev
Register and unregister async sub-device for DT.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp/smiapp-core.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index 92a7840..9852c5f 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2942,8 +2942,21 @@ static int smiapp_probe(struct i2c_client *client,
sensor->src->sensor = sensor;
sensor->src->pads[0].flags = MEDIA_PAD_FL_SOURCE;
- return media_entity_init(&sensor->src->sd.entity, 2,
+ rval = media_entity_init(&sensor->src->sd.entity, 2,
sensor->src->pads, 0);
+ if (rval < 0)
+ return rval;
+
+ rval = v4l2_async_register_subdev(&sensor->src->sd);
+ if (rval < 0)
+ goto out_media_entity_cleanup;
+
+ return 0;
+
+out_media_entity_cleanup:
+ media_entity_cleanup(&sensor->src->sd.entity);
+
+ return rval;
}
static int smiapp_remove(struct i2c_client *client)
@@ -2952,6 +2965,8 @@ static int smiapp_remove(struct i2c_client *client)
struct smiapp_sensor *sensor = to_smiapp_sensor(subdev);
unsigned int i;
+ v4l2_async_unregister_subdev(subdev);
+
if (sensor->power_count) {
if (gpio_is_valid(sensor->platform_data->xshutdown))
gpio_set_value(sensor->platform_data->xshutdown, 0);
--
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 v3 10/12] 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
---
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 2f13735..1e60f4a 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -25,11 +25,13 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include "smiapp.h"
@@ -2919,19 +2921,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-frequencies", &asize) ? 0 : -ENOENT;
+ if (rval) {
+ dev_warn(dev, "can't get link-frequencies 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-frequencies", 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];
@@ -2990,6 +3094,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 i2c_device_id smiapp_id_table[] = {
{ SMIAPP_NAME, 0 },
{ },
@@ -3003,6 +3112,7 @@ static const struct dev_pm_ops smiapp_pm_ops = {
static struc
[REVIEW PATCH v3 12/12] smiapp: Fully probe the device in probe
In the case of platform data, ISPs that provide clocks to the sensor must
probe before the sensor does. Accessing the sensor does require the clocks,
and thus, probe cannot access the sensor in such a system.
This limitation does not exist in the case of the DT. Perform all
initialisation except Media entity initialisation, link creation and
sub-device registration in probe.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp/smiapp-core.c | 68 +---
1 file changed, 46 insertions(+), 22 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index c2bf718..48e1a1f 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2334,10 +2334,9 @@ static DEVICE_ATTR(ident, S_IRUGO,
smiapp_sysfs_ident_read, NULL);
* V4L2 subdev core operations
*/
-static int smiapp_identify_module(struct v4l2_subdev *subdev)
+static int smiapp_identify_module(struct smiapp_sensor *sensor)
{
- struct smiapp_sensor *sensor = to_smiapp_sensor(subdev);
- struct i2c_client *client = v4l2_get_subdevdata(subdev);
+ struct i2c_client *client = v4l2_get_subdevdata(&sensor->src->sd);
struct smiapp_module_info *minfo = &sensor->minfo;
unsigned int i;
int rval = 0;
@@ -2517,10 +2516,17 @@ static int smiapp_register_subdevs(struct smiapp_sensor
*sensor)
return 0;
}
-static int smiapp_registered(struct v4l2_subdev *subdev)
+static void smiapp_cleanup(struct smiapp_sensor *sensor)
{
- struct smiapp_sensor *sensor = to_smiapp_sensor(subdev);
- struct i2c_client *client = v4l2_get_subdevdata(subdev);
+ struct i2c_client *client = v4l2_get_subdevdata(&sensor->src->sd);
+
+ device_remove_file(&client->dev, &dev_attr_nvm);
+ device_remove_file(&client->dev, &dev_attr_ident);
+}
+
+static int smiapp_init(struct smiapp_sensor *sensor)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&sensor->src->sd);
struct smiapp_pll *pll = &sensor->pll;
struct smiapp_subdev *last = NULL;
u32 tmp;
@@ -2566,7 +2572,7 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
if (rval)
return -ENODEV;
- rval = smiapp_identify_module(subdev);
+ rval = smiapp_identify_module(sensor);
if (rval) {
rval = -ENODEV;
goto out_power_off;
@@ -2646,13 +2652,13 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
if (sensor->nvm == NULL) {
dev_err(&client->dev, "nvm buf allocation failed\n");
rval = -ENOMEM;
- goto out_ident_release;
+ goto out_cleanup;
}
if (device_create_file(&client->dev, &dev_attr_nvm) != 0) {
dev_err(&client->dev, "sysfs nvm entry failed\n");
rval = -EBUSY;
- goto out_ident_release;
+ goto out_cleanup;
}
}
@@ -2696,7 +2702,7 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
rval = smiapp_get_mbus_formats(sensor);
if (rval) {
rval = -ENODEV;
- goto out_nvm_release;
+ goto out_cleanup;
}
for (i = 0; i < SMIAPP_SUBDEVS; i++) {
@@ -2758,10 +2764,6 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
last = this;
}
- rval = smiapp_register_subdevs(sensor);
- if (rval)
- goto out_nvm_release;
-
dev_dbg(&client->dev, "profile %d\n", sensor->minfo.smiapp_profile);
sensor->pixel_array->sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
@@ -2770,14 +2772,14 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
smiapp_read_frame_fmt(sensor);
rval = smiapp_init_controls(sensor);
if (rval < 0)
- goto out_nvm_release;
+ goto out_cleanup;
mutex_lock(&sensor->mutex);
rval = smiapp_update_mode(sensor);
mutex_unlock(&sensor->mutex);
if (rval) {
dev_err(&client->dev, "update mode failed\n");
- goto out_nvm_release;
+ goto out_cleanup;
}
sensor->streaming = false;
@@ -2787,23 +2789,39 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
rval = smiapp_read(sensor, SMIAPP_REG_U8_FLASH_MODE_CAPABILITY, &tmp);
sensor->flash_capability = tmp;
if (rval)
- goto out_nvm_release;
+ goto out_cleanup;
smiapp_power_off(sensor);
return 0;
-out_nvm_release:
- device_remove_file(&client->dev, &dev_attr_nvm);
-
-out_ident_release:
- device_remove_file(&client->dev, &dev_attr_ident);
+out_cleanup:
+ smiapp_cleanup(sensor);
out_power_off:
smiapp_power_off(sensor);
return rval
[REVIEW PATCH v3 09/12] of: smiapp: Add documentation
Document the smiapp device tree properties.
Signed-off-by: Sakari Ailus
---
.../devicetree/bindings/media/i2c/nokia,smia.txt | 63
MAINTAINERS|1 +
2 files changed, 64 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..855e1fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/nokia,smia.txt
@@ -0,0 +1,63 @@
+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 to the sensor
+- clock-frequency: Frequency of the external clock to the sensor
+- link-frequencies: 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-frequency = <960>;
+ nokia,nvm-size = <512>; /* 8 * 64 */
+ link-frequencies = /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 f2d9159..437981a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8625,6 +8625,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
--
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 v3 02/12] smiapp: List include/uapi/linux/smiapp.h in MAINTAINERS
This is part of the smiapp driver. Signed-off-by: Sakari Ailus --- MAINTAINERS |1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 9c49eb6..f2d9159 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8624,6 +8624,7 @@ F:drivers/media/i2c/smiapp/ 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 SMM665 HARDWARE MONITOR DRIVER M: Guenter Roeck -- 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 v3 11/12] smiapp: Split sub-device initialisation off from the registered callback
The registered callback is called by the V4L2 async framework after the
bound callback. This allows separating the functionality in the registered
callback so that on DT based systems only sub-device registration is done
there.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/smiapp/smiapp-core.c | 82 +---
1 file changed, 54 insertions(+), 28 deletions(-)
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index 1e60f4a..c2bf718 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -2467,6 +2467,56 @@ static const struct v4l2_subdev_ops smiapp_ops;
static const struct v4l2_subdev_internal_ops smiapp_internal_ops;
static const struct media_entity_operations smiapp_entity_ops;
+static int smiapp_register_subdevs(struct smiapp_sensor *sensor)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(&sensor->src->sd);
+ struct smiapp_subdev *ssds[] = {
+ sensor->scaler,
+ sensor->binner,
+ sensor->pixel_array,
+ };
+ unsigned int i;
+ int rval;
+
+ for (i = 0; i < SMIAPP_SUBDEVS - 1; i++) {
+ struct smiapp_subdev *this = ssds[i + 1];
+ struct smiapp_subdev *last = ssds[i];
+
+ if (!last)
+ continue;
+
+ rval = media_entity_init(&this->sd.entity,
+this->npads, this->pads, 0);
+ if (rval) {
+ dev_err(&client->dev,
+ "media_entity_init failed\n");
+ return rval;
+ }
+
+ rval = media_entity_create_link(&this->sd.entity,
+ this->source_pad,
+ &last->sd.entity,
+ last->sink_pad,
+ MEDIA_LNK_FL_ENABLED |
+ MEDIA_LNK_FL_IMMUTABLE);
+ if (rval) {
+ dev_err(&client->dev,
+ "media_entity_create_link failed\n");
+ return rval;
+ }
+
+ rval = v4l2_device_register_subdev(sensor->src->sd.v4l2_dev,
+ &this->sd);
+ if (rval) {
+ dev_err(&client->dev,
+ "v4l2_device_register_subdev failed\n");
+ return rval;
+ }
+ }
+
+ return 0;
+}
+
static int smiapp_registered(struct v4l2_subdev *subdev)
{
struct smiapp_sensor *sensor = to_smiapp_sensor(subdev);
@@ -2705,37 +2755,13 @@ static int smiapp_registered(struct v4l2_subdev *subdev)
this->sd.owner = THIS_MODULE;
v4l2_set_subdevdata(&this->sd, client);
- rval = media_entity_init(&this->sd.entity,
-this->npads, this->pads, 0);
- if (rval) {
- dev_err(&client->dev,
- "media_entity_init failed\n");
- goto out_nvm_release;
- }
-
- rval = media_entity_create_link(&this->sd.entity,
- this->source_pad,
- &last->sd.entity,
- last->sink_pad,
- MEDIA_LNK_FL_ENABLED |
- MEDIA_LNK_FL_IMMUTABLE);
- if (rval) {
- dev_err(&client->dev,
- "media_entity_create_link failed\n");
- goto out_nvm_release;
- }
-
- rval = v4l2_device_register_subdev(sensor->src->sd.v4l2_dev,
- &this->sd);
- if (rval) {
- dev_err(&client->dev,
- "v4l2_device_register_subdev failed\n");
- goto out_nvm_release;
- }
-
last = this;
}
+ rval = smiapp_register_subdevs(sensor);
+ if (rval)
+ goto out_nvm_release;
+
dev_dbg(&client->dev, "profile %d\n", sensor->minfo.smiapp_profile);
sensor->pixel_array->sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_SENSOR;
--
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 v3 04/12] smiapp: Use types better suitable for DT
Signed-off-by: Sakari Ailus
---
include/media/smiapp.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/media/smiapp.h b/include/media/smiapp.h
index 0b8f124..268a3cd 100644
--- a/include/media/smiapp.h
+++ b/include/media/smiapp.h
@@ -65,19 +65,19 @@ struct smiapp_platform_data {
unsigned short i2c_addr_dfl;/* Default i2c addr */
unsigned short i2c_addr_alt;/* Alternate i2c addr */
- unsigned int nvm_size; /* bytes */
- unsigned int ext_clk; /* sensor external clk */
+ uint32_t nvm_size; /* bytes */
+ uint32_t ext_clk; /* sensor external clk */
unsigned int lanes; /* Number of CSI-2 lanes */
- u8 csi_signalling_mode; /* SMIAPP_CSI_SIGNALLING_MODE_* */
- const s64 *op_sys_clock;
+ uint32_t csi_signalling_mode; /* SMIAPP_CSI_SIGNALLING_MODE_* */
+ uint64_t *op_sys_clock;
enum smiapp_module_board_orient module_board_orient;
struct smiapp_flash_strobe_parms *strobe_setup;
int (*set_xclk)(struct v4l2_subdev *sd, int hz);
- int xshutdown; /* gpio or SMIAPP_NO_XSHUTDOWN */
+ int32_t xshutdown; /* gpio or SMIAPP_NO_XSHUTDOWN */
};
#endif /* __SMIAPP_H_ */
--
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 v3 00/12] smiapp OF support
Hi all,
This patchset adds support for Device tree in the smiapp driver. Platform
data support is retained as well. The actual DT related changes are
prepended by a few simple cleanups.
A new link-frequency property is defined in video-interfaces.txt, as this is
hardly something which is specific to the SMIA compliant sensors.
since v2:
- patch 8 (now 9) "of: smiapp: Add documentation":
- Cleanups
- Removed clock-names property documentation
- Port node documentation was really endpoint node documentation
- Added remote-endpoint as mandatory endpoint node properties
- Rename link-frequency property as link-frequencies
- Removed clock-names property from the DT example
- Fix clock property documentation
- Use struct smiapp_sensor pointer as an argument to many functions, instead
of struct v4l2_subdev pointer. This modifies patch "smiapp: Fully probe
the device in probe".
- smiapp_subdev_{init,cleanup} renamed as smiapp_{init,cleanup} (same patch)
- Remove redundant sub-device name change, patch "smiapp: Don't give the
source sub-device a temporary name" added to the set.
since v1:
- Only use dev->of_node to determine whether the OF node is there.
- Add clock-lanes and data-lanes properties to mandatory properties list in
documentation.
- Add a patch to include include/uapi/linux/smiapp.h in MAINTAINERS section
for the smiapp driver.
--
Kind regards,
Sakari
--
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 v3 03/12] smiapp-pll: include linux/device.h in smiapp-pll.c, not in smiapp-pll.h
struct device has a forward declaration in the header already. The header is only needed in the .c file. Signed-off-by: Sakari Ailus --- drivers/media/i2c/smiapp-pll.c |1 + drivers/media/i2c/smiapp-pll.h |2 -- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/media/i2c/smiapp-pll.c b/drivers/media/i2c/smiapp-pll.c index 2b84d09..e3348db 100644 --- a/drivers/media/i2c/smiapp-pll.c +++ b/drivers/media/i2c/smiapp-pll.c @@ -16,6 +16,7 @@ * General Public License for more details. */ +#include #include #include #include diff --git a/drivers/media/i2c/smiapp-pll.h b/drivers/media/i2c/smiapp-pll.h index 77f7ff2f..b98d143 100644 --- a/drivers/media/i2c/smiapp-pll.h +++ b/drivers/media/i2c/smiapp-pll.h @@ -19,8 +19,6 @@ #ifndef SMIAPP_PLL_H #define SMIAPP_PLL_H -#include - /* CSI-2 or CCP-2 */ #define SMIAPP_PLL_BUS_TYPE_CSI2 0x00 #define SMIAPP_PLL_BUS_TYPE_PARALLEL 0x01 -- 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 v3 01/12] smiapp: Remove FSF's address from the license header
Remove FSF's address information from the license header in the smiapp driver and the smiapp-pll PLL calculator. This should no longer be needed, and would be rendered outdated in case the FSF chooses to relocate its office. Signed-off-by: Sakari Ailus Cc: Timo Ahonen --- drivers/media/i2c/smiapp-pll.c |6 -- drivers/media/i2c/smiapp-pll.h |6 -- drivers/media/i2c/smiapp/smiapp-core.c |6 -- drivers/media/i2c/smiapp/smiapp-limits.c |6 -- drivers/media/i2c/smiapp/smiapp-limits.h |6 -- drivers/media/i2c/smiapp/smiapp-quirk.c|6 -- drivers/media/i2c/smiapp/smiapp-quirk.h|6 -- drivers/media/i2c/smiapp/smiapp-reg-defs.h |6 -- drivers/media/i2c/smiapp/smiapp-reg.h |6 -- drivers/media/i2c/smiapp/smiapp-regs.c |6 -- drivers/media/i2c/smiapp/smiapp-regs.h |6 -- drivers/media/i2c/smiapp/smiapp.h |6 -- 12 files changed, 72 deletions(-) diff --git a/drivers/media/i2c/smiapp-pll.c b/drivers/media/i2c/smiapp-pll.c index e40d902..2b84d09 100644 --- a/drivers/media/i2c/smiapp-pll.c +++ b/drivers/media/i2c/smiapp-pll.c @@ -14,12 +14,6 @@ * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA - * 02110-1301 USA - * */ #include diff --git a/drivers/media/i2c/smiapp-pll.h b/drivers/media/i2c/smiapp-pll.h index e8f035a..77f7ff2f 100644 --- a/drivers/media/i2c/smiapp-pll.h +++ b/drivers/media/i2c/smiapp-pll.h @@ -14,12 +14,6 @@ * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA - * 02110-1301 USA - * */ #ifndef SMIAPP_PLL_H diff --git a/drivers/media/i2c/smiapp/smiapp-core.c b/drivers/media/i2c/smiapp/smiapp-core.c index 65e4e05..ab917a6 100644 --- a/drivers/media/i2c/smiapp/smiapp-core.c +++ b/drivers/media/i2c/smiapp/smiapp-core.c @@ -18,12 +18,6 @@ * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA - * 02110-1301 USA - * */ #include diff --git a/drivers/media/i2c/smiapp/smiapp-limits.c b/drivers/media/i2c/smiapp/smiapp-limits.c index 847cb23..784b114 100644 --- a/drivers/media/i2c/smiapp/smiapp-limits.c +++ b/drivers/media/i2c/smiapp/smiapp-limits.c @@ -14,12 +14,6 @@ * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA - * 02110-1301 USA - * */ #include "smiapp.h" diff --git a/drivers/media/i2c/smiapp/smiapp-limits.h b/drivers/media/i2c/smiapp/smiapp-limits.h index 343e9c3..b201248 100644 --- a/drivers/media/i2c/smiapp/smiapp-limits.h +++ b/drivers/media/i2c/smiapp/smiapp-limits.h @@ -14,12 +14,6 @@ * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA - * 02110-1301 USA - * */ #define SMIAPP_LIMIT_ANALOGUE_GAIN_CAPABILITY 0 diff --git a/drivers/media/i2c/smiapp/smiapp-quirk.c b/drivers/media/i2c/smiapp/smiapp-quirk.c index e0bee87..dd4ae6f 100644 --- a/drivers/media/i2c/smiapp/smiapp-quirk.c +++ b/drivers/media/i2c/smiapp/smiapp-quirk.c @@ -14,12 +14,6 @@ * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA - * 02110-1301 USA - * */ #include diff --git a/drivers/media/i2c/smiapp/smiapp-qui
[PATCH v5] media: platform: add VPFE capture driver support for AM437X
From: Benoit Parrot This patch adds Video Processing Front End (VPFE) driver for AM437X family of devices Driver supports the following: - V4L2 API using MMAP buffer access based on videobuf2 api - Asynchronous sensor/decoder sub device registration - DT support Signed-off-by: Benoit Parrot Signed-off-by: Darren Etheridge Signed-off-by: Lad, Prabhakar --- Changes for v5: 1: Fixed review comments pointed out by Hans, fixing race condition. v4l2-compliance output:- -- root@am437x-evm:~# ./v4l2-compliance -s -i 0 -vv Driver Info: Driver name : vpfe Card type :[ 262.490769] vpfe 48328000.vpfe: = START STATUS = TI AM437x VPFE Bus info : platform:vpfe [ 262.502285] vpfe 48328000.vpfe: == END STATUS == 48328000.vpfe Driver version: 3.18.0 Capabil[ 262.515396] vpfe 48328000.vpfe: invalid input index: 1 ities : 0x8521 Video Capture Read/Write Streaming Extended Pix Format Device Capabilities Device Caps : 0x0521 Video Capture Read/Write Streaming Extended Pix Format Compliance test for device /dev/video0 (not using libv4l2): Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second video open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 1 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Test input 0: Control ioctls: test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported) test VIDIOC_QUERYCTRL: OK (Not Supported) test VIDIOC_G/S_CTRL: OK (Not Supported) test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) Standard Controls: 0 Private Controls: 0 Format ioctls: info: found 7 framesizes for pixel format 56595559 info: found 7 framesizes for pixel format 59565955 info: found 7 framesizes for pixel format 52424752 info: found 7 framesizes for pixel format 31384142 info: found 4 formats for buftype 1 test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK test VIDIOC_G/S_PARM: OK test VIDIOC_G_FBUF: OK (Not Supported) test VIDIOC_G_FMT: OK test VIDIOC_TRY_FMT: OK info: Could not perform global format test test VIDIOC_S_FMT: OK test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) test Cropping: OK test Composing: OK (Not Supported) test Scaling: OK (Not Supported) Codec ioctls: test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) test VIDIOC_G_ENC_INDEX: OK (Not Supported) test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) Buffer ioctls: info: test buftype Video Capture test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK test VIDIOC_EXPBUF: OK Streaming ioctls: test read/write: OK Video Capture: Buffer: 0 Sequence: 0 Field: None Timestamp: 267.115428s Buffer: 1 Sequence: 1 Field: None Timestamp: 267.138308s Buffer: 2 Sequence: 2 Field: None Timestamp: 267.161189s Buffer: 3 Sequence: 3 Field: None Timestamp: 267.367114s Buffer: 0 Sequence: 4 Field: None Timestamp: 267.389994s Buffer: 1 Sequence: 5 Field: None Timestamp: 267.412874s Buffer: 2 Sequence: 6 Field: None Timestamp: 267.435755s Buffer: 3 Sequence: 7 Field: None Timestamp:
Re: [PATCH 2/2] mn88472: implement firmware parity check
Reviewed-by: Antti Palosaari
PS. something to say about logging levels... but as it is staging
driver, criteria for patches is not so high yet.
regards
Antti
On 12/08/2014 10:31 PM, Benjamin Larsson wrote:
Signed-off-by: Benjamin Larsson
---
drivers/staging/media/mn88472/mn88472.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/staging/media/mn88472/mn88472.c
b/drivers/staging/media/mn88472/mn88472.c
index df7dbe9..1df85a7 100644
--- a/drivers/staging/media/mn88472/mn88472.c
+++ b/drivers/staging/media/mn88472/mn88472.c
@@ -294,6 +294,7 @@ static int mn88472_init(struct dvb_frontend *fe)
int ret, len, remaining;
const struct firmware *fw = NULL;
u8 *fw_file = MN88472_FIRMWARE;
+ unsigned int csum;
dev_dbg(&client->dev, "\n");
@@ -346,6 +347,20 @@ static int mn88472_init(struct dvb_frontend *fe)
}
}
+ /* parity check of firmware */
+ ret = regmap_read(dev->regmap[0], 0xf8, &csum);
+ if (ret) {
+ dev_err(&client->dev,
+ "parity reg read failed=%d\n", ret);
+ goto err;
+ }
+ if (csum & 0x10) {
+ dev_err(&client->dev,
+ "firmware parity check failed=0x%x\n", csum);
+ goto err;
+ }
+ dev_err(&client->dev, "firmware parity check succeeded=0x%x\n", csum);
+
ret = regmap_write(dev->regmap[0], 0xf5, 0x00);
if (ret)
goto err;
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mn88472: fix firmware downloading
On 12/08/2014 09:55 PM, Antti Palosaari wrote: Moikka! But that patch is rather useless :] Only thing needed is to change existing value in file drivers/media/usb/dvb-usb-v2/rtl28xxu.c : mn88472_config.i2c_wr_max = 22, ... and that leaves room for use even smaller values if there is an I2C adapter which cannot write even 17 bytes. 2nd thing is to add comment mn88472.h to specify that max limit and that's all. regards Antti Ok, I'll do that. MvH Benjamin Larsson -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mn88472: fix firmware downloading
Moikka!
But that patch is rather useless :] Only thing needed is to change
existing value in file drivers/media/usb/dvb-usb-v2/rtl28xxu.c :
mn88472_config.i2c_wr_max = 22,
... and that leaves room for use even smaller values if there is an I2C
adapter which cannot write even 17 bytes.
2nd thing is to add comment mn88472.h to specify that max limit and
that's all.
regards
Antti
On 12/08/2014 10:31 PM, Benjamin Larsson wrote:
The max amount of payload bytes in each i2c transfer when
loading the demodulator firmware is 16 bytes.
Signed-off-by: Benjamin Larsson
---
drivers/staging/media/mn88472/mn88472.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/mn88472/mn88472.c
b/drivers/staging/media/mn88472/mn88472.c
index ffee187..df7dbe9 100644
--- a/drivers/staging/media/mn88472/mn88472.c
+++ b/drivers/staging/media/mn88472/mn88472.c
@@ -15,6 +15,7 @@
*/
#include "mn88472_priv.h"
+#define FW_BUF_SIZE 16
static int mn88472_get_tune_settings(struct dvb_frontend *fe,
struct dvb_frontend_tune_settings *s)
@@ -331,10 +332,10 @@ static int mn88472_init(struct dvb_frontend *fe)
goto err;
for (remaining = fw->size; remaining > 0;
- remaining -= (dev->i2c_wr_max - 1)) {
+ remaining -= FW_BUF_SIZE) {
len = remaining;
- if (len > (dev->i2c_wr_max - 1))
- len = (dev->i2c_wr_max - 1);
+ if (len > FW_BUF_SIZE)
+ len = FW_BUF_SIZE;
ret = regmap_bulk_write(dev->regmap[0], 0xf6,
&fw->data[fw->size - remaining], len);
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wintv-hvr-1955 status
It is certainly possible that I have not found the right place in which to ask this question. If someone could direct me to the correct person/forum, I would most appreciate it. Thanks Steve On 12/04/2014 03:11 PM, Steven Saner wrote: > Hi: > > I have a wintv-hvr-1955 (sold as a wintv-hvr-1950) from Hauppauge. > > I referenced a thread in this list in June 2014 > > http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/78952/match=wintv+hvr+1955 > > as well as this wiki page > > http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-1950 > > Both of the above suggest that a Linux driver for this device is > available from Hauppauge after signing an NDA. So I contacted them on > Nov 19 and they responded with the following message: > > --- > A driver has been recently submitted to Linux TV and is awaiting > approval. This process can take anywhere from 2 weeks to 3 months. > --- > > I am wondering if this is true and if I can get a status of this or an > ETA. Is there anything available that I can try? Will support for this > device be included in the pvrusb2 driver (like the 1950) or in something > else? > > Thanks for any information or suggestions. > > Steve > -- -- Steven Saner Voice: 316-858-3000 Director of Network Operations Fax: 316-858-3001 Hubris Communicationshttp://www.hubris.net -- 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] mn88472: fix firmware downloading
The max amount of payload bytes in each i2c transfer when
loading the demodulator firmware is 16 bytes.
Signed-off-by: Benjamin Larsson
---
drivers/staging/media/mn88472/mn88472.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/mn88472/mn88472.c
b/drivers/staging/media/mn88472/mn88472.c
index ffee187..df7dbe9 100644
--- a/drivers/staging/media/mn88472/mn88472.c
+++ b/drivers/staging/media/mn88472/mn88472.c
@@ -15,6 +15,7 @@
*/
#include "mn88472_priv.h"
+#define FW_BUF_SIZE 16
static int mn88472_get_tune_settings(struct dvb_frontend *fe,
struct dvb_frontend_tune_settings *s)
@@ -331,10 +332,10 @@ static int mn88472_init(struct dvb_frontend *fe)
goto err;
for (remaining = fw->size; remaining > 0;
- remaining -= (dev->i2c_wr_max - 1)) {
+ remaining -= FW_BUF_SIZE) {
len = remaining;
- if (len > (dev->i2c_wr_max - 1))
- len = (dev->i2c_wr_max - 1);
+ if (len > FW_BUF_SIZE)
+ len = FW_BUF_SIZE;
ret = regmap_bulk_write(dev->regmap[0], 0xf6,
&fw->data[fw->size - remaining], len);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] mn88472: implement firmware parity check
Signed-off-by: Benjamin Larsson
---
drivers/staging/media/mn88472/mn88472.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/staging/media/mn88472/mn88472.c
b/drivers/staging/media/mn88472/mn88472.c
index df7dbe9..1df85a7 100644
--- a/drivers/staging/media/mn88472/mn88472.c
+++ b/drivers/staging/media/mn88472/mn88472.c
@@ -294,6 +294,7 @@ static int mn88472_init(struct dvb_frontend *fe)
int ret, len, remaining;
const struct firmware *fw = NULL;
u8 *fw_file = MN88472_FIRMWARE;
+ unsigned int csum;
dev_dbg(&client->dev, "\n");
@@ -346,6 +347,20 @@ static int mn88472_init(struct dvb_frontend *fe)
}
}
+ /* parity check of firmware */
+ ret = regmap_read(dev->regmap[0], 0xf8, &csum);
+ if (ret) {
+ dev_err(&client->dev,
+ "parity reg read failed=%d\n", ret);
+ goto err;
+ }
+ if (csum & 0x10) {
+ dev_err(&client->dev,
+ "firmware parity check failed=0x%x\n", csum);
+ goto err;
+ }
+ dev_err(&client->dev, "firmware parity check succeeded=0x%x\n", csum);
+
ret = regmap_write(dev->regmap[0], 0xf5, 0x00);
if (ret)
goto err;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension
On Mon 2014-12-08 17:55:20, Jacek Anaszewski wrote: > On 12/06/2014 01:43 PM, Pavel Machek wrote: > > > >>>The format of a sysfs attribute should be concise. > >>>The error codes are generic and map directly to the V4L2 Flash > >>>error codes. > >>> > >> > >>Actually I'd like to see those flash fault code defined in LED > >>subsystem. And V4L2 will just include LED flash header file to use it. > >>Because flash fault code is not for V4L2 specific but it's a feature > >>of LED flash devices. > >> > >>For clearing error code of flash devices, I think it depends on the > >>hardware. If most of our LED flash is using reading to clear error > >>code, we probably can make it simple as this now. But what if some > >>other LED flash devices are using writing to clear error code? we > >>should provide a API to that? > > > >Actually, we should provide API that makes sense, and that is easy to > >use by userspace. > > > >I believe "read" is called read because it does not change anything, > >and it should stay that way in /sysfs. You may want to talk to sysfs > >maintainers if you plan on doing another semantics. > > How would you proceed in case of devices which clear their fault > register upon I2C readout (e.g. AS3645)? In this case read does have > a side effect. For such devices attribute semantics would have to be > different than for the devices which don't clear faults on readout. No, semantics should be same for all devices. If device clears fault register during I2C readout, kernel will simply gather faults in an variable, and clear them upon write to sysfs file. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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
[PATCH] [media] uvcvideo: Add GUID for BGR 8:8:8
The Magewell XI100DUSB-HDMI[1] video capture device reports the pixel
format "e436eb7d-524f-11ce-9f53-0020af0ba770". This is its GUID for
BGR 8:8:8.
The UVC 1.5 spec[2] only defines GUIDs for YUY2, NV12, M420 and I420.
This seems to be an extension documented in the Microsoft Windows Media
Format SDK[3] - or at least the Media Format SDK was the only hit that
Google gave when searching for the GUID. This Media Format SDK defines
this GUID as corresponding to `MEDIASUBTYPE_RGB24`. Note though, the
XI100DUSB outputs BGR e.g. byte-reversed. I don't know if its the
capture device in error or Microsoft mean BGR when they say RGB.
[1]:
http://www.magewell.com/hardware/dongles/xi100dusb-hdmi/xi100dusb-hdmi_features.html?lang=en
[2]: http://www.usb.org/developers/docs/devclass_docs/USB_Video_Class_1_5.zip
[3]:
http://msdn.microsoft.com/en-gb/library/windows/desktop/dd757532(v=vs.85).aspx
Signed-off-by: William Manley
---
drivers/media/usb/uvc/uvc_driver.c | 5 +
drivers/media/usb/uvc/uvcvideo.h | 3 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 7c8322d..dc7cff1 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -138,6 +138,11 @@ static struct uvc_format_desc uvc_fmts[] = {
.fcc= V4L2_PIX_FMT_RGB565,
},
{
+ .name = "BGR 8:8:8 (BGR3)",
+ .guid = UVC_GUID_FORMAT_BGR3,
+ .fcc= V4L2_PIX_FMT_BGR24,
+ },
+ {
.name = "H.264",
.guid = UVC_GUID_FORMAT_H264,
.fcc= V4L2_PIX_FMT_H264,
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 864ada7..ed0210d 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -109,6 +109,9 @@
#define UVC_GUID_FORMAT_RGBP \
{ 'R', 'G', 'B', 'P', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
+#define UVC_GUID_FORMAT_BGR3 \
+ { 0x7d, 0xeb, 0x36, 0xe4, 0x4f, 0x52, 0xce, 0x11, \
+0x9f, 0x53, 0x00, 0x20, 0xaf, 0x0b, 0xa7, 0x70}
#define UVC_GUID_FORMAT_M420 \
{ 'M', '4', '2', '0', 0x00, 0x00, 0x10, 0x00, \
0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
--
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 5/5] media: ov2640: dt: add the device tree binding document
Hi Josh,
Thank you for the patch.
On Monday 08 December 2014 19:29:07 Josh Wu wrote:
> Add the document for ov2640 dt.
>
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Josh Wu
> ---
> v1 -> v2:
> 1. change the compatible string to be consistent with verdor file.
That's nice, but you still need to send a patch to add the ovti vendor prefix
to Documentation/devicetree/bindings/vendor-prefixes.txt. It's not there yet.
> 2. change the clock and pins' name.
> 3. add missed pinctrl in example.
>
> .../devicetree/bindings/media/i2c/ov2640.txt | 44 +++
> 1 file changed, 44 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2640.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov2640.txt
> b/Documentation/devicetree/bindings/media/i2c/ov2640.txt new file mode
> 100644
> index 000..15be3cb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov2640.txt
> @@ -0,0 +1,44 @@
> +* Omnivision ov2640 CMOS sensor
> +
> +The Omnivision OV2640 sensor support multiple resolutions output, such as
> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
> +output format.
> +
> +Required Properties :
> +- compatible: Must be "ovti,ov2640"
> +- clocks: reference master clock, if using external fixed clock, you
> + no need to have such property.
That's not true anymore, the clocks property is mandatory in all cases. Just
describe it as
- clocks: reference to the xvclk input clock.
> +- clock-names: Must be "xvclk", it means the master clock for ov2640.
I would drop "it means the master clock for ov2640".
> +Optional Properties:
> +- resetb-gpios: reset pin
- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.
> +- pwdn-gpios: power down pin
- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.
> +
> +The device node must contain one 'port' child node for its digital output
> +video port, in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> +
> + i2c1: i2c@f0018000 {
> + ov2640: camera@0x30 {
> + compatible = "ovti,ov2640";
> + reg = <0x30>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pck1 &pinctrl_ov2640_pwdn
&pinctrl_ov2640_reset>;
> +
> + resetb-gpios = <&pioE 24 GPIO_ACTIVE_HIGH>;
> + pwdn-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
> +
> + clocks = <&pck1>;
> + clock-names = "xvclk";
> +
> + port {
> + ov2640_0: endpoint {
> + remote-endpoint = <&isi_0>;
> + bus-width = <8>;
> + };
> + };
> + };
> + };
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mn88472: fix firmware loading
On 12/08/2014 06:46 PM, Antti Palosaari wrote: Hello! [...] regmap_bulk_write(): Write multiple registers to the device In this case we want to write multiple bytes to the same register. So I think that my patch is correct in principle. You haven't make any test whether it is possible to write that firmware in a large chunks *or* writing one byte (smallest possible ~chuck) at the time? I think it does not matter. I suspect you could even download whole firmware as one go - but rtl2832p I2C adapter does support only 22 bytes on one xfer. Even those are written to one register, chip knows how many bytes one message has and could increase its internal address counter. That is usually called register address auto-increment. A) writing: f6 00 f6 01 f6 02 f6 03 f6 04 f6 05 f6 06 f6 07 f6 08 f6 09 B) writing: f6 00 01 02 03 04 f6 05 06 07 08 09 will likely end up same. B is better as only 2 xfers are done - much less IO. regards Antti Hello Antti. I have now tried the following patch on top of my load defaults patch. index a7d35bb..fd9796d --- a/drivers/staging/media/mn88472/mn88472.c +++ b/drivers/staging/media/mn88472/mn88472.c @@ -467,7 +467,7 @@ static int mn88472_probe(struct i2c_client *client, goto err; } - dev->i2c_wr_max = config->i2c_wr_max; + dev->i2c_wr_max = 2; dev->xtal = config->xtal; dev->ts_mode = config->ts_mode; dev->ts_clock = config->ts_clock; With this patch I get data, without it I don't. Based on that info I started testing different i2c wr max values. When I got to 18 it stopped working. So it seams like both you and me where right. We can write several values at once but only a maximum of 16. I have a patch that adds parity check of the firmware and all the times the check succeeded but the demodulator didn't deliver data. So I guess that the parity checker is before the 16 byte buffer and if you write more the data is just ignored. I will send an updated patch based on this. MvH Benjamin Larsson -- 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 3/5] media: ov2640: add primary dt support
Hi Josh,
Thank you for the patch.
On Monday 08 December 2014 19:29:05 Josh Wu wrote:
> Add device tree support for ov2640.
>
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Josh Wu
> ---
> v1 -> v2:
> 1. use gpiod APIs.
> 2. change the gpio pin's name according to datasheet.
> 3. reduce the delay for .reset() function.
>
> drivers/media/i2c/soc_camera/ov2640.c | 86 +---
> 1 file changed, 80 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/i2c/soc_camera/ov2640.c
> b/drivers/media/i2c/soc_camera/ov2640.c index 9ee910d..2a57979 100644
> --- a/drivers/media/i2c/soc_camera/ov2640.c
> +++ b/drivers/media/i2c/soc_camera/ov2640.c
> @@ -18,6 +18,8 @@
> #include
> #include
> #include
> +#include
> +#include
> #include
> #include
>
> @@ -283,6 +285,10 @@ struct ov2640_priv {
> u32 cfmt_code;
> struct v4l2_clk *clk;
> const struct ov2640_win_size*win;
> +
> + struct soc_camera_subdev_desc ssdd_dt;
> + struct gpio_desc *resetb_gpio;
> + struct gpio_desc *pwdn_gpio;
> };
>
> /*
> @@ -1047,6 +1053,61 @@ static struct v4l2_subdev_ops ov2640_subdev_ops = {
> .video = &ov2640_subdev_video_ops,
> };
>
> +/* OF probe functions */
> +static int ov2640_hw_power(struct device *dev, int on)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct ov2640_priv *priv = to_ov2640(client);
> +
> + dev_dbg(&client->dev, "%s: %s the camera\n",
> + __func__, on ? "ENABLE" : "DISABLE");
> +
> + if (priv->pwdn_gpio && !IS_ERR(priv->pwdn_gpio))
No need to test for IS_ERR, as the probe function would have failed in that
case.
> + gpiod_direction_output(priv->pwdn_gpio, !on);
> +
> + return 0;
> +}
> +
> +static int ov2640_hw_reset(struct device *dev)
> +{
> + struct i2c_client *client = to_i2c_client(dev);
> + struct ov2640_priv *priv = to_ov2640(client);
> +
> + /* If enabled, give a reset impulse */
> + if (priv->resetb_gpio && !IS_ERR(priv->resetb_gpio)) {
Same here.
> + gpiod_direction_output(priv->resetb_gpio, 0);
Given that your DT should specify the active low GPIO flag, and that the gpiod
API inverts the value in that case, you should set the value to 1 here.
> + usleep_range(3000, 5000);
> + gpiod_direction_output(priv->resetb_gpio, 1);
And to 0 here.
> + }
> +
> + return 0;
> +}
> +
> +static int ov2640_probe_dt(struct i2c_client *client,
> + struct ov2640_priv *priv)
> +{
> + priv->resetb_gpio = devm_gpiod_get_optional(&client->dev, "resetb",
> + GPIOD_OUT_HIGH);
> + if (!priv->resetb_gpio)
> + dev_warn(&client->dev, "resetb gpio not found!\n");
No need to warn here, it's perfectly fine if the reset signal isn't connected
to a GPIO.
> + else if (IS_ERR(priv->resetb_gpio))
> + return -EINVAL;
> +
> + priv->pwdn_gpio = devm_gpiod_get_optional(&client->dev, "pwdn",
> + GPIOD_OUT_HIGH);
> + if (!priv->pwdn_gpio)
> + dev_warn(&client->dev, "pwdn gpio not found!\n");
Same here.
> + else if (IS_ERR(priv->pwdn_gpio))
> + return -EINVAL;
> +
> + /* Initialize the soc_camera_subdev_desc */
> + priv->ssdd_dt.power = ov2640_hw_power;
> + priv->ssdd_dt.reset = ov2640_hw_reset;
> + client->dev.platform_data = &priv->ssdd_dt;
> +
> + return 0;
> +}
> +
> /*
> * i2c_driver functions
> */
> @@ -1058,12 +1119,6 @@ static int ov2640_probe(struct i2c_client *client,
> struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
> int ret;
>
> - if (!ssdd) {
> - dev_err(&adapter->dev,
> - "OV2640: Missing platform_data for driver\n");
> - return -EINVAL;
> - }
> -
> if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA)) {
> dev_err(&adapter->dev,
> "OV2640: I2C-Adapter doesn't support SMBUS\n");
> @@ -1077,6 +1132,18 @@ static int ov2640_probe(struct i2c_client *client,
> return -ENOMEM;
> }
>
> + if (!ssdd) {
> + if (client->dev.of_node) {
> + ret = ov2640_probe_dt(client, priv);
> + if (ret)
> + return ret;
> + } else {
> + dev_err(&client->dev,
> + "Missing platform_data for driver\n");
> + return -EINVAL;
> + }
I would test for !client->dev.of_node and return the error, you could then get
rid of the else and lower the indentation level for the call to
ov2640_probe_dt().
> + }
> +
> v4l2_i2c_subdev_init(&priv->subdev, client, &ov2640_subdev_ops);
> v4l2_ctrl_handler_init(&priv->hdl, 2);
> v4l2_ctrl_new_std(&priv->hdl, &ov2640_ctrl_ops,
> @@ -1123,9 +1190,16 @@ static
HD Capture Cards on Linux
Hi Guys, In my apparently eternal quest for a decent HD capture card with support for v4l2 I couldn't find an existing table of cards, I've put one up the Wiki. I hope I've done it correctly, these tables are horrible to maintain. Anyhow if people would like to look at it, I'd be grateful for any comments, or indeed you can update the wiki directly. Here is the link: https://linuxtv.org/wiki/index.php/HD_Capture Regards, Steve. -- 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] Si2168: increase timeout to fix firmware loading
On 12/08/2014 10:30 AM, Jurgen Kramer wrote:
Increase si2168 cmd execute timeout to prevent firmware load failures. Tests
shows it takes up to 52ms to load the 'dvb-demod-si2168-a30-01.fw' firmware.
Increase timeout to a safe value of 70ms.
Signed-off-by: Jurgen Kramer
Reviewed-by: Antti Palosaari
Cc: # v3.17+
That must go stable 3.17.
Antti
---
drivers/media/dvb-frontends/si2168.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index ce9ab44..d2f1a3e 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -39,7 +39,7 @@ static int si2168_cmd_execute(struct si2168 *s, struct
si2168_cmd *cmd)
if (cmd->rlen) {
/* wait cmd execution terminate */
- #define TIMEOUT 50
+ #define TIMEOUT 70
timeout = jiffies + msecs_to_jiffies(TIMEOUT);
while (!time_after(jiffies, timeout)) {
ret = i2c_master_recv(s->client, cmd->args, cmd->rlen);
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mn88472: fix firmware loading
Hello! On 12/08/2014 06:04 PM, Benjamin Larsson wrote: On 12/07/2014 11:36 PM, Antti Palosaari wrote: On 12/08/2014 12:10 AM, Benjamin Larsson wrote: The firmware must be loaded one byte at a time via the 0xf6 register. I don't think so. Currently it downloads firmware in 22 byte chunks and it seems to work, at least for me, both mn88472 and mn88473. Ok, I have now tried the driver with my defaults patch in and with your method of loading the firmware and my patch. I have my antenna placed in a bad location with bad reception. With my patch I am getting data from the device, without my patch I am not. So whatever my code does it makes the device more sensitive. And then there is this comment in the regmap code: regmap_bulk_write(): Write multiple registers to the device In this case we want to write multiple bytes to the same register. So I think that my patch is correct in principle. You haven't make any test whether it is possible to write that firmware in a large chunks *or* writing one byte (smallest possible ~chuck) at the time? I think it does not matter. I suspect you could even download whole firmware as one go - but rtl2832p I2C adapter does support only 22 bytes on one xfer. Even those are written to one register, chip knows how many bytes one message has and could increase its internal address counter. That is usually called register address auto-increment. A) writing: f6 00 f6 01 f6 02 f6 03 f6 04 f6 05 f6 06 f6 07 f6 08 f6 09 B) writing: f6 00 01 02 03 04 f6 05 06 07 08 09 will likely end up same. B is better as only 2 xfers are done - much less IO. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] rc: img-ir: add philips rc6 decoder module
On 04/12/14 15:38, Sifan Naeem wrote:
> Add img-ir module for decoding Philips rc6 protocol.
>
> Signed-off-by: Sifan Naeem
Aside from the "Philips" thing:
Acked-by: James Hogan
(It's unpleasant having unexplained timings for RC-6, but it's better
than no RC-6 support, and hopefully in the future it can be improved).
Cheers
James
> ---
> drivers/media/rc/img-ir/Kconfig |8 +++
> drivers/media/rc/img-ir/Makefile |1 +
> drivers/media/rc/img-ir/img-ir-hw.c |3 +
> drivers/media/rc/img-ir/img-ir-hw.h |1 +
> drivers/media/rc/img-ir/img-ir-rc6.c | 117
> ++
> 5 files changed, 130 insertions(+)
> create mode 100644 drivers/media/rc/img-ir/img-ir-rc6.c
>
> diff --git a/drivers/media/rc/img-ir/Kconfig b/drivers/media/rc/img-ir/Kconfig
> index b5b114f..4d3fca9 100644
> --- a/drivers/media/rc/img-ir/Kconfig
> +++ b/drivers/media/rc/img-ir/Kconfig
> @@ -66,3 +66,11 @@ config IR_IMG_RC5
> help
> Say Y here to enable support for the RC5 protocol in the ImgTec
> infrared decoder block.
> +
> +config IR_IMG_RC6
> + bool "Phillips RC6 protocol support"
> + depends on IR_IMG_HW
> + help
> +Say Y here to enable support for the RC6 protocol in the ImgTec
> +infrared decoder block.
> +Note: This version only supports mode 0.
> diff --git a/drivers/media/rc/img-ir/Makefile
> b/drivers/media/rc/img-ir/Makefile
> index 898b1b8..8e6d458 100644
> --- a/drivers/media/rc/img-ir/Makefile
> +++ b/drivers/media/rc/img-ir/Makefile
> @@ -7,6 +7,7 @@ img-ir-$(CONFIG_IR_IMG_SONY) += img-ir-sony.o
> img-ir-$(CONFIG_IR_IMG_SHARP)+= img-ir-sharp.o
> img-ir-$(CONFIG_IR_IMG_SANYO)+= img-ir-sanyo.o
> img-ir-$(CONFIG_IR_IMG_RC5) += img-ir-rc5.o
> +img-ir-$(CONFIG_IR_IMG_RC6) += img-ir-rc6.o
> img-ir-objs := $(img-ir-y)
>
> obj-$(CONFIG_IR_IMG) += img-ir.o
> diff --git a/drivers/media/rc/img-ir/img-ir-hw.c
> b/drivers/media/rc/img-ir/img-ir-hw.c
> index 322cdf8..3b70dc2 100644
> --- a/drivers/media/rc/img-ir/img-ir-hw.c
> +++ b/drivers/media/rc/img-ir/img-ir-hw.c
> @@ -45,6 +45,9 @@ static struct img_ir_decoder *img_ir_decoders[] = {
> #ifdef CONFIG_IR_IMG_RC5
> &img_ir_rc5,
> #endif
> +#ifdef CONFIG_IR_IMG_RC6
> + &img_ir_rc6,
> +#endif
> NULL
> };
>
> diff --git a/drivers/media/rc/img-ir/img-ir-hw.h
> b/drivers/media/rc/img-ir/img-ir-hw.h
> index f124ec5..c7b6e1a 100644
> --- a/drivers/media/rc/img-ir/img-ir-hw.h
> +++ b/drivers/media/rc/img-ir/img-ir-hw.h
> @@ -188,6 +188,7 @@ extern struct img_ir_decoder img_ir_sony;
> extern struct img_ir_decoder img_ir_sharp;
> extern struct img_ir_decoder img_ir_sanyo;
> extern struct img_ir_decoder img_ir_rc5;
> +extern struct img_ir_decoder img_ir_rc6;
>
> /**
> * struct img_ir_reg_timings - Reg values for decoder timings at clock rate.
> diff --git a/drivers/media/rc/img-ir/img-ir-rc6.c
> b/drivers/media/rc/img-ir/img-ir-rc6.c
> new file mode 100644
> index 000..bcd0822
> --- /dev/null
> +++ b/drivers/media/rc/img-ir/img-ir-rc6.c
> @@ -0,0 +1,117 @@
> +/*
> + * ImgTec IR Decoder setup for Phillips RC-6 protocol.
> + *
> + * Copyright 2012-2014 Imagination Technologies Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include "img-ir-hw.h"
> +
> +/* Convert RC6 data to a scancode */
> +static int img_ir_rc6_scancode(int len, u64 raw, u64 enabled_protocols,
> + struct img_ir_scancode_req *request)
> +{
> + unsigned int addr, cmd, mode, trl1, trl2;
> +
> + /*
> + * Due to a side effect of the decoder handling the double length
> + * Trailer bit, the header information is a bit scrambled, and the
> + * raw data is shifted incorrectly.
> + * This workaround effectively recovers the header bits.
> + *
> + * The Header field should look like this:
> + *
> + * StartBit ModeBit2 ModeBit1 ModeBit0 TrailerBit
> + *
> + * But what we get is:
> + *
> + * ModeBit2 ModeBit1 ModeBit0 TrailerBit1 TrailerBit2
> + *
> + * The start bit is not important to recover the scancode.
> + */
> +
> + raw >>= 27;
> +
> + trl1= (raw >> 17) & 0x01;
> + trl2= (raw >> 16) & 0x01;
> +
> + mode= (raw >> 18) & 0x07;
> + addr= (raw >> 8) & 0xff;
> + cmd = raw & 0xff;
> +
> + /*
> + * Due to the above explained irregularity the trailer bits cannot
> + * have the same value.
> + */
> + if (trl1 == trl2)
> + return -EINVAL;
> +
> + /* Only mode 0 supported for now */
> + if (mode)
> + return -EINVAL;
> +
> + request->protocol = RC_TYPE_RC6_0;
> + request-
Re: [PATCH 4/5] rc: img-ir: add philips rc5 decoder module
On 04/12/14 15:38, Sifan Naeem wrote:
> Add img-ir module for decoding Philips rc5 protocol.
>
> Signed-off-by: Sifan Naeem
> ---
> drivers/media/rc/img-ir/Kconfig |7 +++
> drivers/media/rc/img-ir/Makefile |1 +
> drivers/media/rc/img-ir/img-ir-hw.c |3 ++
> drivers/media/rc/img-ir/img-ir-hw.h |1 +
> drivers/media/rc/img-ir/img-ir-rc5.c | 88
> ++
> 5 files changed, 100 insertions(+)
> create mode 100644 drivers/media/rc/img-ir/img-ir-rc5.c
>
> diff --git a/drivers/media/rc/img-ir/Kconfig b/drivers/media/rc/img-ir/Kconfig
> index 03ba9fc..b5b114f 100644
> --- a/drivers/media/rc/img-ir/Kconfig
> +++ b/drivers/media/rc/img-ir/Kconfig
> @@ -59,3 +59,10 @@ config IR_IMG_SANYO
> help
> Say Y here to enable support for the Sanyo protocol (used by Sanyo,
> Aiwa, Chinon remotes) in the ImgTec infrared decoder block.
> +
> +config IR_IMG_RC5
> + bool "Phillips RC5 protocol support"
I think that should be "Philips" (if wikipedia is anything to go by).
Same elsewhere in this patch and patch 5.
Other than that,
Acked-by: James Hogan
(Note, I don't have RC-5/RC-6 capable hardware yet so can't test this
support)
Thanks
James
> + depends on IR_IMG_HW
> + help
> +Say Y here to enable support for the RC5 protocol in the ImgTec
> +infrared decoder block.
> diff --git a/drivers/media/rc/img-ir/Makefile
> b/drivers/media/rc/img-ir/Makefile
> index 92a459d..898b1b8 100644
> --- a/drivers/media/rc/img-ir/Makefile
> +++ b/drivers/media/rc/img-ir/Makefile
> @@ -6,6 +6,7 @@ img-ir-$(CONFIG_IR_IMG_JVC) += img-ir-jvc.o
> img-ir-$(CONFIG_IR_IMG_SONY) += img-ir-sony.o
> img-ir-$(CONFIG_IR_IMG_SHARP)+= img-ir-sharp.o
> img-ir-$(CONFIG_IR_IMG_SANYO)+= img-ir-sanyo.o
> +img-ir-$(CONFIG_IR_IMG_RC5) += img-ir-rc5.o
> img-ir-objs := $(img-ir-y)
>
> obj-$(CONFIG_IR_IMG) += img-ir.o
> diff --git a/drivers/media/rc/img-ir/img-ir-hw.c
> b/drivers/media/rc/img-ir/img-ir-hw.c
> index a977467..322cdf8 100644
> --- a/drivers/media/rc/img-ir/img-ir-hw.c
> +++ b/drivers/media/rc/img-ir/img-ir-hw.c
> @@ -42,6 +42,9 @@ static struct img_ir_decoder *img_ir_decoders[] = {
> #ifdef CONFIG_IR_IMG_SANYO
> &img_ir_sanyo,
> #endif
> +#ifdef CONFIG_IR_IMG_RC5
> + &img_ir_rc5,
> +#endif
> NULL
> };
>
> diff --git a/drivers/media/rc/img-ir/img-ir-hw.h
> b/drivers/media/rc/img-ir/img-ir-hw.h
> index 8578aa7..f124ec5 100644
> --- a/drivers/media/rc/img-ir/img-ir-hw.h
> +++ b/drivers/media/rc/img-ir/img-ir-hw.h
> @@ -187,6 +187,7 @@ extern struct img_ir_decoder img_ir_jvc;
> extern struct img_ir_decoder img_ir_sony;
> extern struct img_ir_decoder img_ir_sharp;
> extern struct img_ir_decoder img_ir_sanyo;
> +extern struct img_ir_decoder img_ir_rc5;
>
> /**
> * struct img_ir_reg_timings - Reg values for decoder timings at clock rate.
> diff --git a/drivers/media/rc/img-ir/img-ir-rc5.c
> b/drivers/media/rc/img-ir/img-ir-rc5.c
> new file mode 100644
> index 000..e1a0829
> --- /dev/null
> +++ b/drivers/media/rc/img-ir/img-ir-rc5.c
> @@ -0,0 +1,88 @@
> +/*
> + * ImgTec IR Decoder setup for Phillips RC-5 protocol.
> + *
> + * Copyright 2012-2014 Imagination Technologies Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by the
> + * Free Software Foundation; either version 2 of the License, or (at your
> + * option) any later version.
> + */
> +
> +#include "img-ir-hw.h"
> +
> +/* Convert RC5 data to a scancode */
> +static int img_ir_rc5_scancode(int len, u64 raw, u64 enabled_protocols,
> + struct img_ir_scancode_req *request)
> +{
> + unsigned int addr, cmd, tgl, start;
> +
> + /* Quirk in the decoder shifts everything by 2 to the left. */
> + raw >>= 2;
> +
> + start = (raw >> 13) & 0x01;
> + tgl = (raw >> 11) & 0x01;
> + addr= (raw >> 6) & 0x1f;
> + cmd = raw & 0x3f;
> + /*
> + * 12th bit is used to extend the command in extended RC5 and has
> + * no effect on standard RC5.
> + */
> + cmd += ((raw >> 12) & 0x01) ? 0 : 0x40;
> +
> + if (!start)
> + return -EINVAL;
> +
> + request->protocol = RC_TYPE_RC5;
> + request->scancode = addr << 8 | cmd;
> + request->toggle = tgl;
> + return IMG_IR_SCANCODE;
> +}
> +
> +/* Convert RC5 scancode to RC5 data filter */
> +static int img_ir_rc5_filter(const struct rc_scancode_filter *in,
> + struct img_ir_filter *out, u64 protocols)
> +{
> + /* Not supported by the hw. */
> + return -EINVAL;
> +}
> +
> +/*
> + * RC-5 decoder
> + * see http://www.sbprojects.com/knowledge/ir/rc5.php
> + */
> +struct img_ir_decoder img_ir_rc5 = {
> + .type = RC_BIT_RC5,
> + .control = {
> + .bitoriend2 = 1,
> +
Re: [PATCH 2/2] mn88472: fix firmware loading
Moikka! On 12/08/2014 01:12 PM, Benjamin Larsson wrote: On 12/07/2014 11:36 PM, Antti Palosaari wrote: On 12/08/2014 12:10 AM, Benjamin Larsson wrote: The firmware must be loaded one byte at a time via the 0xf6 register. I don't think so. Currently it downloads firmware in 22 byte chunks and it seems to work, at least for me, both mn88472 and mn88473. With both these changes I get much better sensitivity. So something is better then before. I will track down the needed changes and respin the patches. I suspect it is that initialization of all registers which has something to do with sensitivity. I haven't tested if firmware uploading is critical, what happens when some byte is skipped or so... Did you saw there is config parameter i2c_wr_max? Setting it to '1' does same what that your patch did, but leaves amount of max I2C bytes configurable... Anyhow, good finding, which needs to be track down. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] rc: img-ir: biphase enabled with workaround
On 04/12/14 15:38, Sifan Naeem wrote:
> Biphase decoding in the current img-ir has got a quirk, where multiple
> Interrupts are generated when an incomplete IR code is received by the
> decoder.
>
> Patch adds a work around for the quirk and enables biphase decoding.
>
> Signed-off-by: Sifan Naeem
> ---
> drivers/media/rc/img-ir/img-ir-hw.c | 56
> +--
> drivers/media/rc/img-ir/img-ir-hw.h |2 ++
> 2 files changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/rc/img-ir/img-ir-hw.c
> b/drivers/media/rc/img-ir/img-ir-hw.c
> index 4a1407b..a977467 100644
> --- a/drivers/media/rc/img-ir/img-ir-hw.c
> +++ b/drivers/media/rc/img-ir/img-ir-hw.c
> @@ -52,6 +52,11 @@ static struct img_ir_decoder *img_ir_decoders[] = {
>
> #define IMG_IR_QUIRK_CODE_BROKEN 0x1 /* Decode is broken */
> #define IMG_IR_QUIRK_CODE_LEN_INCR 0x2 /* Bit length needs increment */
> +/*
> + * The decoder generates rapid interrupts without actually having
> + * received any new data after an incomplete IR code is decoded.
> + */
> +#define IMG_IR_QUIRK_CODE_IRQ0x4
>
> /* functions for preprocessing timings, ensuring max is set */
>
> @@ -547,6 +552,7 @@ static void img_ir_set_decoder(struct img_ir_priv *priv,
>
> /* stop the end timer and switch back to normal mode */
> del_timer_sync(&hw->end_timer);
> + del_timer_sync(&hw->suspend_timer);
FYI, this'll need rebasing due to conflicting with "img-ir/hw: Fix
potential deadlock stopping timer". The new del_timer_sync will need to
be when spin lock isn't held, i.e. still next to the other one, and
don't forget to ensure that suspend_timer doesn't get started if
hw->stopping.
> hw->mode = IMG_IR_M_NORMAL;
>
> /* clear the wakeup scancode filter */
> @@ -843,6 +849,26 @@ static void img_ir_end_timer(unsigned long arg)
> spin_unlock_irq(&priv->lock);
> }
>
> +/*
> + * Timer function to re-enable the current protocol after it had been
> + * cleared when invalid interrupts were generated due to a quirk in the
> + * img-ir decoder.
> + */
> +static void img_ir_suspend_timer(unsigned long arg)
> +{
> + struct img_ir_priv *priv = (struct img_ir_priv *)arg;
> +
You should take the spin lock for most of this function now that
"img-ir/hw: Fix potential deadlock stopping timer" is applied and it is
safe to do so.
> + img_ir_write(priv, IMG_IR_IRQ_CLEAR,
> + IMG_IR_IRQ_ALL & ~IMG_IR_IRQ_EDGE);
> +
> + /* Don't set IRQ if it has changed in a different context. */
Wouldn't hurt to clarify this while you're at it (it confused me for a
moment thinking it was concerned about the enabled raw event IRQs
(IMG_IR_IRQ_EDGE) changing).
Maybe "Don't overwrite enabled valid/match IRQs if they have already
been changed by e.g. a filter change".
Should you even be clearing IRQs in that case? Maybe safer to just treat
that case as a "return immediately without touching anything" sort of
situation.
> + if ((priv->hw.suspend_irqen & IMG_IR_IRQ_EDGE) ==
> + img_ir_read(priv, IMG_IR_IRQ_ENABLE))
> + img_ir_write(priv, IMG_IR_IRQ_ENABLE, priv->hw.suspend_irqen);
> + /* enable */
> + img_ir_write(priv, IMG_IR_CONTROL, priv->hw.reg_timings.ctrl);
> +}
> +
> #ifdef CONFIG_COMMON_CLK
> static void img_ir_change_frequency(struct img_ir_priv *priv,
> struct clk_notifier_data *change)
> @@ -908,15 +934,37 @@ void img_ir_isr_hw(struct img_ir_priv *priv, u32
> irq_status)
> if (!hw->decoder)
> return;
>
> + ct = hw->decoder->control.code_type;
> +
> ir_status = img_ir_read(priv, IMG_IR_STATUS);
> - if (!(ir_status & (IMG_IR_RXDVAL | IMG_IR_RXDVALD2)))
> + if (!(ir_status & (IMG_IR_RXDVAL | IMG_IR_RXDVALD2))) {
> + if (!(priv->hw.ct_quirks[ct] & IMG_IR_QUIRK_CODE_IRQ))
(I suggest adding "|| hw->stopping" to this case)
> + return;
> + /*
> + * The below functionality is added as a work around to stop
> + * multiple Interrupts generated when an incomplete IR code is
> + * received by the decoder.
> + * The decoder generates rapid interrupts without actually
> + * having received any new data. After a single interrupt it's
> + * expected to clear up, but instead multiple interrupts are
> + * rapidly generated. only way to get out of this loop is to
> + * reset the control register after a short delay.
> + */
> + img_ir_write(priv, IMG_IR_CONTROL, 0);
> + hw->suspend_irqen = img_ir_read(priv, IMG_IR_IRQ_ENABLE);
You're reusing hw->suspend_irqen. What if you get this workaround being
activated between img_ir_enable_wake() and img_ir_disable_wake()? I
suggest just using a new img_ir_priv_hw member.
The rest looks reasonable to me, even if unfortunate tha
Re: [PATCH/RFC v8 01/14] leds: Add LED Flash class extension to the LED subsystem
On 12/05/2014 08:27 PM, Bryan Wu wrote:
On Fri, Nov 28, 2014 at 1:17 AM, Jacek Anaszewski
wrote:
Some LED devices support two operation modes - torch and flash.
This patch provides support for flash LED devices in the LED subsystem
by introducing new sysfs attributes and kernel internal interface.
The attributes being introduced are: flash_brightness, flash_strobe,
flash_timeout, max_flash_timeout, max_flash_brightness, flash_fault
and flash_sync_strobe. All the flash related features are placed
in a separate module. Torch mode is supported by the LED class
interface.
The modifications aim to be compatible with V4L2 framework requirements
related to the flash devices management. The design assumes that V4L2
sub-device can take of the LED class device control and communicate
with it through the kernel internal interface. When V4L2 Flash sub-device
file is opened, the LED class device sysfs interface is made
unavailable.
Signed-off-by: Jacek Anaszewski
Acked-by: Kyungmin Park
Cc: Bryan Wu
Cc: Richard Purdie
---
drivers/leds/Kconfig| 10 +
drivers/leds/Makefile |1 +
drivers/leds/led-class-flash.c | 446 +++
drivers/leds/led-class.c|4 +
include/linux/led-class-flash.h | 198 +
include/linux/leds.h|3 +
6 files changed, 662 insertions(+)
create mode 100644 drivers/leds/led-class-flash.c
create mode 100644 include/linux/led-class-flash.h
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index b3c0d8a..fa8021e 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -19,6 +19,16 @@ config LEDS_CLASS
This option enables the led sysfs class in /sys/class/leds. You'll
need this to do anything useful with LEDs. If unsure, say N.
+config LEDS_CLASS_FLASH
+ tristate "LED Flash Class Support"
+ depends on LEDS_CLASS
Looks like it requires V4L2, so probably add depends on V4L2 or similar.
But actually I want to see LED Flash class doesn't depends on V4L2. Is
that possible to do that?
For example a non-V4L2 application want to control the LED as a flash?
It doesn't require V4L2. It only used v4l2-controls.h for error code
macros, but this is also going to be changed.
Other than this main concern, I'm good with this patch now.
-Bryan
+ help
+ This option enables the flash led sysfs class in /sys/class/leds.
+ It wrapps LED Class and adds flash LEDs specific sysfs attributes
+ and kernel internal API to it. You'll need this to provide support
+ for the flash related features of a LED device. It can be built
+ as a module.
+
comment "LED drivers"
config LEDS_88PM860X
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 1c65a19..cbba921 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -2,6 +2,7 @@
# LED Core
obj-$(CONFIG_NEW_LEDS) += led-core.o
obj-$(CONFIG_LEDS_CLASS) += led-class.o
+obj-$(CONFIG_LEDS_CLASS_FLASH) += led-class-flash.o
obj-$(CONFIG_LEDS_TRIGGERS)+= led-triggers.o
# LED Platform Drivers
diff --git a/drivers/leds/led-class-flash.c b/drivers/leds/led-class-flash.c
new file mode 100644
index 000..219b414
--- /dev/null
+++ b/drivers/leds/led-class-flash.c
@@ -0,0 +1,446 @@
+/*
+ * LED Flash class interface
+ *
+ * Copyright (C) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jacek Anaszewski
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "leds.h"
+
+#define has_flash_op(flash, op)\
+ (flash && flash->ops->op)
+
+#define call_flash_op(flash, op, args...) \
+ ((has_flash_op(flash, op)) ?\
+ (flash->ops->op(flash, args)) : \
+ -EINVAL)
+
+static ssize_t flash_brightness_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t size)
+{
+ struct led_classdev *led_cdev = dev_get_drvdata(dev);
+ struct led_classdev_flash *flash = lcdev_to_flash(led_cdev);
+ unsigned long state;
+ ssize_t ret;
+
+ mutex_lock(&led_cdev->led_access);
+
+ if (led_sysfs_is_disabled(led_cdev)) {
+ ret = -EBUSY;
+ goto unlock;
+ }
+
+ ret = kstrtoul(buf, 10, &state);
+ if (ret)
+ goto unlock;
+
+ ret = led_set_flash_brightness(flash, state);
+ if (ret < 0)
+ goto unlock;
+
+ ret = size;
+unlock:
+ mutex_unlock(&led_cdev->led_access);
+ return ret;
+}
+
+static ssize_t flash_brightness_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct led_c
Re: [PATCH/RFC v8 02/14] Documentation: leds: Add description of LED Flash class extension
On 12/06/2014 01:43 PM, Pavel Machek wrote: The format of a sysfs attribute should be concise. The error codes are generic and map directly to the V4L2 Flash error codes. Actually I'd like to see those flash fault code defined in LED subsystem. And V4L2 will just include LED flash header file to use it. Because flash fault code is not for V4L2 specific but it's a feature of LED flash devices. For clearing error code of flash devices, I think it depends on the hardware. If most of our LED flash is using reading to clear error code, we probably can make it simple as this now. But what if some other LED flash devices are using writing to clear error code? we should provide a API to that? Actually, we should provide API that makes sense, and that is easy to use by userspace. I believe "read" is called read because it does not change anything, and it should stay that way in /sysfs. You may want to talk to sysfs maintainers if you plan on doing another semantics. How would you proceed in case of devices which clear their fault register upon I2C readout (e.g. AS3645)? In this case read does have a side effect. For such devices attribute semantics would have to be different than for the devices which don't clear faults on readout. In case of devices which use writing to clear error code - I'd do that after reading flash_fault attribute, in the same callback. Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] rc: img-ir: pass toggle bit to the rc driver
On 04/12/14 15:38, Sifan Naeem wrote:
> Add toggle bit to struct img_ir_scancode_req so that protocols can
> provide it to img_ir_handle_data(), and pass that toggle bit up to
> rc_keydown instead of 0.
>
> This is nedded for the upcoming rc-5 and rc-6 patches.
Typo (nedded).
Otherwise:
Acked-by: James Hogan
Cheers
James
>
> Signed-off-by: Sifan Naeem
> ---
> drivers/media/rc/img-ir/img-ir-hw.c |8 +---
> drivers/media/rc/img-ir/img-ir-hw.h |2 ++
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/rc/img-ir/img-ir-hw.c
> b/drivers/media/rc/img-ir/img-ir-hw.c
> index 61850a6..4a1407b 100644
> --- a/drivers/media/rc/img-ir/img-ir-hw.c
> +++ b/drivers/media/rc/img-ir/img-ir-hw.c
> @@ -792,6 +792,7 @@ static void img_ir_handle_data(struct img_ir_priv *priv,
> u32 len, u64 raw)
> struct img_ir_scancode_req request;
>
> request.protocol = RC_TYPE_UNKNOWN;
> + request.toggle = 0;
>
> if (dec->scancode)
> ret = dec->scancode(len, raw, hw->enabled_protocols, &request);
> @@ -802,9 +803,10 @@ static void img_ir_handle_data(struct img_ir_priv *priv,
> u32 len, u64 raw)
> dev_dbg(priv->dev, "data (%u bits) = %#llx\n",
> len, (unsigned long long)raw);
> if (ret == IMG_IR_SCANCODE) {
> - dev_dbg(priv->dev, "decoded scan code %#x\n",
> - request.scancode);
> - rc_keydown(hw->rdev, request.protocol, request.scancode, 0);
> + dev_dbg(priv->dev, "decoded scan code %#x, toggle %u\n",
> + request.scancode, request.toggle);
> + rc_keydown(hw->rdev, request.protocol, request.scancode,
> +request.toggle);
> img_ir_end_repeat(priv);
> } else if (ret == IMG_IR_REPEATCODE) {
> if (hw->mode == IMG_IR_M_REPEATING) {
> diff --git a/drivers/media/rc/img-ir/img-ir-hw.h
> b/drivers/media/rc/img-ir/img-ir-hw.h
> index 1fc9583..5e59e8e 100644
> --- a/drivers/media/rc/img-ir/img-ir-hw.h
> +++ b/drivers/media/rc/img-ir/img-ir-hw.h
> @@ -138,10 +138,12 @@ struct img_ir_timing_regvals {
> * RC_TYPE_UNKNOWN).
> * @scancode:Scan code of received message (must be written by
> * handler if IMG_IR_SCANCODE is returned).
> + * @toggle: Toggle bit (defaults to 0).
> */
> struct img_ir_scancode_req {
> enum rc_type protocol;
> u32 scancode;
> + u8 toggle;
> };
>
> /**
>
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/5] rc: img-ir: add scancode requests to a struct
On 04/12/14 15:38, Sifan Naeem wrote:
> The information being requested of hardware decode callbacks through
> the img-ir-hw scancode API is mounting up, so combine it into a struct
> which can be passed in with a single pointer rather than multiple
> pointer arguments. This allows it to be extended more easily without
> touching all the hardware decode callbacks.
>
> Signed-off-by: Sifan Naeem
Acked-by: James Hogan
Cheers
James
> ---
> drivers/media/rc/img-ir/img-ir-hw.c| 16 +---
> drivers/media/rc/img-ir/img-ir-hw.h| 16 ++--
> drivers/media/rc/img-ir/img-ir-jvc.c |8
> drivers/media/rc/img-ir/img-ir-nec.c | 24
> drivers/media/rc/img-ir/img-ir-sanyo.c |8
> drivers/media/rc/img-ir/img-ir-sharp.c |8
> drivers/media/rc/img-ir/img-ir-sony.c | 12 ++--
> 7 files changed, 53 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/media/rc/img-ir/img-ir-hw.c
> b/drivers/media/rc/img-ir/img-ir-hw.c
> index ec49f94..61850a6 100644
> --- a/drivers/media/rc/img-ir/img-ir-hw.c
> +++ b/drivers/media/rc/img-ir/img-ir-hw.c
> @@ -789,20 +789,22 @@ static void img_ir_handle_data(struct img_ir_priv
> *priv, u32 len, u64 raw)
> struct img_ir_priv_hw *hw = &priv->hw;
> const struct img_ir_decoder *dec = hw->decoder;
> int ret = IMG_IR_SCANCODE;
> - u32 scancode;
> - enum rc_type protocol = RC_TYPE_UNKNOWN;
> + struct img_ir_scancode_req request;
> +
> + request.protocol = RC_TYPE_UNKNOWN;
>
> if (dec->scancode)
> - ret = dec->scancode(len, raw, &protocol, &scancode,
> hw->enabled_protocols);
> + ret = dec->scancode(len, raw, hw->enabled_protocols, &request);
> else if (len >= 32)
> - scancode = (u32)raw;
> + request.scancode = (u32)raw;
> else if (len < 32)
> - scancode = (u32)raw & ((1 << len)-1);
> + request.scancode = (u32)raw & ((1 << len)-1);
> dev_dbg(priv->dev, "data (%u bits) = %#llx\n",
> len, (unsigned long long)raw);
> if (ret == IMG_IR_SCANCODE) {
> - dev_dbg(priv->dev, "decoded scan code %#x\n", scancode);
> - rc_keydown(hw->rdev, protocol, scancode, 0);
> + dev_dbg(priv->dev, "decoded scan code %#x\n",
> + request.scancode);
> + rc_keydown(hw->rdev, request.protocol, request.scancode, 0);
> img_ir_end_repeat(priv);
> } else if (ret == IMG_IR_REPEATCODE) {
> if (hw->mode == IMG_IR_M_REPEATING) {
> diff --git a/drivers/media/rc/img-ir/img-ir-hw.h
> b/drivers/media/rc/img-ir/img-ir-hw.h
> index 8fcc16c..1fc9583 100644
> --- a/drivers/media/rc/img-ir/img-ir-hw.h
> +++ b/drivers/media/rc/img-ir/img-ir-hw.h
> @@ -133,6 +133,18 @@ struct img_ir_timing_regvals {
> #define IMG_IR_REPEATCODE1 /* repeat the previous code */
>
> /**
> + * struct img_ir_scancode_req - Scancode request data.
> + * @protocol:Protocol code of received message (defaults to
> + * RC_TYPE_UNKNOWN).
> + * @scancode:Scan code of received message (must be written by
> + * handler if IMG_IR_SCANCODE is returned).
> + */
> +struct img_ir_scancode_req {
> + enum rc_type protocol;
> + u32 scancode;
> +};
> +
> +/**
> * struct img_ir_decoder - Decoder settings for an IR protocol.
> * @type:Protocol types bitmap.
> * @tolerance: Timing tolerance as a percentage (default 10%).
> @@ -162,8 +174,8 @@ struct img_ir_decoder {
> struct img_ir_control control;
>
> /* scancode logic */
> - int (*scancode)(int len, u64 raw, enum rc_type *protocol,
> - u32 *scancode, u64 enabled_protocols);
> + int (*scancode)(int len, u64 raw, u64 enabled_protocols,
> + struct img_ir_scancode_req *request);
> int (*filter)(const struct rc_scancode_filter *in,
> struct img_ir_filter *out, u64 protocols);
> };
> diff --git a/drivers/media/rc/img-ir/img-ir-jvc.c
> b/drivers/media/rc/img-ir/img-ir-jvc.c
> index a60dda8..d3e2fc0 100644
> --- a/drivers/media/rc/img-ir/img-ir-jvc.c
> +++ b/drivers/media/rc/img-ir/img-ir-jvc.c
> @@ -12,8 +12,8 @@
> #include "img-ir-hw.h"
>
> /* Convert JVC data to a scancode */
> -static int img_ir_jvc_scancode(int len, u64 raw, enum rc_type *protocol,
> -u32 *scancode, u64 enabled_protocols)
> +static int img_ir_jvc_scancode(int len, u64 raw, u64 enabled_protocols,
> +struct img_ir_scancode_req *request)
> {
> unsigned int cust, data;
>
> @@ -23,8 +23,8 @@ static int img_ir_jvc_scancode(int len, u64 raw, enum
> rc_type *protocol,
> cust = (raw >> 0) & 0xff;
> data = (raw >> 8) & 0xff;
>
> - *protocol = RC_TYPE_JVC;
> - *scancode = cust << 8 | data;
> + request->protocol = RC_TYPE_JVC;
> + request->scancod
[PATCHv2 for v3.19 1/2] cx88: add missing alloc_ctx support
From: Hans Verkuil
The cx88 vb2 conversion and the vb2 dma_sg improvements were developed
separately and
were merged separately. Unfortunately, the patch updating drivers to the dma_sg
improvements didn't take the updated cx88 driver into account. Basically two
ships
passing in the night, unaware of one another even though both ships have the
same
owner, i.e. me :-)
Signed-off-by: Hans Verkuil
Reported-by: Chris Lee
---
drivers/media/pci/cx88/cx88-blackbird.c | 4 +---
drivers/media/pci/cx88/cx88-dvb.c | 4 +---
drivers/media/pci/cx88/cx88-mpeg.c | 11 +++
drivers/media/pci/cx88/cx88-vbi.c | 9 +
drivers/media/pci/cx88/cx88-video.c | 17 +
drivers/media/pci/cx88/cx88.h | 2 ++
6 files changed, 21 insertions(+), 26 deletions(-)
diff --git a/drivers/media/pci/cx88/cx88-blackbird.c
b/drivers/media/pci/cx88/cx88-blackbird.c
index 4160ca4..d3c79d9 100644
--- a/drivers/media/pci/cx88/cx88-blackbird.c
+++ b/drivers/media/pci/cx88/cx88-blackbird.c
@@ -647,6 +647,7 @@ static int queue_setup(struct vb2_queue *q, const struct
v4l2_format *fmt,
dev->ts_packet_size = 188 * 4;
dev->ts_packet_count = 32;
sizes[0] = dev->ts_packet_size * dev->ts_packet_count;
+ alloc_ctxs[0] = dev->alloc_ctx;
return 0;
}
@@ -662,14 +663,11 @@ static void buffer_finish(struct vb2_buffer *vb)
{
struct cx8802_dev *dev = vb->vb2_queue->drv_priv;
struct cx88_buffer *buf = container_of(vb, struct cx88_buffer, vb);
- struct sg_table *sgt = vb2_dma_sg_plane_desc(vb, 0);
struct cx88_riscmem *risc = &buf->risc;
if (risc->cpu)
pci_free_consistent(dev->pci, risc->size, risc->cpu, risc->dma);
memset(risc, 0, sizeof(*risc));
-
- dma_unmap_sg(&dev->pci->dev, sgt->sgl, sgt->nents, DMA_FROM_DEVICE);
}
static void buffer_queue(struct vb2_buffer *vb)
diff --git a/drivers/media/pci/cx88/cx88-dvb.c
b/drivers/media/pci/cx88/cx88-dvb.c
index c344bfd..5780e2f 100644
--- a/drivers/media/pci/cx88/cx88-dvb.c
+++ b/drivers/media/pci/cx88/cx88-dvb.c
@@ -92,6 +92,7 @@ static int queue_setup(struct vb2_queue *q, const struct
v4l2_format *fmt,
dev->ts_packet_size = 188 * 4;
dev->ts_packet_count = dvb_buf_tscnt;
sizes[0] = dev->ts_packet_size * dev->ts_packet_count;
+ alloc_ctxs[0] = dev->alloc_ctx;
*num_buffers = dvb_buf_tscnt;
return 0;
}
@@ -108,14 +109,11 @@ static void buffer_finish(struct vb2_buffer *vb)
{
struct cx8802_dev *dev = vb->vb2_queue->drv_priv;
struct cx88_buffer *buf = container_of(vb, struct cx88_buffer, vb);
- struct sg_table *sgt = vb2_dma_sg_plane_desc(vb, 0);
struct cx88_riscmem *risc = &buf->risc;
if (risc->cpu)
pci_free_consistent(dev->pci, risc->size, risc->cpu, risc->dma);
memset(risc, 0, sizeof(*risc));
-
- dma_unmap_sg(&dev->pci->dev, sgt->sgl, sgt->nents, DMA_FROM_DEVICE);
}
static void buffer_queue(struct vb2_buffer *vb)
diff --git a/drivers/media/pci/cx88/cx88-mpeg.c
b/drivers/media/pci/cx88/cx88-mpeg.c
index f181a3a..1c1f69e 100644
--- a/drivers/media/pci/cx88/cx88-mpeg.c
+++ b/drivers/media/pci/cx88/cx88-mpeg.c
@@ -235,10 +235,6 @@ int cx8802_buf_prepare(struct vb2_queue *q, struct
cx8802_dev *dev,
return -EINVAL;
vb2_set_plane_payload(&buf->vb, 0, size);
- rc = dma_map_sg(&dev->pci->dev, sgt->sgl, sgt->nents, DMA_FROM_DEVICE);
- if (!rc)
- return -EIO;
-
rc = cx88_risc_databuffer(dev->pci, risc, sgt->sgl,
dev->ts_packet_size, dev->ts_packet_count, 0);
if (rc) {
@@ -733,6 +729,11 @@ static int cx8802_probe(struct pci_dev *pci_dev,
if (NULL == dev)
goto fail_core;
dev->pci = pci_dev;
+ dev->alloc_ctx = vb2_dma_sg_init_ctx(&pci_dev->dev);
+ if (IS_ERR(dev->alloc_ctx)) {
+ err = PTR_ERR(dev->alloc_ctx);
+ goto fail_core;
+ }
dev->core = core;
/* Maintain a reference so cx88-video can query the 8802 device. */
@@ -752,6 +753,7 @@ static int cx8802_probe(struct pci_dev *pci_dev,
return 0;
fail_free:
+ vb2_dma_sg_cleanup_ctx(dev->alloc_ctx);
kfree(dev);
fail_core:
core->dvbdev = NULL;
@@ -798,6 +800,7 @@ static void cx8802_remove(struct pci_dev *pci_dev)
/* common */
cx8802_fini_common(dev);
cx88_core_put(dev->core,dev->pci);
+ vb2_dma_sg_cleanup_ctx(dev->alloc_ctx);
kfree(dev);
}
diff --git a/drivers/media/pci/cx88/cx88-vbi.c
b/drivers/media/pci/cx88/cx88-vbi.c
index 6ab6e27..32eb7fd 100644
--- a/drivers/media/pci/cx88/cx88-vbi.c
+++ b/drivers/media/pci/cx88/cx88-vbi.c
@@ -120,6 +120,7 @@ static int queue_setup(struct vb2_queue *q, const struct
v4l2_format *fmt,
sizes[0] = VBI_LINE_NTSC_COUNT * VBI_LINE_LENGTH * 2;
else
[PATCHv2 for v3.19 2/2] cx88: remove leftover start_video_dma() call
From: Hans Verkuil
The start_streaming op is responsible for starting the video dma,
so it shouldn't be called anymore from the buf_queue op.
Unfortunately, this call to start_video_dma() was added to the
start_streaming op, but was forgotten to be removed from the
buf_queue op, which is where it used to be before the vb2 conversion.
Calling this function twice causes very hard to find errors: sometimes
it works, sometimes it doesn't. It took me a whole friggin' day
to track this down, and in the end it was just luck that my eye suddenly
triggered on that line.
Signed-off-by: Hans Verkuil
---
drivers/media/pci/cx88/cx88-video.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/pci/cx88/cx88-video.c
b/drivers/media/pci/cx88/cx88-video.c
index 25a4b7f31..860c98fc 100644
--- a/drivers/media/pci/cx88/cx88-video.c
+++ b/drivers/media/pci/cx88/cx88-video.c
@@ -523,7 +523,6 @@ static void buffer_queue(struct vb2_buffer *vb)
if (list_empty(&q->active)) {
list_add_tail(&buf->list, &q->active);
- start_video_dma(dev, q, buf);
buf->count= q->count++;
dprintk(2,"[%p/%d] buffer_queue - first active\n",
buf, buf->vb.v4l2_buf.index);
--
2.1.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
[PATCHv2 for v3.19 0/2] cx88: fix broken driver
The first patch was due to the dma-sg changes and the cx88 vb2 conversion going in as separate patch series, and the cx88 wasn't patched with the dma-sg changes. The second was a nasty leftover line from the vb2 conversion that took me the whole day to track down. One of those annoying bugs that you *know* must be something obvious, except that you don't see it until suddenly you do... 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
[REVIEW PATCH v2] rc-main: Re-apply filter for no-op protocol change
Since commit da6e162d6a46 ("[media] rc-core: simplify sysfs code"), when
the IR protocol is set using the sysfs interface to the same set of
protocols that are already set, store_protocols() does not refresh the
scancode filter with the new protocol, even if it has already called the
change_protocol() callback successfully. This results in the filter
being disabled in the hardware and not re-enabled until the filter is
set again using sysfs.
Fix in store_protocols() by still re-applying the filter whenever the
change_protocol() driver callback succeeded.
The problem can be reproduced with the img-ir driver by setting a
filter, and then setting the protocol to the same protocol that is
already set:
$ echo nec > protocols
$ echo 0x > filter_mask
$ echo nec > protocols
After this, messages which don't match the filter were still being
received.
Fixes: da6e162d6a46 ("[media] rc-core: simplify sysfs code")
Reported-by: Sifan Naeem
Signed-off-by: James Hogan
Cc: Mauro Carvalho Chehab
Cc: David Härdeman
Cc: # v3.17+
Cc: linux-media@vger.kernel.org
---
Changes in v2:
- Move fix to store_protocols(). Still set filter again even if protocol
mask hasn't been changed as a result of the protocol change (Mauro).
---
drivers/media/rc/rc-main.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 8d3b74c5a717..fc369b033484 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1021,16 +1021,16 @@ static ssize_t store_protocols(struct device *device,
goto out;
}
- if (new_protocols == old_protocols) {
- rc = len;
- goto out;
+ if (new_protocols != old_protocols) {
+ *current_protocols = new_protocols;
+ IR_dprintk(1, "Protocols changed to 0x%llx\n",
+ (long long)new_protocols);
}
- *current_protocols = new_protocols;
- IR_dprintk(1, "Protocols changed to 0x%llx\n", (long
long)new_protocols);
-
/*
-* If the protocol is changed the filter needs updating.
+* If a protocol change was attempted the filter may need updating, even
+* if the actual protocol mask hasn't changed (since the driver may have
+* cleared the filter).
* Try setting the same filter with the new protocol (if any).
* Fall back to clearing the filter.
*/
--
2.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REVIEW PATCH 1/2] img-ir/hw: Avoid clearing filter for no-op protocol change
Hi Mauro,
On 04/12/14 17:38, Mauro Carvalho Chehab wrote:
> Em Mon, 1 Dec 2014 12:55:09 +
> James Hogan escreveu:
>
>> When the img-ir driver is asked to change protocol, if the chosen
>> decoder is already loaded then don't call img_ir_set_decoder(), so as
>> not to clear the current filter.
>>
>> This is important because store_protocol() does not refresh the scancode
>> filter with the new protocol if the set of enabled protocols hasn't
>> actually changed, but it will still call the change_protocol() callback,
>> resulting in the filter being disabled in the hardware.
>>
>> The problem can be reproduced by setting a filter, and then setting the
>> protocol to the same protocol that is already set:
>> $ echo nec > protocols
>> $ echo 0x > filter_mask
>> $ echo nec > protocols
>>
>> After this, messages which don't match the filter still get received.
>
> This should be fixed at the RC core, as this is not driver-specific.
Yes, you're right. I've fixed there and attempted backporting, and the
problem appears to have actually been introduced in commit da6e162d6a46
("[media] rc-core: simplify sysfs code") which went into v3.17.
I'll send a v2.
Thanks
James
>
> Regards,
> Mauro
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 2/2] mn88472: fix firmware loading
On 12/07/2014 11:36 PM, Antti Palosaari wrote: On 12/08/2014 12:10 AM, Benjamin Larsson wrote: The firmware must be loaded one byte at a time via the 0xf6 register. I don't think so. Currently it downloads firmware in 22 byte chunks and it seems to work, at least for me, both mn88472 and mn88473. Ok, I have now tried the driver with my defaults patch in and with your method of loading the firmware and my patch. I have my antenna placed in a bad location with bad reception. With my patch I am getting data from the device, without my patch I am not. So whatever my code does it makes the device more sensitive. And then there is this comment in the regmap code: regmap_bulk_write(): Write multiple registers to the device In this case we want to write multiple bytes to the same register. So I think that my patch is correct in principle. MvH Benjamin Larsson -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] media: ov2640: add a master clock for sensor
On Mon, Dec 8, 2014 at 9:29 AM, Josh Wu wrote: > + priv->master_clk = devm_clk_get(&client->dev, "xvclk"); > + if (IS_ERR(priv->master_clk)) > + return -EINVAL; You should return PTR_ERR(priv->master_clk) instead. -- 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
[sur40] videobuf2 and/or DMA?
Hello everyone, I'm preparing to finally add support for the raw sensor video stream to my driver for the SUR40 touchscreen. However, after an extensive amount of Googling, I'm still not clear on the relationship between DMA transfers, the USB core and the videobuf2 framework. Specifically, I'd like to know: - Can I always use DMA on the USB side (for bulk transfers), or does this in any way require support from the USB device's hardware? (I'm guessing no, but a definite answer would be great.) - Regardless of the USB side of things, can I use the videobuf2 framework without _having_ to use DMA? That way, I could get a basic driver running without DMA and switch later when it's convenient and/or the speedup is justified. Thanks & best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: Kernel 3.17.0 broke xc4000-based DTV1800h
2014-12-01 15:15 GMT+01:00 Devin Heitmueller : > If somebody wants to send me an updated blob, I'm happy to host a copy > at kernellabs.com alongside the file that is currently there (please > make sure it has a different filename though). It would probably be the least confusing to users if the updated firmware was simply named "dvb-fe-xc4000-1.4.2.fw", as it is a fixed/more complete version built from the same Xceive 1.4 source files. -- 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: V4l2 state transition
Le 2014-12-08 09:29, Nicolas Dufresne a écrit : Le 2014-12-08 00:19, Bin Chen a écrit : Can anyone comment is following state transition diagram for V4l2 user space program make sense? Do you see any issues if we were to enforce this constraint? I think you should request some buffers before streamon. If in capture, you should also queue the minimum amount of buffers. I forgot, setting input and format isn't strictly required. Driver should have decent default configured. Nicolas -- 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: V4l2 state transition
Le 2014-12-08 00:19, Bin Chen a écrit : Can anyone comment is following state transition diagram for V4l2 user space program make sense? Do you see any issues if we were to enforce this constraint? I think you should request some buffers before streamon. If in capture, you should also queue the minimum amount of buffers. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] media: platform: add VPFE capture driver support for AM437X
On 12/06/2014 02:07 PM, Lad, Prabhakar wrote:
> From: Benoit Parrot
>
> This patch adds Video Processing Front End (VPFE) driver for
> AM437X family of devices
> Driver supports the following:
> - V4L2 API using MMAP buffer access based on videobuf2 api
> - Asynchronous sensor/decoder sub device registration
> - DT support
>
> Signed-off-by: Benoit Parrot
> Signed-off-by: Darren Etheridge
> Signed-off-by: Lad, Prabhakar
> ---
> Changes for v4:
> 1: Fixed review comments pointed by Hans to check
> ycbcr_enc and quantization while comparing formats,
> fixed the release function and dropped compose cases
> for vpfe_g_selection as compose isn't supported.
>
> .../devicetree/bindings/media/ti-am437x-vpfe.txt | 61 +
> MAINTAINERS|9 +
> drivers/media/platform/Kconfig |1 +
> drivers/media/platform/Makefile|2 +
> drivers/media/platform/am437x/Kconfig | 11 +
> drivers/media/platform/am437x/Makefile |3 +
> drivers/media/platform/am437x/am437x-vpfe.c| 2778
>
> drivers/media/platform/am437x/am437x-vpfe.h| 283 ++
> drivers/media/platform/am437x/am437x-vpfe_regs.h | 140 +
> include/uapi/linux/Kbuild |1 +
> include/uapi/linux/am437x-vpfe.h | 122 +
> 11 files changed, 3411 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/ti-am437x-vpfe.txt
> create mode 100644 drivers/media/platform/am437x/Kconfig
> create mode 100644 drivers/media/platform/am437x/Makefile
> create mode 100644 drivers/media/platform/am437x/am437x-vpfe.c
> create mode 100644 drivers/media/platform/am437x/am437x-vpfe.h
> create mode 100644 drivers/media/platform/am437x/am437x-vpfe_regs.h
> create mode 100644 include/uapi/linux/am437x-vpfe.h
>
> +/*
> + * vpfe_release : This function is based on the vb2_fop_release
> + * helper function.
> + * It has been augmented to handle module power management,
> + * by disabling/enabling h/w module fcntl clock when necessary.
> + */
> +static int vpfe_release(struct file *file)
> +{
> + struct vpfe_device *vpfe = video_drvdata(file);
> + int ret;
> +
> + vpfe_dbg(2, vpfe, "vpfe_release\n");
> +
> + if (!v4l2_fh_is_singular_file(file))
> + return vb2_fop_release(file);
> +
> + mutex_lock(&vpfe->lock);
This should be moved up to before the if. Otherwise there will be a
race between open and release w.r.t. to v4l2_fh_is_singular_file().
> + ret = _vb2_fop_release(file, NULL);
> + vpfe_ccdc_close(&vpfe->ccdc, vpfe->pdev);
> + mutex_unlock(&vpfe->lock);
> +
> + return ret;
> +}
> +
> +/*
> + * vpfe_open : This function is based on the v4l2_fh_open helper function.
> + * It has been augmented to handle module power management,
> + * by disabling/enabling h/w module fcntl clock when necessary.
> + */
> +static int vpfe_open(struct file *file)
> +{
> + struct vpfe_device *vpfe = video_drvdata(file);
> + int ret;
> +
> + ret = v4l2_fh_open(file);
> + if (ret) {
> + vpfe_err(vpfe, "v4l2_fh_open failed\n");
> + return ret;
> + }
> +
> + if (!v4l2_fh_is_singular_file(file))
> + return 0;
> +
> + mutex_lock(&vpfe->lock);
Same here: the lock should move to before the v4l2_fh_open call.
> + if (vpfe_initialize_device(vpfe)) {
> + mutex_unlock(&vpfe->lock);
> + v4l2_fh_release(file);
> + return -ENODEV;
> + }
> + mutex_unlock(&vpfe->lock);
> +
> + return 0;
> +}
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
[GIT PULL] mem2mem patches
The following changes since commit 71947828caef0c83d4245f7d1eaddc799b4ff1d1: [media] mn88473: One function call less in mn88473_init() after error (2014-12-04 16:00:47 -0200) are available in the git repository at: git://linuxtv.org/kdebski/media_tree_2.git for-3.20 for you to fetch changes up to 7760045d005bf16e89488416960223bde86c7a0e: media: s5p-mfc: use vb2_ops_wait_prepare/finish helper (2014-12-08 13:05:29 +0100) Prabhakar Lad (6): media: s3c-camif: use vb2_ops_wait_prepare/finish helper media: ti-vpe: use vb2_ops_wait_prepare/finish helper media: exynos-gsc: use vb2_ops_wait_prepare/finish helper media: sh_veu: use vb2_ops_wait_prepare/finish helper media: s5p-tv: use vb2_ops_wait_prepare/finish helper media: s5p-mfc: use vb2_ops_wait_prepare/finish helper drivers/media/platform/exynos-gsc/gsc-core.h | 12 drivers/media/platform/exynos-gsc/gsc-m2m.c |6 ++-- drivers/media/platform/s3c-camif/camif-capture.c | 17 ++- drivers/media/platform/s5p-mfc/s5p_mfc.c |1 + drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 20 ++--- drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 20 ++--- drivers/media/platform/s5p-tv/mixer_video.c | 21 ++--- drivers/media/platform/sh_veu.c | 35 +- drivers/media/platform/ti-vpe/vpe.c | 19 9 files changed, 27 insertions(+), 124 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TT-connect CT2-4650 CI: DVB-C: no signal, no QAM
Hi Olli, Thanks for feedback. > Are you able to provide me a trace of the USB bus when using Windows? This > is what I have been doing. > > 1) install USBlyzer > 2) start it and select the option Capture hot plugged in the menus > 3) start capture > 4) plug in the device > 5) start watching tv > 6) stop capture after 1 sec to avoid the capture file growing too much I've done that and shared at: https://drive.google.com/open?id=0B94Ll0t460PoSTdKR0xiZlU2S0E&authuser=0 > Would be also good to know if gnutv -cammenu works with the open source Yes, it seems to work (except it coredumps after ctrl-c on fedora), e.g. $ gnutv -channels channels.xine.conf -cammenu "Eurosport HD" CAM Application type: 01 CAM Application manufacturer: 0b00 CAM Manufacturer code: 0001 CAM Menu string: Conax Conditional Access CAM supports the following ca system ids: 0x0b00 -- Conax Conditional Access Main menu 0. Quit menu 1. Subscription status 2. Event status 3. Tokens status 4. Change CA PIN 5. Maturity Rating 6. Ordering online 7. About Conax CA 8. Messages 9. Language 10. Loader status 11. CI Plus Info Press OK to select, or press RETURN > driver. Are all your channels encrypted? Is there any difference between > them? No, some are unencrypted. I cannot tell there are some other differences, windows application 'tt-viewer' does not show details about scanned channels. Also, the multiplex frequencies listed by provider do not seem to match much with what the w_scan initially found. Also, w_scan only scanned at QAM256, tv provider page suggests there are some channels at QAM64 (I havent tried to scan those). But again, it worked (with the TechnoTrend driver) for a short while from linux, even the encryted channels I think. Regards Pavol > > Cheers, > -olli > On 7 Dec 2014 19:41, "Pavol Domin" wrote: > > > Hello, > > > > I recently purchased "TechnoTrend TT-connect CT2-4650 CI" in order to > > watch DVB-C cable TV. I have obtained CAM and smart card from my cable > > TV provider. > > > > Initially, I tried the closed-source driver from the manufacturer; I have > > scanned (w_scan) over hundred of channels and I was able to watch few > > channels (vlc > > or xine) for several minutes. After couple of channels switches however, > > xine started to report 'DVB Signal Lost' for any channel. The w_scan > > founds nothing anymore - tried multiple kernels on different machines, > > during several days, nothing ;) > > > > Manufacturer is not providing linux support and directed me to > > linux_media instead. > > > > The situation with linux_media is not better however (tried recent > > media_build on ubuntu 3.16 and fedora 3.17 kernels) > > > > 1. the device is detected without any problems, no single error reported: > > [ 1957.068871] dvb-usb: found a 'TechnoTrend TT-connect CT2-4650 CI' in > > warm state. > > [ 1957.068999] dvb-usb: will pass the complete MPEG2 transport stream to > > the software demuxer. > > [ 1957.069182] DVB: registering new adapter (TechnoTrend TT-connect > > CT2-4650 CI) > > [ 1957.070518] dvb-usb: MAC address: bc:ea:2b:65:02:3b > > [ 1957.283195] i2c i2c-9: Added multiplexed i2c bus 10 > > [ 1957.283205] si2168 9-0064: Silicon Labs Si2168 successfully attached > > [ 1957.287689] si2157 10-0060: Silicon Labs Si2147/2148/2157/2158 > > successfully attached > > [ 1957.498312] sp2 9-0040: CIMaX SP2 successfully attached > > [ 1957.498348] usb 1-1.3: DVB: registering adapter 0 frontend 0 (Silicon > > Labs Si2168)... > > [ 1957.498835] Registered IR keymap rc-tt-1500 > > [ 1957.499038] input: IR-receiver inside an USB DVB receiver as > > /devices/pci:00/:00:1a.0/usb1/1-1/1-1.3/rc/rc0/input23 > > [ 1957.499408] rc0: IR-receiver inside an USB DVB receiver as > > /devices/pci:00/:00:1a.0/usb1/1-1/1-1.3/rc/rc0 > > [ 1957.499413] dvb-usb: schedule remote query interval to 150 msecs. > > [ 1957.499419] dvb-usb: TechnoTrend TT-connect CT2-4650 CI successfully > > initialized and connected. > > [ 1963.73] dvb_ca adapter 0: DVB CAM detected and initialised > > successfully > > [ 2016.342642] si2168 9-0064: found a 'Silicon Labs Si2168' in cold state > > [ 2016.342910] si2168 9-0064: downloading firmware from file > > 'dvb-demod-si2168-a20-01.fw' > > [ 2017.729882] si2168 9-0064: found a 'Silicon Labs Si2168' in warm state > > [ 2017.739725] si2157 10-0060: found a 'Silicon Labs > > Si2146/2147/2148/2157/2158' in cold state > > [ 2017.739805] si2157 10-0060: downloading firmware from file > > 'dvb-tuner-si2158-a20-01.fw' > > > > 2. yet, the full dvb-c w_scan founds zero channels (after 20+ minutes of > > scanning) > > > > 3. an attempt to tune a channel (czap) using the channel list scanned > > the first time returns: > > $ czap -r -c channels.xine.conf 'Eurosport HD' > > using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' > > reading channels from file 'channels.xine.conf' > > 141 Eurosport > > HD:56200:INVERSION_AUTO:6
[PATCH 5/5] media: ov2640: dt: add the device tree binding document
Add the document for ov2640 dt.
Cc: devicet...@vger.kernel.org
Signed-off-by: Josh Wu
---
v1 -> v2:
1. change the compatible string to be consistent with verdor file.
2. change the clock and pins' name.
3. add missed pinctrl in example.
.../devicetree/bindings/media/i2c/ov2640.txt | 44 ++
1 file changed, 44 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2640.txt
diff --git a/Documentation/devicetree/bindings/media/i2c/ov2640.txt
b/Documentation/devicetree/bindings/media/i2c/ov2640.txt
new file mode 100644
index 000..15be3cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov2640.txt
@@ -0,0 +1,44 @@
+* Omnivision ov2640 CMOS sensor
+
+The Omnivision OV2640 sensor support multiple resolutions output, such as
+CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
+output format.
+
+Required Properties :
+- compatible: Must be "ovti,ov2640"
+- clocks: reference master clock, if using external fixed clock, you
+ no need to have such property.
+- clock-names: Must be "xvclk", it means the master clock for ov2640.
+
+Optional Properties:
+- resetb-gpios: reset pin
+- pwdn-gpios: power down pin
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ i2c1: i2c@f0018000 {
+ ov2640: camera@0x30 {
+ compatible = "ovti,ov2640";
+ reg = <0x30>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck1 &pinctrl_ov2640_pwdn
&pinctrl_ov2640_reset>;
+
+ resetb-gpios = <&pioE 24 GPIO_ACTIVE_HIGH>;
+ pwdn-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
+
+ clocks = <&pck1>;
+ clock-names = "xvclk";
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint = <&isi_0>;
+ bus-width = <8>;
+ };
+ };
+ };
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] media: soc-camera: use icd->control instead of icd->pdev for reset()
icd->control is the sub device dev, i.e. i2c device.
icd->pdev is the soc camera device's device.
To be consitent with power() function, we will call reset() with
icd->control as well.
Signed-off-by: Josh Wu
---
drivers/media/platform/soc_camera/soc_camera.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index f4be2a1..1a3fcb5 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -688,7 +688,7 @@ static int soc_camera_open(struct file *file)
/* The camera could have been already on, try to reset */
if (sdesc->subdev_desc.reset)
- sdesc->subdev_desc.reset(icd->pdev);
+ sdesc->subdev_desc.reset(icd->control);
ret = soc_camera_add_device(icd);
if (ret < 0) {
@@ -1174,8 +1174,10 @@ static void scan_add_host(struct soc_camera_host *ici)
struct soc_camera_subdev_desc *ssdd =
&sdesc->subdev_desc;
/* The camera could have been already on, try to reset
*/
- if (ssdd->reset)
- ssdd->reset(icd->pdev);
+ if (ssdd->reset) {
+ if (icd->control)
+ ssdd->reset(icd->control);
+ }
icd->parent = ici->v4l2_dev.dev;
@@ -1461,7 +1463,7 @@ static int soc_camera_async_bound(struct
v4l2_async_notifier *notifier,
memcpy(&sdesc->subdev_desc, ssdd,
sizeof(sdesc->subdev_desc));
if (ssdd->reset)
- ssdd->reset(icd->pdev);
+ ssdd->reset(&client->dev);
}
icd->control = &client->dev;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] media: ov2640: add a master clock for sensor
The master clock (xvclk) is mandatory. It's a common clock framework clock.
It can make sensor output a pixel clock to the camera interface.
Cc: devicet...@vger.kernel.org
Signed-off-by: Josh Wu
---
v1 -> v2:
1. change the clock's name.
2. Make the clock is mandatory.
drivers/media/i2c/soc_camera/ov2640.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/soc_camera/ov2640.c
b/drivers/media/i2c/soc_camera/ov2640.c
index 2a57979..7cb61e2 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -13,6 +13,7 @@
* published by the Free Software Foundation.
*/
+#include
#include
#include
#include
@@ -31,6 +32,7 @@
#define VAL_SET(x, mask, rshift, lshift) \
x) >> rshift) & mask) << lshift)
+
/*
* DSP registers
* register offset for BANK_SEL == BANK_SEL_DSP
@@ -284,6 +286,7 @@ struct ov2640_priv {
struct v4l2_ctrl_handlerhdl;
u32 cfmt_code;
struct v4l2_clk *clk;
+ struct clk *master_clk;
const struct ov2640_win_size*win;
struct soc_camera_subdev_desc ssdd_dt;
@@ -746,6 +749,7 @@ static int ov2640_s_power(struct v4l2_subdev *sd, int on)
struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
struct ov2640_priv *priv = to_ov2640(client);
struct v4l2_clk *clk;
+ int ret;
if (!priv->clk) {
clk = v4l2_clk_get(&client->dev, "mclk");
@@ -755,7 +759,20 @@ static int ov2640_s_power(struct v4l2_subdev *sd, int on)
priv->clk = clk;
}
- return soc_camera_set_power(&client->dev, ssdd, priv->clk, on);
+ if (on) {
+ ret = clk_prepare_enable(priv->master_clk);
+ if (ret)
+ return ret;
+ } else {
+ clk_disable_unprepare(priv->master_clk);
+ }
+
+ ret = soc_camera_set_power(&client->dev, ssdd, priv->clk, on);
+
+ if (ret && on)
+ clk_disable_unprepare(priv->master_clk);
+
+ return ret;
}
/* Select the nearest higher resolution for capture */
@@ -1144,6 +1161,10 @@ static int ov2640_probe(struct i2c_client *client,
}
}
+ priv->master_clk = devm_clk_get(&client->dev, "xvclk");
+ if (IS_ERR(priv->master_clk))
+ return -EINVAL;
+
v4l2_i2c_subdev_init(&priv->subdev, client, &ov2640_subdev_ops);
v4l2_ctrl_handler_init(&priv->hdl, 2);
v4l2_ctrl_new_std(&priv->hdl, &ov2640_ctrl_ops,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] media: ov2640: add primary dt support
Add device tree support for ov2640.
Cc: devicet...@vger.kernel.org
Signed-off-by: Josh Wu
---
v1 -> v2:
1. use gpiod APIs.
2. change the gpio pin's name according to datasheet.
3. reduce the delay for .reset() function.
drivers/media/i2c/soc_camera/ov2640.c | 86 ---
1 file changed, 80 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/ov2640.c
b/drivers/media/i2c/soc_camera/ov2640.c
index 9ee910d..2a57979 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -18,6 +18,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -283,6 +285,10 @@ struct ov2640_priv {
u32 cfmt_code;
struct v4l2_clk *clk;
const struct ov2640_win_size*win;
+
+ struct soc_camera_subdev_desc ssdd_dt;
+ struct gpio_desc *resetb_gpio;
+ struct gpio_desc *pwdn_gpio;
};
/*
@@ -1047,6 +1053,61 @@ static struct v4l2_subdev_ops ov2640_subdev_ops = {
.video = &ov2640_subdev_video_ops,
};
+/* OF probe functions */
+static int ov2640_hw_power(struct device *dev, int on)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct ov2640_priv *priv = to_ov2640(client);
+
+ dev_dbg(&client->dev, "%s: %s the camera\n",
+ __func__, on ? "ENABLE" : "DISABLE");
+
+ if (priv->pwdn_gpio && !IS_ERR(priv->pwdn_gpio))
+ gpiod_direction_output(priv->pwdn_gpio, !on);
+
+ return 0;
+}
+
+static int ov2640_hw_reset(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct ov2640_priv *priv = to_ov2640(client);
+
+ /* If enabled, give a reset impulse */
+ if (priv->resetb_gpio && !IS_ERR(priv->resetb_gpio)) {
+ gpiod_direction_output(priv->resetb_gpio, 0);
+ usleep_range(3000, 5000);
+ gpiod_direction_output(priv->resetb_gpio, 1);
+ }
+
+ return 0;
+}
+
+static int ov2640_probe_dt(struct i2c_client *client,
+ struct ov2640_priv *priv)
+{
+ priv->resetb_gpio = devm_gpiod_get_optional(&client->dev, "resetb",
+ GPIOD_OUT_HIGH);
+ if (!priv->resetb_gpio)
+ dev_warn(&client->dev, "resetb gpio not found!\n");
+ else if (IS_ERR(priv->resetb_gpio))
+ return -EINVAL;
+
+ priv->pwdn_gpio = devm_gpiod_get_optional(&client->dev, "pwdn",
+ GPIOD_OUT_HIGH);
+ if (!priv->pwdn_gpio)
+ dev_warn(&client->dev, "pwdn gpio not found!\n");
+ else if (IS_ERR(priv->pwdn_gpio))
+ return -EINVAL;
+
+ /* Initialize the soc_camera_subdev_desc */
+ priv->ssdd_dt.power = ov2640_hw_power;
+ priv->ssdd_dt.reset = ov2640_hw_reset;
+ client->dev.platform_data = &priv->ssdd_dt;
+
+ return 0;
+}
+
/*
* i2c_driver functions
*/
@@ -1058,12 +1119,6 @@ static int ov2640_probe(struct i2c_client *client,
struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
int ret;
- if (!ssdd) {
- dev_err(&adapter->dev,
- "OV2640: Missing platform_data for driver\n");
- return -EINVAL;
- }
-
if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA)) {
dev_err(&adapter->dev,
"OV2640: I2C-Adapter doesn't support SMBUS\n");
@@ -1077,6 +1132,18 @@ static int ov2640_probe(struct i2c_client *client,
return -ENOMEM;
}
+ if (!ssdd) {
+ if (client->dev.of_node) {
+ ret = ov2640_probe_dt(client, priv);
+ if (ret)
+ return ret;
+ } else {
+ dev_err(&client->dev,
+ "Missing platform_data for driver\n");
+ return -EINVAL;
+ }
+ }
+
v4l2_i2c_subdev_init(&priv->subdev, client, &ov2640_subdev_ops);
v4l2_ctrl_handler_init(&priv->hdl, 2);
v4l2_ctrl_new_std(&priv->hdl, &ov2640_ctrl_ops,
@@ -1123,9 +1190,16 @@ static const struct i2c_device_id ov2640_id[] = {
};
MODULE_DEVICE_TABLE(i2c, ov2640_id);
+static const struct of_device_id ov2640_of_match[] = {
+ {.compatible = "ovti,ov2640", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, ov2640_of_match);
+
static struct i2c_driver ov2640_i2c_driver = {
.driver = {
.name = "ov2640",
+ .of_match_table = of_match_ptr(ov2640_of_match),
},
.probe= ov2640_probe,
.remove = ov2640_remove,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] media: ov2640: add device tree support
This patch series add device tree support for ov2640. And also add the document for the devicetree properties. v1 -> v2: 1. modified the dt bindings according to Laurent's suggestion. 2. add a fix patch for soc_camera. Otherwise the .reset() function won't work. Josh Wu (5): media: soc-camera: use icd->control instead of icd->pdev for reset() media: ov2640: add async probe function media: ov2640: add primary dt support media: ov2640: add a master clock for sensor media: ov2640: dt: add the device tree binding document .../devicetree/bindings/media/i2c/ov2640.txt | 44 +++ drivers/media/i2c/soc_camera/ov2640.c | 140 ++--- drivers/media/platform/soc_camera/soc_camera.c | 10 +- 3 files changed, 173 insertions(+), 21 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2640.txt -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] media: ov2640: add async probe function
To support async probe for ov2640, we need remove the code to get 'mclk'
in ov2640_probe() function. oterwise, if soc_camera host is not probed
in the moment, then we will fail to get 'mclk' and quit the ov2640_probe()
function.
So in this patch, we move such 'mclk' getting code to ov2640_s_power()
function. That make ov2640 survive, as we can pass a NULL (priv-clk) to
soc_camera_set_power() function.
And if soc_camera host is probed, the when ov2640_s_power() is called,
then we can get the 'mclk' and that make us enable/disable soc_camera
host's clock as well.
Signed-off-by: Josh Wu
---
v1 -> v2:
no changes.
drivers/media/i2c/soc_camera/ov2640.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/media/i2c/soc_camera/ov2640.c
b/drivers/media/i2c/soc_camera/ov2640.c
index 1fdce2f..9ee910d 100644
--- a/drivers/media/i2c/soc_camera/ov2640.c
+++ b/drivers/media/i2c/soc_camera/ov2640.c
@@ -739,6 +739,15 @@ static int ov2640_s_power(struct v4l2_subdev *sd, int on)
struct i2c_client *client = v4l2_get_subdevdata(sd);
struct soc_camera_subdev_desc *ssdd = soc_camera_i2c_to_desc(client);
struct ov2640_priv *priv = to_ov2640(client);
+ struct v4l2_clk *clk;
+
+ if (!priv->clk) {
+ clk = v4l2_clk_get(&client->dev, "mclk");
+ if (IS_ERR(clk))
+ dev_warn(&client->dev, "Cannot get the mclk. maybe
soc-camera host is not probed yet.\n");
+ else
+ priv->clk = clk;
+ }
return soc_camera_set_power(&client->dev, ssdd, priv->clk, on);
}
@@ -1078,21 +1087,21 @@ static int ov2640_probe(struct i2c_client *client,
if (priv->hdl.error)
return priv->hdl.error;
- priv->clk = v4l2_clk_get(&client->dev, "mclk");
- if (IS_ERR(priv->clk)) {
- ret = PTR_ERR(priv->clk);
- goto eclkget;
- }
-
ret = ov2640_video_probe(client);
if (ret) {
- v4l2_clk_put(priv->clk);
-eclkget:
- v4l2_ctrl_handler_free(&priv->hdl);
+ goto evideoprobe;
} else {
dev_info(&adapter->dev, "OV2640 Probed\n");
}
+ ret = v4l2_async_register_subdev(&priv->subdev);
+ if (ret < 0)
+ goto evideoprobe;
+
+ return 0;
+
+evideoprobe:
+ v4l2_ctrl_handler_free(&priv->hdl);
return ret;
}
@@ -1100,7 +1109,9 @@ static int ov2640_remove(struct i2c_client *client)
{
struct ov2640_priv *priv = to_ov2640(client);
- v4l2_clk_put(priv->clk);
+ v4l2_async_unregister_subdev(&priv->subdev);
+ if (priv->clk)
+ v4l2_clk_put(priv->clk);
v4l2_device_unregister_subdev(&priv->subdev);
v4l2_ctrl_handler_free(&priv->hdl);
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mn88472: fix firmware loading
On 12/07/2014 11:36 PM, Antti Palosaari wrote: On 12/08/2014 12:10 AM, Benjamin Larsson wrote: The firmware must be loaded one byte at a time via the 0xf6 register. I don't think so. Currently it downloads firmware in 22 byte chunks and it seems to work, at least for me, both mn88472 and mn88473. With both these changes I get much better sensitivity. So something is better then before. I will track down the needed changes and respin the patches. MvH Benjamin Larsson -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/11] media: s3c-camif: use vb2_ops_wait_prepare/finish helper
On 26/11/14 23:42, Lad, Prabhakar wrote: > This patch drops driver specific wait_prepare() and > wait_finish() callbacks from vb2_ops and instead uses > the the helpers vb2_ops_wait_prepare/finish() provided > by the vb2 core, the lock member of the queue needs > to be initalized to a mutex so that vb2 helpers > vb2_ops_wait_prepare/finish() can make use of it. > > Signed-off-by: Lad, Prabhakar > Cc: Sylwester Nawrocki Acked-by: Sylwester Nawrocki -- Thanks, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v9 06/19] DT: Add documentation for the mfd Maxim max77693
Hi Pavel, On 12/04/2014 05:12 PM, Pavel Machek wrote: Hi! +- maxim,boost-mode : + In boost mode the device can produce up to 1.2A of total current + on both outputs. The maximum current on each output is reduced + to 625mA then. If there are two child led nodes defined then boost + is enabled by default. + Possible values: + MAX77693_LED_BOOST_OFF - no boost, + MAX77693_LED_BOOST_ADAPTIVE - adaptive mode, + MAX77693_LED_BOOST_FIXED - fixed mode. +- maxim,boost-vout : Output voltage of the boost module in millivolts. +- maxim,vsys-min : Low input voltage level in millivolts. Flash is not fired + if chip estimates that system voltage could drop below this level due + to flash power consumption. + +Required properties of the LED child node: +- label : see Documentation/devicetree/bindings/leds/common.txt +- maxim,fled_id : Identifier of the fled output the led is connected to; I'm pretty sure this will be needed for about every chip that can drive multiple LEDs. Shouldn't it be documented in the generic documentation? OK. Well... "fled_id" is not exactly suitable name. On other busses, it would be "reg = <1>"? I'm ok with "reg". This scheme is used for pca963x.txt and is described as "number of LED line". We could define it similarly in the common.txt. A device would have to specify the range of allowed values though. I would add such a note to the generic binding. Regards, Jacek -- 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 for 3.19] cx88: add missing alloc_ctx support
On 12/08/2014 09:28 AM, Hans Verkuil wrote: > The cx88 vb2 conversion and the vb2 dma_sg improvements were developed > separately and > were merged separately. Unfortunately, the patch updating drivers to the > dma_sg > improvements didn't take the updated cx88 driver into account. Basically two > ships > passing in the night, unaware of one another even though both ships have the > same > owner, i.e. me :-) Ignore this. Besides the fact that the patch in not complete (I missed a dma_map_sg occurrence), is isn't working even with that fix in. I'm missing something. Still debugging... Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: hcd: get/put device and hcd for hcd_buffers()
From: Greg Kroah-Hartman
> On Fri, Dec 05, 2014 at 09:03:57PM +0100, Sebastian Andrzej Siewior wrote:
> > Consider the following scenario:
> > - plugin a webcam
> > - play the stream via gst-launch-0.10 v4l2src device=/dev/video0
> > - remove the USB-HCD during playback via "rmmod $HCD"
> >
> > and now wait for the crash
>
> Which you deserve, why did you ever remove a kernel module? That's racy
> and _never_ recommended, which is why it never happens automatically and
> only root can do it.
Really drivers and subsystems should have the required locking (etc) to
ensure that kernel modules can either be unloaded, or that the unload
request itself fails if the device is busy.
It shouldn't be considered a 'shoot self in foot' operation.
OTOH there are likely to be bugs.
David
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
Re: [PATCH] usb: hcd: get/put device and hcd for hcd_buffers()
* Sebastian Andrzej Siewior | 2014-12-06 00:23:27 [+0100]: >I had one patch doing that. Let me grab it out on Monday. okay, this is it. Laurent, any idea why this could not fly? I haven't seen anything odd so far. diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c index 7c8322d4fc63..d656c7de25ef 100644 --- a/drivers/media/usb/uvc/uvc_driver.c +++ b/drivers/media/usb/uvc/uvc_driver.c @@ -1703,6 +1703,7 @@ static void uvc_unregister_video(struct uvc_device *dev) stream->vdev = NULL; uvc_debugfs_cleanup_stream(stream); + uvc_video_enable(stream, 0); } /* Decrement the stream count and call uvc_delete explicitly if there @@ -1950,10 +1951,6 @@ static void uvc_disconnect(struct usb_interface *intf) */ usb_set_intfdata(intf, NULL); - if (intf->cur_altsetting->desc.bInterfaceSubClass == - UVC_SC_VIDEOSTREAMING) - return; - dev->state |= UVC_DEV_DISCONNECTED; uvc_unregister_video(dev); -- 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] Si2168: increase timeout to fix firmware loading
Increase si2168 cmd execute timeout to prevent firmware load failures. Tests
shows it takes up to 52ms to load the 'dvb-demod-si2168-a30-01.fw' firmware.
Increase timeout to a safe value of 70ms.
Signed-off-by: Jurgen Kramer
---
drivers/media/dvb-frontends/si2168.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index ce9ab44..d2f1a3e 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -39,7 +39,7 @@ static int si2168_cmd_execute(struct si2168 *s, struct
si2168_cmd *cmd)
if (cmd->rlen) {
/* wait cmd execution terminate */
- #define TIMEOUT 50
+ #define TIMEOUT 70
timeout = jiffies + msecs_to_jiffies(TIMEOUT);
while (!time_after(jiffies, timeout)) {
ret = i2c_master_recv(s->client, cmd->args, cmd->rlen);
--
1.9.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 for 3.19] cx88: add missing alloc_ctx support
The cx88 vb2 conversion and the vb2 dma_sg improvements were developed
separately and
were merged separately. Unfortunately, the patch updating drivers to the dma_sg
improvements didn't take the updated cx88 driver into account. Basically two
ships
passing in the night, unaware of one another even though both ships have the
same
owner, i.e. me :-)
Signed-off-by: Hans Verkuil
Reported-by: Chris Lee
--
diff --git a/drivers/media/pci/cx88/cx88-blackbird.c
b/drivers/media/pci/cx88/cx88-blackbird.c
index 4160ca4..d3c79d9 100644
--- a/drivers/media/pci/cx88/cx88-blackbird.c
+++ b/drivers/media/pci/cx88/cx88-blackbird.c
@@ -647,6 +647,7 @@ static int queue_setup(struct vb2_queue *q, const struct
v4l2_format *fmt,
dev->ts_packet_size = 188 * 4;
dev->ts_packet_count = 32;
sizes[0] = dev->ts_packet_size * dev->ts_packet_count;
+ alloc_ctxs[0] = dev->alloc_ctx;
return 0;
}
@@ -662,14 +663,11 @@ static void buffer_finish(struct vb2_buffer *vb)
{
struct cx8802_dev *dev = vb->vb2_queue->drv_priv;
struct cx88_buffer *buf = container_of(vb, struct cx88_buffer, vb);
- struct sg_table *sgt = vb2_dma_sg_plane_desc(vb, 0);
struct cx88_riscmem *risc = &buf->risc;
if (risc->cpu)
pci_free_consistent(dev->pci, risc->size, risc->cpu, risc->dma);
memset(risc, 0, sizeof(*risc));
-
- dma_unmap_sg(&dev->pci->dev, sgt->sgl, sgt->nents, DMA_FROM_DEVICE);
}
static void buffer_queue(struct vb2_buffer *vb)
diff --git a/drivers/media/pci/cx88/cx88-dvb.c
b/drivers/media/pci/cx88/cx88-dvb.c
index c344bfd..5780e2f 100644
--- a/drivers/media/pci/cx88/cx88-dvb.c
+++ b/drivers/media/pci/cx88/cx88-dvb.c
@@ -92,6 +92,7 @@ static int queue_setup(struct vb2_queue *q, const struct
v4l2_format *fmt,
dev->ts_packet_size = 188 * 4;
dev->ts_packet_count = dvb_buf_tscnt;
sizes[0] = dev->ts_packet_size * dev->ts_packet_count;
+ alloc_ctxs[0] = dev->alloc_ctx;
*num_buffers = dvb_buf_tscnt;
return 0;
}
@@ -108,14 +109,11 @@ static void buffer_finish(struct vb2_buffer *vb)
{
struct cx8802_dev *dev = vb->vb2_queue->drv_priv;
struct cx88_buffer *buf = container_of(vb, struct cx88_buffer, vb);
- struct sg_table *sgt = vb2_dma_sg_plane_desc(vb, 0);
struct cx88_riscmem *risc = &buf->risc;
if (risc->cpu)
pci_free_consistent(dev->pci, risc->size, risc->cpu, risc->dma);
memset(risc, 0, sizeof(*risc));
-
- dma_unmap_sg(&dev->pci->dev, sgt->sgl, sgt->nents, DMA_FROM_DEVICE);
}
static void buffer_queue(struct vb2_buffer *vb)
diff --git a/drivers/media/pci/cx88/cx88-mpeg.c
b/drivers/media/pci/cx88/cx88-mpeg.c
index f181a3a..1c1f69e 100644
--- a/drivers/media/pci/cx88/cx88-mpeg.c
+++ b/drivers/media/pci/cx88/cx88-mpeg.c
@@ -235,10 +235,6 @@ int cx8802_buf_prepare(struct vb2_queue *q, struct
cx8802_dev *dev,
return -EINVAL;
vb2_set_plane_payload(&buf->vb, 0, size);
- rc = dma_map_sg(&dev->pci->dev, sgt->sgl, sgt->nents, DMA_FROM_DEVICE);
- if (!rc)
- return -EIO;
-
rc = cx88_risc_databuffer(dev->pci, risc, sgt->sgl,
dev->ts_packet_size, dev->ts_packet_count, 0);
if (rc) {
@@ -733,6 +729,11 @@ static int cx8802_probe(struct pci_dev *pci_dev,
if (NULL == dev)
goto fail_core;
dev->pci = pci_dev;
+ dev->alloc_ctx = vb2_dma_sg_init_ctx(&pci_dev->dev);
+ if (IS_ERR(dev->alloc_ctx)) {
+ err = PTR_ERR(dev->alloc_ctx);
+ goto fail_core;
+ }
dev->core = core;
/* Maintain a reference so cx88-video can query the 8802 device. */
@@ -752,6 +753,7 @@ static int cx8802_probe(struct pci_dev *pci_dev,
return 0;
fail_free:
+ vb2_dma_sg_cleanup_ctx(dev->alloc_ctx);
kfree(dev);
fail_core:
core->dvbdev = NULL;
@@ -798,6 +800,7 @@ static void cx8802_remove(struct pci_dev *pci_dev)
/* common */
cx8802_fini_common(dev);
cx88_core_put(dev->core,dev->pci);
+ vb2_dma_sg_cleanup_ctx(dev->alloc_ctx);
kfree(dev);
}
diff --git a/drivers/media/pci/cx88/cx88-vbi.c
b/drivers/media/pci/cx88/cx88-vbi.c
index 6ab6e27..32eb7fd 100644
--- a/drivers/media/pci/cx88/cx88-vbi.c
+++ b/drivers/media/pci/cx88/cx88-vbi.c
@@ -120,6 +120,7 @@ static int queue_setup(struct vb2_queue *q, const struct
v4l2_format *fmt,
sizes[0] = VBI_LINE_NTSC_COUNT * VBI_LINE_LENGTH * 2;
else
sizes[0] = VBI_LINE_PAL_COUNT * VBI_LINE_LENGTH * 2;
+ alloc_ctxs[0] = dev->alloc_ctx;
return 0;
}
@@ -131,7 +132,6 @@ static int buffer_prepare(struct vb2_buffer *vb)
struct sg_table *sgt = vb2_dma_sg_plane_desc(vb, 0);
unsigned int lines;
unsigned int size;
- int rc;
if (dev->core->tvnorm & V4L2_STD_525_60)
lines = VBI_LINE_
Re: DVBSky T980C: Si2168 fw load failed
On 12/08/2014 10:12 AM, Jurgen Kramer wrote: On Mon, 2014-12-08 at 09:50 +0200, Antti Palosaari wrote: On 12/08/2014 09:39 AM, Jurgen Kramer wrote: On Sun, 2014-12-07 at 16:50 +0200, Antti Palosaari wrote: On 12/07/2014 10:15 AM, Jurgen Kramer wrote: On Sat, 2014-12-06 at 20:29 +0200, Antti Palosaari wrote: On 12/06/2014 06:48 PM, Jurgen Kramer wrote: On my new DVBSky T980C the tuner firmware failes to load: [ 51.326525] si2168 2-0064: found a 'Silicon Labs Si2168' in cold state [ 51.356233] si2168 2-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 51.408166] si2168 2-0064: firmware download failed=-110 [ 51.415457] si2157 4-0060: found a 'Silicon Labs Si2146/2147/2148/2157/2158' in cold state [ 51.521714] si2157 4-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' [ 52.330605] si2168 2-0064: found a 'Silicon Labs Si2168' in cold state [ 52.330784] si2168 2-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 52.382145] si2168 2-0064: firmware download failed=-110 110 seems to mean connection timeout. Any pointers how to debug this further? This is with the latest media_build from linuxtv.org on 3.17.4. Looks like si2168 firmware failed to download, but si2157 succeeded. Could you add some more time for driver timeout? Current timeout is selected by trial and error, lets say it takes always max 43ms for my device I coded it 50ms. drivers/media/dvb-frontends/si2168.c /* wait cmd execution terminate */ #define TIMEOUT 50 change it to #define TIMEOUT 500 Thanks, with the larger timeout the fw load works: [ 56.960982] si2168 4-0064: found a 'Silicon Labs Si2168' in cold state [ 56.972650] si2168 4-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 60.103509] si2168 4-0064: found a 'Silicon Labs Si2168' in warm state [ 60.110739] si2157 6-0060: found a 'Silicon Labs Si2146/2147/2148/2157/2158' in cold state [ 60.123720] si2157 6-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' Have to find out some suitable value. For that I need know how long it took maximum in your case. There is already dubug printing to print execution time of each command, but it is behind dynamic debug. Maybe the most easiest way is change that debug line to info: drivers/media/dvb-frontends/si2168.c - dev_dbg(&s->client->dev, "cmd execution took %d ms\n", + dev_info(&s->client->dev, "cmd execution took %d ms\n", and then compile and install and issue command: This gives the following results: [ 50.152281] si2168 4-0064: cmd execution took 0 ms [ 50.154007] si2168 4-0064: cmd execution took 1 ms [ 50.154010] si2168 4-0064: found a 'Silicon Labs Si2168' in cold state [ 50.181157] si2168 4-0064: downloading firmware from file 'dvb-demod-si2168-a30-01.fw' [ 50.233374] si2168 4-0064: cmd execution took 52 ms [ 53.300879] si2168 4-0064: cmd execution took 0 ms [ 53.300880] si2168 4-0064: found a 'Silicon Labs Si2168' in warm state [ 53.308282] si2157 6-0060: found a 'Silicon Labs Si2146/2147/2148/2157/2158' in cold state [ 53.321085] si2157 6-0060: downloading firmware from file 'dvb-tuner-si2158-a20-01.fw' [ 54.152370] si2168 4-0064: cmd execution took 1 ms So the initial timeout of 50ms is just missed. New value 60ms? or 75 to be really safe. 70ms sounds nice for my me. Wanna make a patch? Or if it sounds too hard I could make it. No problem creating a patch (against git://linuxtv.org/media_tree.git ?). Thats OK Antti Regards, Jurgen -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/9] clk: sunxi: Add prcm mod0 clock driver
Hi, On 07-12-14 19:08, Maxime Ripard wrote: On Wed, Dec 03, 2014 at 10:49:20AM +0100, Hans de Goede wrote: So it should not have a simple-bus compatible either, and as such we cannot simply change the mod0 driver from of_clk_define to a platform driver because then we need to instantiate platform devs for the mod0 clock nodes, which means making the clock node a simple-bus. I guess we can do that as a temporary measure until we get things right on that front. I'm totally open to doing that work, so I'm not asking you to do it. I can see your logic in wanting the ir_clk prcm sub-node to use the mod0 compatible string, so how about we make the mod0 driver both register through of_declare and as a platform driver. Note this means that it will try to bind twice to the ir_clk node, since of_clk_declare will cause it to try and bind there too AFAIK. Hmmm, I could live with that for a while too. That shouldn't even require too much work, since the first thing we check in the mod0 code is that we actually have something in reg, which will not be the case in the OF_CLK_DECLARE case. The of_clk_declare bind will fail though because there is no regs property, so this double bind is not an issue as long as we do not log errors on the first bind failure. Yep, exactly. Note that the ir_clk node will still need an "ir-clk" compatible as well for the MFD to find it and assign the proper resources to it. No, it really doesn't. At least for now, we have a single mod0 clock under the PRCM MFD. If (and only if) one day, we find ourselves in a position where we have two mod0 clocks under the PRCM, then we'll fix the MFD code to deal with that, because it really should deal with it. Ok, using only the mod0 compat string works for me. I'll respin my patch-set (minus the one patch you've already merged) to make the modo clk driver use both of_clk_declare and make it a platfrom driver, and use the mod0 compat string for the ir-clk node. Not sure when I'll get this done exactly though, but we still have a while before 3.20 :) 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: DVBSky T980C: Si2168 fw load failed
On Mon, 2014-12-08 at 09:50 +0200, Antti Palosaari wrote: > > On 12/08/2014 09:39 AM, Jurgen Kramer wrote: > > On Sun, 2014-12-07 at 16:50 +0200, Antti Palosaari wrote: > >> > >> On 12/07/2014 10:15 AM, Jurgen Kramer wrote: > >>> On Sat, 2014-12-06 at 20:29 +0200, Antti Palosaari wrote: > On 12/06/2014 06:48 PM, Jurgen Kramer wrote: > > On my new DVBSky T980C the tuner firmware failes to load: > > [ 51.326525] si2168 2-0064: found a 'Silicon Labs Si2168' in cold > > state > > [ 51.356233] si2168 2-0064: downloading firmware from file > > 'dvb-demod-si2168-a30-01.fw' > > [ 51.408166] si2168 2-0064: firmware download failed=-110 > > [ 51.415457] si2157 4-0060: found a 'Silicon Labs > > Si2146/2147/2148/2157/2158' > > in cold state > > [ 51.521714] si2157 4-0060: downloading firmware from file > > 'dvb-tuner-si2158-a20-01.fw' > > [ 52.330605] si2168 2-0064: found a 'Silicon Labs Si2168' in cold > > state > > [ 52.330784] si2168 2-0064: downloading firmware from file > > 'dvb-demod-si2168-a30-01.fw' > > [ 52.382145] si2168 2-0064: firmware download failed=-110 > > > > 110 seems to mean connection timeout. Any pointers how to debug this > > further? > > > > This is with the latest media_build from linuxtv.org on 3.17.4. > > Looks like si2168 firmware failed to download, but si2157 succeeded. > Could you add some more time for driver timeout? Current timeout is > selected by trial and error, lets say it takes always max 43ms for my > device I coded it 50ms. > > > drivers/media/dvb-frontends/si2168.c > /* wait cmd execution terminate */ > #define TIMEOUT 50 > > change it to > #define TIMEOUT 500 > >>> > >>> Thanks, with the larger timeout the fw load works: > >>> > >>> [ 56.960982] si2168 4-0064: found a 'Silicon Labs Si2168' in cold > >>> state > >>> [ 56.972650] si2168 4-0064: downloading firmware from file > >>> 'dvb-demod-si2168-a30-01.fw' > >>> [ 60.103509] si2168 4-0064: found a 'Silicon Labs Si2168' in warm > >>> state > >>> [ 60.110739] si2157 6-0060: found a 'Silicon Labs > >>> Si2146/2147/2148/2157/2158' in cold state > >>> [ 60.123720] si2157 6-0060: downloading firmware from file > >>> 'dvb-tuner-si2158-a20-01.fw' > >> > >> Have to find out some suitable value. For that I need know how long it > >> took maximum in your case. There is already dubug printing to print > >> execution time of each command, but it is behind dynamic debug. Maybe > >> the most easiest way is change that debug line to info: > >> drivers/media/dvb-frontends/si2168.c > >> - dev_dbg(&s->client->dev, "cmd execution took %d ms\n", > >> + dev_info(&s->client->dev, "cmd execution took %d ms\n", > >> > >> and then compile and install and issue command: > > > > This gives the following results: > > [ 50.152281] si2168 4-0064: cmd execution took 0 ms > > [ 50.154007] si2168 4-0064: cmd execution took 1 ms > > [ 50.154010] si2168 4-0064: found a 'Silicon Labs Si2168' in cold > > state > > [ 50.181157] si2168 4-0064: downloading firmware from file > > 'dvb-demod-si2168-a30-01.fw' > > [ 50.233374] si2168 4-0064: cmd execution took 52 ms > > > > [ 53.300879] si2168 4-0064: cmd execution took 0 ms > > [ 53.300880] si2168 4-0064: found a 'Silicon Labs Si2168' in warm > > state > > [ 53.308282] si2157 6-0060: found a 'Silicon Labs > > Si2146/2147/2148/2157/2158' in cold state > > [ 53.321085] si2157 6-0060: downloading firmware from file > > 'dvb-tuner-si2158-a20-01.fw' > > [ 54.152370] si2168 4-0064: cmd execution took 1 ms > > > > So the initial timeout of 50ms is just missed. New value 60ms? or 75 to > > be really safe. > > 70ms sounds nice for my me. Wanna make a patch? Or if it sounds too hard > I could make it. No problem creating a patch (against git://linuxtv.org/media_tree.git ?). > Regards, Jurgen -- 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
