Re: tda8290 regression fix
On 2012-09-16 00:25, Mauro Carvalho Chehab wrote:
Em Sat, 15 Sep 2012 20:12:49 +0200
Anders Thomsonaerikss...@gmail.com escreveu:
On 2012-09-15 19:58, Mauro Carvalho Chehab wrote:
Em Sat, 15 Sep 2012 19:39:31 +0200
Anders Thomsonaerikss...@gmail.com escreveu:
On 2012-09-15 18:34, Mauro Carvalho Chehab wrote:
$ cat /TV_CARD.diff
diff --git a/drivers/media/common/tuners/tda8290.c
b/drivers/media/common/tuners/tda8290.c
index 064d14c..498cc7b 100644
--- a/drivers/media/common/tuners/tda8290.c
+++ b/drivers/media/common/tuners/tda8290.c
@@ -635,7 +635,11 @@ static int tda829x_find_tuner(struct
dvb_frontend *fe)
dvb_attach(tda827x_attach, fe,
priv-tda827x_addr,
priv-i2c_props.adap,priv-cfg);
+ tuner_info(ANDERS: setting switch_addr. was
0x%02x, new
0x%02x\n,priv-cfg.switch_addr,priv-i2c_props.addr);
priv-cfg.switch_addr =
priv-i2c_props.addr;
+ priv-cfg.switch_addr = 0xc2 / 2;
No, this is wrong. The I2C address is passed by the bridge driver
or by
the tuner_core attachment, being stored at priv-i2c_props.addr.
What's the driver and card you're using?
lspci -vv:
03:06.0 Multimedia controller: Philips Semiconductors
SAA7131/SAA7133/SAA7135 Video Broadcast Decoder (rev d1)
Subsystem: Pinnacle Systems Inc. Device 002f
There are lots of Pinnacle device supported by saa7134 driver. Without its
PCI ID that's not much we can do.
That here, right?
lspci -nvv:
03:06.0 0480: 1131:7133 (rev d1)
Subsystem: 11bd:002f
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
TAbort-TAbort-MAbort-SERR-PERR- INTx-
Latency: 64 (21000ns min, 8000ns max)
Interrupt: pin A routed to IRQ 21
Region 0: Memory at fdeff000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME-
Kernel driver in use: saa7134
Kernel modules: saa7134
Also, please post the dmesg showing what happens without and with your
patch.
Coming. Hold on...
Thanks!
Please try the enclosed patch.
-
[PATCH] tda8290: Fix lna switch address
When LNA is configured with config 1 or config 2, tda827x driver
will use the LNA switch_addr. However, this is not happening for
all devices using such config, as reported by Anders. According
to him, he is experiencing bad tuning with this code since
Kenrel 2.6.26.
Reported-by: Anders Thomsonaerikss...@gmail.com
Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com
diff --git a/drivers/media/tuners/tda8290.c b/drivers/media/tuners/tda8290.c
index 8c48521..bedc6ce 100644
--- a/drivers/media/tuners/tda8290.c
+++ b/drivers/media/tuners/tda8290.c
@@ -627,6 +627,9 @@ static int tda829x_find_tuner(struct dvb_frontend *fe)
return -EREMOTEIO;
}
+ if (priv-cfg.config == 1 || priv-cfg.config == 2)
+ priv-cfg.switch_addr = priv-i2c_props.addr;
+
if ((data == 0x83) || (data == 0x84)) {
priv-ver |= TDA18271;
tda829x_tda18271_config.config = priv-cfg.config;
@@ -640,7 +643,6 @@ static int tda829x_find_tuner(struct dvb_frontend *fe)
dvb_attach(tda827x_attach, fe, priv-tda827x_addr,
priv-i2c_props.adap,priv-cfg);
- priv-cfg.switch_addr = priv-i2c_props.addr;
}
if (fe-ops.tuner_ops.init)
fe-ops.tuner_ops.init(fe);
Hi,
Which tree should this be applied to? I have no drivers/media/tuners dir
here.
However, it applies cleanly to 3.5.3 as:
diff --git a/drivers/media/common/tuners/tda8290.c
b/drivers/media/common/tuners/tda8290.c
index 8c48521..bedc6ce 100644
--- a/drivers/media/common/tuners/tda8290.c
+++ b/drivers/media/common/tuners/tda8290.c
@@ -627,6 +627,9 @@ static int tda829x_find_tuner(struct dvb_frontend *fe)
return -EREMOTEIO;
}
+ if (priv-cfg.config == 1 || priv-cfg.config == 2)
+ priv-cfg.switch_addr = priv-i2c_props.addr;
+
if ((data == 0x83) || (data == 0x84)) {
priv-ver |= TDA18271;
tda829x_tda18271_config.config = priv-cfg.config;
@@ -640,7 +643,6 @@ static int tda829x_find_tuner(struct dvb_frontend *fe)
dvb_attach(tda827x_attach, fe, priv-tda827x_addr,
priv-i2c_props.adap, priv-cfg);
-
Re: pac7302-webcams and libv4lconvert interaction
Hi,
Am 13.09.2012 14:05, schrieb Hans de Goede:
Hi,
On 09/12/2012 04:36 PM, Frank Schäfer wrote:
snip
And a negative side effect is, that unknown pac7302 devices (with no
V4LCONTROL_ROTATED_90_JPEG entry in libv4lconvert) do not work.
With a consistent API behavior, they would work fine (output a rotated
image). Users would at least know that their device is working and most
of them know what to do next.
For image rotation, we still need to add an entry to libv4lconvert and
to modify it to invert the width and height values in v4l2_pix_format in
this case.
That is a good point, unfortunately we are stuck with how we are doing
things now, since changing things would break the kernel ABI.
Yeah, we can't break things. But I think this would be ABI fixing not
breaking. ;)
Actually...I'm not sure if this would be really an ABI change, because
the interface itself wouldn't change.
We would only fix a driver which passes a wrong value to userspace.
Its a question of interpretation...
Also ...
The device I have here is a good example: many people reported this
device as not working years ago, one of them even got a hint in a forum
that this could be a pac7302 device 2 years ago.
But with the gpsca-pac7302 driver, he got no picture and gave up.
And if I had not started q4vl2 from the terminal and had noticed the
error message from libv4lconvert, I would have needed much more time to
find out what's wrong...
True, OTOH just having this fixed won't help a regular user, as he/she
would still need to first add the new usb-id to the pac7302 driver...
Regular users, sure. But it would be a big step forward.
Adding new device IDs for testing is one of the easier things in the
Unix world.
Hans, I have a bunch of smaller things on my ToDo list which I want to
do first.
For now: maybe we can improve things by trusting the jpeg-header ?
That would mean removing the following section from
v4lconvert_decode_jpeg_tinyjpeg() :
if (data-control_flags V4LCONTROL_ROTATED_90_JPEG) {
unsigned int tmp = width;
width = height;
height = tmp;
}
if (header_width != width || header_height != height) {
V4LCONVERT_ERR(unexpected width / height in JPEG header:
expected: %ux%u, header: %ux%u\n,
width, height, header_width, header_height);
errno = EIO;
return -1;
}
V4LCONTROL_ROTATED_90_JPEG is only used for the pac7302 devices and we
know that their header is correct.
And even in cases where the header is wrong, I think it would we better
to get a garbeled picture instead of -EIO.
Regards,
Frank
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: [RFCv3 API PATCH 15/31] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.
On Sat September 15 2012 22:16:24 Sylwester Nawrocki wrote: On 09/15/2012 02:35 PM, Hans Verkuil wrote: If we switch all existing drivers to monotonic timestamps in kernel release 3.x, v4l2-compliance can just use the version it gets from VIDIOC_QUERYCAP and enforce monotonic timestamps verification if the version is= 3.x. This isn't more difficult for apps to check than a dedicated flag (although it's less explicit). I think that checking for the driver (kernel) version is a very poor substitute for testing against a proper flag. That flag should be the default in this case. The flag should be set by the framework instead giving every driver the job of setting it. One alternative might be to use a v4l2_buffer flag instead. That does have the advantage that in the future we can add additional flags should we need to support different clocks. Should we ever add support to switch clocks dynamically, then a buffer flag is more suitable than a driver capability. In that scenario it does make real sense to have a flag (or really mask). Say something like this: /* Clock Mask */ V4L2_BUF_FLAG_CLOCK_MASK 0xf000 /* Possible Clocks */ V4L2_BUF_FLAG_CLOCK_SYSTEM0x I realized that this should be called: V4L2_BUF_FLAG_CLOCK_UNKNOWN 0x With a comment saying that is clock is either the system clock or a monotonic clock. That reflects the current situation correctly. V4L2_BUF_FLAG_CLOCK_MONOTONIC 0x1000 There is already lots of overhead related to the buffers management, could we perhaps have the most common option defined in a way that drivers don't need to update each buffer's flags before dequeuing, only to indicate the timestamp type (other than flags being modified in videobuf) ? Well, if all vb2 drivers use the monotonic clock, then you could do it in __fill_v4l2_buffer: instead of clearing just the state flags you'd clear state + clock flags, and you OR in the monotonic flag in the case statement below (adding just a single b-flags |= line in the DEQUEUED case). So that wouldn't add any overhead. Not that I think setting a flag will add any measurable overhead in any case. This buffer flags idea sounds to me worse than the capability flag. After all the drivers should use monotonic clock timestamps, shouldn't they ? Yes. But you have monotonic and raw monotonic clocks at the moment, and perhaps others will be added in the future. You can't change clocks if you put this in the querycap capabilities. Have anyone has ever come with a use case for switching timestamps clock type, can anyone give an example of it ? How likely is we will ever need that ? Well, ALSA allows you to switch between gettimeofday and monotonic. So in theory at least if an app selects gettimeofday for alsa, that app might also want to select gettimeofday for v4l2. I'd really like to keep this door open. My experience is that if something is possible, then someone somewhere will want to use it. 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: ITE9135 on AMD SB700 - ehci_hcd bug
On 09/12/2012 09:32 AM, Marx wrote: Hello I'm trying to use dual DVB-T tuner based on ITE9135 tuner. I use Debian kernel 3.5-trunk-686-pae. My motherboard is AsRock E350M1 (no USB3 ports). Tuner is detected ok, see log at the end of post. When I try to scan channels, bug happens: Sep 11 17:16:31 wuwek kernel: [ 209.291329] ehci_hcd :00:13.2: force halt; handshake f821a024 4000 - -110 Sep 11 17:16:31 wuwek kernel: [ 209.291401] ehci_hcd :00:13.2: HC died; cleaning up Sep 11 17:16:31 wuwek kernel: [ 209.291606] usb 2-3: USB disconnect, device number 2 Sep 11 17:16:41 wuwek kernel: [ 219.312848] dvb-usb: error while stopping stream. Sep 11 17:16:41 wuwek kernel: [ 219.320585] dvb-usb: ITE 9135(9006) Generic successfully deinitialized and disconnected. After trying many ways I've read about problems with ehci on SB700 based boards and switched off ehci via command sh -c 'echo -n :00:13.2 unbind' and now ehci bug doesn't happen. Of course I can see only one tuner and in slower USB mode (see log at the end). But now I can scan succesfully without any errors. Of course it isn't acceptable fix for my problem. Drivers for ITE9135 seems ok, but there is a problem with ehci_hcd on my motherboard. I would like to know what can I do to fix my problem. I am quite sure dvb_usb_v2 fixes that. Test latest tree. 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: [RFCv3 API PATCH 15/31] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.
On Sunday 16 September 2012 15:57:14 Hans Verkuil wrote: On Sat September 15 2012 22:16:24 Sylwester Nawrocki wrote: On 09/15/2012 02:35 PM, Hans Verkuil wrote: If we switch all existing drivers to monotonic timestamps in kernel release 3.x, v4l2-compliance can just use the version it gets from VIDIOC_QUERYCAP and enforce monotonic timestamps verification if the version is= 3.x. This isn't more difficult for apps to check than a dedicated flag (although it's less explicit). I think that checking for the driver (kernel) version is a very poor substitute for testing against a proper flag. That flag should be the default in this case. The flag should be set by the framework instead giving every driver the job of setting it. One alternative might be to use a v4l2_buffer flag instead. That does have the advantage that in the future we can add additional flags should we need to support different clocks. Should we ever add support to switch clocks dynamically, then a buffer flag is more suitable than a driver capability. In that scenario it does make real sense to have a flag (or really mask). Say something like this: /* Clock Mask */ V4L2_BUF_FLAG_CLOCK_MASK0xf000 /* Possible Clocks */ V4L2_BUF_FLAG_CLOCK_SYSTEM 0x I realized that this should be called: V4L2_BUF_FLAG_CLOCK_UNKNOWN 0x With a comment saying that is clock is either the system clock or a monotonic clock. That reflects the current situation correctly. V4L2_BUF_FLAG_CLOCK_MONOTONIC 0x1000 There is already lots of overhead related to the buffers management, could we perhaps have the most common option defined in a way that drivers don't need to update each buffer's flags before dequeuing, only to indicate the timestamp type (other than flags being modified in videobuf) ? Well, if all vb2 drivers use the monotonic clock, then you could do it in __fill_v4l2_buffer: instead of clearing just the state flags you'd clear state + clock flags, and you OR in the monotonic flag in the case statement below (adding just a single b-flags |= line in the DEQUEUED case). So that wouldn't add any overhead. Not that I think setting a flag will add any measurable overhead in any case. This buffer flags idea sounds to me worse than the capability flag. After all the drivers should use monotonic clock timestamps, shouldn't they ? Yes. But you have monotonic and raw monotonic clocks at the moment, and perhaps others will be added in the future. You can't change clocks if you put this in the querycap capabilities. Have anyone has ever come with a use case for switching timestamps clock type, can anyone give an example of it ? How likely is we will ever need that ? Well, ALSA allows you to switch between gettimeofday and monotonic. So in theory at least if an app selects gettimeofday for alsa, that app might also want to select gettimeofday for v4l2. I'd really like to keep this door open. My experience is that if something is possible, then someone somewhere will want to use it. As far as system timestamps are concerned I think the monotonic clock should be enough, at least for now. Raw monotonic could possibly be useful later. Another important use case I have in mind is to provide raw device timestamps. For instance UVC devices send a device clock timestamp along with video frames. That timestamp can be useful to userspace applications. -- 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
How to set pixelaspect in struct v4l2_cropcap returned by VIDIOC_CROPCAP?
Guys I'm adding v4l2 output device support for VLC/ffmpeg/libav (I'm using v4l2loopback [1] driver for testing) but I have a problem which I can't seem to find a solution. VLC [2] uses VIDIOC_CROPCAP [3] to detect the pixelaspect ratio of the input it receives from v4l2 device. But I can't seem to find a way to set struct v4l2_cropcap.pixelaspect when I'm outputting data to the device and the result is that VLC assumes pixelaspect is 1:1. I was hoping that VIDIOC_S_CROP [4] would allow setting pixelaspect but according to docs that is not case. What am I missing? How to set pixelaspect values returned by VIDIOC_CROPCAP? [1]: https://github.com/umlaeute/v4l2loopback [2]: http://git.videolan.org/?p=vlc.git;a=blob;f=modules/access/v4l2/demux.c;hb=HEAD#l248 [3]: http://www.linuxtv.org/downloads/v4l-dvb-apis/vidioc-cropcap.html [4]: http://www.kernel.org/doc/htmldocs/media/vidioc-g-crop.html -- Georgi Chorbadzhiyski http://georgi.unixsol.org/ -- 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/4] gspca_pac7302: use registers 0x01 and 0x03 for red and blue balance controls
Currently used registers 0xc5 and 0xc7 provide only a very coarse
adjustment possibility within a very small value range (0-3).
With registers 0x01 and 0x03, a fine grained adjustment with
255 steps is possible. This is also what the Windows driver does.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/gspca/pac7302.c | 51 +
1 files changed, 40 insertions(+), 11 deletions(-)
diff --git a/drivers/media/usb/gspca/pac7302.c
b/drivers/media/usb/gspca/pac7302.c
index 4894ac1..8a0f4d6 100644
--- a/drivers/media/usb/gspca/pac7302.c
+++ b/drivers/media/usb/gspca/pac7302.c
@@ -77,12 +77,12 @@
*
* Page | Register | Function
* -++---
+ * 0 | 0x01 | setredbalance()
+ * 0 | 0x03 | setbluebalance()
* 0 | 0x0f..0x20 | setcolors()
* 0 | 0xa2..0xab | setbrightcont()
* 0 | 0xb6 | setsharpness()
- * 0 | 0xc5 | setredbalance()
* 0 | 0xc6 | setwhitebalance()
- * 0 | 0xc7 | setbluebalance()
* 0 | 0xdc | setbrightcont(), setcolors()
* 3 | 0x02 | setexposure()
* 3 | 0x10, 0x12 | setgain()
@@ -98,10 +98,13 @@
/* Include pac common sof detection functions */
#include pac_common.h
-#define PAC7302_GAIN_DEFAULT 15
-#define PAC7302_GAIN_KNEE 42
-#define PAC7302_EXPOSURE_DEFAULT 66 /* 33 ms / 30 fps */
-#define PAC7302_EXPOSURE_KNEE133 /* 66 ms / 15 fps */
+#define PAC7302_RGB_BALANCE_MIN 0
+#define PAC7302_RGB_BALANCE_MAX200
+#define PAC7302_RGB_BALANCE_DEFAULT100
+#define PAC7302_GAIN_DEFAULT15
+#define PAC7302_GAIN_KNEE 42
+#define PAC7302_EXPOSURE_DEFAULT66 /* 33 ms / 30 fps */
+#define PAC7302_EXPOSURE_KNEE 133 /* 66 ms / 15 fps */
MODULE_AUTHOR(Jean-Francois Moine http://moinejf.free.fr,
Thomas Kaiser tho...@kaiser-linux.li);
@@ -438,12 +441,31 @@ static void setwhitebalance(struct gspca_dev *gspca_dev)
reg_w(gspca_dev, 0xdc, 0x01);
}
+static u8 rgbbalance_ctrl_to_reg_value(s32 rgb_ctrl_val)
+{
+ const unsigned int k = 1000;/* precision factor */
+ unsigned int norm;
+
+ /* Normed value [0...k] */
+ norm = k * (rgb_ctrl_val - PAC7302_RGB_BALANCE_MIN)
+ / (PAC7302_RGB_BALANCE_MAX - PAC7302_RGB_BALANCE_MIN);
+ /* Qudratic apporach improves control at small (register) values: */
+ return 64 * norm * norm / (k*k) + 32 * norm / k + 32;
+ /* Y = 64*X*X + 32*X + 32
+* = register values 0x20-0x80; Windows driver uses these limits */
+
+ /* NOTE: for full value range (0x00-0xff) use
+* Y = 254*X*X + X
+* = 254 * norm * norm / (k*k) + 1 * norm / k*/
+}
+
static void setredbalance(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
- reg_w(gspca_dev, 0xff, 0x00); /* page 0 */
- reg_w(gspca_dev, 0xc5, sd-red_balance-val);
+ reg_w(gspca_dev, 0xff, 0x00); /* page 0 */
+ reg_w(gspca_dev, 0x01,
+ rgbbalance_ctrl_to_reg_value(sd-red_balance-val));
reg_w(gspca_dev, 0xdc, 0x01);
}
@@ -453,7 +475,8 @@ static void setbluebalance(struct gspca_dev *gspca_dev)
struct sd *sd = (struct sd *) gspca_dev;
reg_w(gspca_dev, 0xff, 0x00); /* page 0 */
- reg_w(gspca_dev, 0xc7, sd-blue_balance-val);
+ reg_w(gspca_dev, 0x03,
+ rgbbalance_ctrl_to_reg_value(sd-blue_balance-val));
reg_w(gspca_dev, 0xdc, 0x01);
}
@@ -642,9 +665,15 @@ static int sd_init_controls(struct gspca_dev *gspca_dev)
V4L2_CID_WHITE_BALANCE_TEMPERATURE,
0, 255, 1, 55);
sd-red_balance = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
- V4L2_CID_RED_BALANCE, 0, 3, 1, 1);
+ V4L2_CID_RED_BALANCE,
+ PAC7302_RGB_BALANCE_MIN,
+ PAC7302_RGB_BALANCE_MAX,
+ 1, PAC7302_RGB_BALANCE_DEFAULT);
sd-blue_balance = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
- V4L2_CID_BLUE_BALANCE, 0, 3, 1, 1);
+ V4L2_CID_BLUE_BALANCE,
+ PAC7302_RGB_BALANCE_MIN,
+ PAC7302_RGB_BALANCE_MAX,
+ 1, PAC7302_RGB_BALANCE_DEFAULT);
gspca_dev-autogain = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
V4L2_CID_AUTOGAIN, 0, 1, 1, 1);
--
1.7.7
--
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
[PATCH 3/4] v4l2-ctrl: add a control for green balance
We already support the red balance (V4L2_CID_RED_BALANCE) and
blue balance (V4L2_CID_BLUE_BALANCE) controls and lots of hardware
provides a possibility to adjust the green balance, too.
Several drivers already support this as custom controls, other just
don't do that due to the lack of a V4L2 standard control.
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
Documentation/DocBook/media/v4l/controls.xml |5 +
drivers/media/v4l2-core/v4l2-ctrls.c |2 ++
include/linux/videodev2.h|4 +++-
3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 272a5f7..dbb3b61 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -162,6 +162,11 @@ activated, keeps adjusting the white balance./entry
entryRed chroma balance./entry
/row
row
+ entryconstantV4L2_CID_GREEN_BALANCE/constant/entry
+ entryinteger/entry
+ entryGreen chroma balance./entry
+ /row
+ row
entryconstantV4L2_CID_BLUE_BALANCE/constant/entry
entryinteger/entry
entryBlue chroma balance./entry
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index ab287f2..39b9bb8 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -575,6 +575,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT: return Min Number of Output
Buffers;
case V4L2_CID_ALPHA_COMPONENT: return Alpha Component;
case V4L2_CID_COLORFX_CBCR: return Color Effects, CbCr;
+ case V4L2_CID_GREEN_BALANCE:return Green Balance;
/* MPEG controls */
/* Keep the order of the 'case's the same as in videodev2.h! */
@@ -941,6 +942,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_SATURATION:
case V4L2_CID_HUE:
case V4L2_CID_RED_BALANCE:
+ case V4L2_CID_GREEN_BALANCE:
case V4L2_CID_BLUE_BALANCE:
case V4L2_CID_GAMMA:
case V4L2_CID_SHARPNESS:
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 4862165..72354ad 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1390,8 +1390,10 @@ enum v4l2_colorfx {
#define V4L2_CID_ALPHA_COMPONENT (V4L2_CID_BASE+41)
#define V4L2_CID_COLORFX_CBCR (V4L2_CID_BASE+42)
+#define V4L2_CID_GREEN_BALANCE (V4L2_CID_BASE+43)
+
/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+43)
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+44)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
--
1.7.7
--
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/4] gspca_pac7302: add support for green balance adjustment
Signed-off-by: Frank Schäfer fschaefer@googlemail.com
---
drivers/media/usb/gspca/pac7302.c | 23 ++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/drivers/media/usb/gspca/pac7302.c
b/drivers/media/usb/gspca/pac7302.c
index 8a0f4d6..9b62b74 100644
--- a/drivers/media/usb/gspca/pac7302.c
+++ b/drivers/media/usb/gspca/pac7302.c
@@ -78,6 +78,7 @@
* Page | Register | Function
* -++---
* 0 | 0x01 | setredbalance()
+ * 0 | 0x02 | setgreenbalance()
* 0 | 0x03 | setbluebalance()
* 0 | 0x0f..0x20 | setcolors()
* 0 | 0xa2..0xab | setbrightcont()
@@ -121,6 +122,7 @@ struct sd {
struct v4l2_ctrl *saturation;
struct v4l2_ctrl *white_balance;
struct v4l2_ctrl *red_balance;
+ struct v4l2_ctrl *green_balance;
struct v4l2_ctrl *blue_balance;
struct { /* flip cluster */
struct v4l2_ctrl *hflip;
@@ -470,6 +472,17 @@ static void setredbalance(struct gspca_dev *gspca_dev)
reg_w(gspca_dev, 0xdc, 0x01);
}
+static void setgreenbalance(struct gspca_dev *gspca_dev)
+{
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ reg_w(gspca_dev, 0xff, 0x00); /* page 0 */
+ reg_w(gspca_dev, 0x02,
+ rgbbalance_ctrl_to_reg_value(sd-green_balance-val));
+
+ reg_w(gspca_dev, 0xdc, 0x01);
+}
+
static void setbluebalance(struct gspca_dev *gspca_dev)
{
struct sd *sd = (struct sd *) gspca_dev;
@@ -620,6 +633,9 @@ static int sd_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_RED_BALANCE:
setredbalance(gspca_dev);
break;
+ case V4L2_CID_GREEN_BALANCE:
+ setgreenbalance(gspca_dev);
+ break;
case V4L2_CID_BLUE_BALANCE:
setbluebalance(gspca_dev);
break;
@@ -652,7 +668,7 @@ static int sd_init_controls(struct gspca_dev *gspca_dev)
struct v4l2_ctrl_handler *hdl = gspca_dev-ctrl_handler;
gspca_dev-vdev.ctrl_handler = hdl;
- v4l2_ctrl_handler_init(hdl, 12);
+ v4l2_ctrl_handler_init(hdl, 13);
sd-brightness = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
V4L2_CID_BRIGHTNESS, 0, 32, 1, 16);
@@ -669,6 +685,11 @@ static int sd_init_controls(struct gspca_dev *gspca_dev)
PAC7302_RGB_BALANCE_MIN,
PAC7302_RGB_BALANCE_MAX,
1, PAC7302_RGB_BALANCE_DEFAULT);
+ sd-green_balance = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
+ V4L2_CID_GREEN_BALANCE,
+ PAC7302_RGB_BALANCE_MIN,
+ PAC7302_RGB_BALANCE_MAX,
+ 1, PAC7302_RGB_BALANCE_DEFAULT);
sd-blue_balance = v4l2_ctrl_new_std(hdl, sd_ctrl_ops,
V4L2_CID_BLUE_BALANCE,
PAC7302_RGB_BALANCE_MIN,
--
1.7.7
--
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] Support for Asus MyCinema U3100Mini Plus
Any pointers where else to look? I'm kinda lost at the moment :)
Oliver
On 09/10/12 19:28, Oliver Schinagl wrote:
On 09/10/12 16:29, Oliver Schinagl wrote:
On 10-09-12 13:46, Antti Palosaari wrote:
On 09/10/2012 12:58 PM, Oliver Schinagl wrote:
Changed the address as recommended, which after reading 7bit and 8bit
addressing makes perfect sense (drop the r/w bit and get the actual
address).
static struct fc2580_config af9035_fc2580_config = {
- .i2c_addr = 0xac,
+ .i2c_addr = 0x56,
.clock = 16384000,
};
So now the address should actually be correct ;)
Unfortunately, nothing. What other debug options do I need to enable
besides CONFIG_DVB_USB_DEBUG to get more interesting output?
For me it sees something happens as there is no I2C error seen anymore.
AF9035 driver uses Kernel dynamic debugs. CONFIG_DVB_USB_DEBUG is
legacy and proprietary DVB subsystem debug which should not be used
anymore.
You could order dynamic debugs like that:
modprobe dvb_usb_af9035; echo -n 'module dvb_usb_af9035 +p'
/sys/kernel/debug/dynamic_debug/control
For tuner, demod and dvb_usbv2 similarly if needed.
I've did and added output from control and dmesg output.
I don't exactly know how to read the dynamic debug output, the only
thing that jumped out at me, was:
drivers/media/dvb-frontends/af9033.c:327 [af9033]af9033_init =p %s:
unsupported tuner ID=%d\012
So I will search and see where in the driver the supported tunerID's are
stored and fix that.
Any other pointers/things you see I should look at?
Appearantly, I setup the tuner, like the others, but it skips that
because the tuner id is wrong/not set.
case AF9033_TUNER_FC2580:
len = ARRAY_SIZE(tuner_init_fc2580);
init = tuner_init_fc2580;
break;
So where is the tuner set?
I did find this bit:
tatic int af9035_read_config(struct dvb_usb_device *d)
{
snip
ret = af9035_rd_reg(d, EEPROM_1_TUNER_ID + eeprom_shift, tmp);
which suggests that it comes from the actual eeprom. I assumed that the
'init/script/firmware' bit, the first 'message' was the ID, 0x32 in the
case of this tuner. I guess I'm wrong?
The log is not exactly helpful either:
drivers/media/usb/dvb-usb-v2/af9035.c:542
[dvb_usb_af9035]af9035_read_config =_ %s: [%d]tuner=%02x\012
So close, yet so far. So if I'm right, the actual ID of the tuner and
the first byte in the init are not always the same? Then why use the
define in the first place there? And why would the 'official' code user
0x32 as tuner ID. Or is this simply a dec/hex conversion goof?
Oliver
Anyway, dmesg reports the following.
[60.071538] usb 1-3: new high-speed USB device number 3 using ehci_hcd
[60.192627] usb 1-3: New USB device found, idVendor=0b05,
idProduct=1779
[60.192638] usb 1-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[60.192646] usb 1-3: Product: AF9035A USB Device
[60.192652] usb 1-3: Manufacturer: Afa Technologies Inc.
[60.192657] usb 1-3: SerialNumber: AF010asdfasdf12314
[60.198686] input: Afa Technologies Inc. AF9035A USB Device as
/devices/pci:00/:00:12.2/usb1/1-3/1-3:1.1/input/input14
[60.198832] hid-generic 0003:0B05:1779.0003: input: USB HID v1.01
Keyboard [Afa Technologies Inc. AF9035A USB Device] on
usb-:00:12.2-3/input1
[60.263893] usbcore: registered new interface driver dvb_usb_af9035
[60.264605] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in cold
state
[60.273924] usb 1-3: dvb_usbv2: downloading firmware from file
'dvb-usb-af9035-02.fw'
[60.584267] dvb_usb_af9035: firmware version=11.5.9.0
[60.584287] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in warm
state
[60.586802] usb 1-3: dvb_usbv2: will pass the complete MPEG2 transport
stream to the software demuxer
[60.586871] DVB: registering new adapter (Asus U3100Mini Plus)
[60.595637] af9033: firmware version: LINK=11.5.9.0 OFDM=5.17.9.1
[60.595654] usb 1-3: DVB: registering adapter 0 frontend 0 (Afatech
AF9033 (DVB-T))...
[60.599889] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while
loading driver (-19)
I then tried using the firmware that came with said driver, as the
version seems slightly different/newer.
#define FW_RELEASE_VERSION v8_8_63_0
#define DVB_LL_VERSION1 11
#define DVB_LL_VERSION2 22
#define DVB_LL_VERSION3 12
#define DVB_LL_VERSION4 0
#define DVB_OFDM_VERSION1 5
#define DVB_OFDM_VERSION2 66
#define DVB_OFDM_VERSION3 12
#define DVB_OFDM_VERSION4 0
(which also gets displayed when loading the firmware, originally on the
old kernel).
This however results in a hard lock/dump when plugging in the device.
Are there certain size restrictions etc? What I did to obtain said
firmware was write a simple program that reads the array, static
unsigned char Firmware_codes[] and outputs the read bytes to a file.
From what I saw from the -02 firmware, the first few bytes are
identical (header?) so should be right procedure.
Firmare surely works but you make some mistake. I have extracted those
from the windows driver.
Re: How to set pixelaspect in struct v4l2_cropcap returned by VIDIOC_CROPCAP?
On Sun September 16 2012 17:32:52 Georgi Chorbadzhiyski wrote: Guys I'm adding v4l2 output device support for VLC/ffmpeg/libav (I'm using v4l2loopback [1] driver for testing) but I have a problem which I can't seem to find a solution. VLC [2] uses VIDIOC_CROPCAP [3] to detect the pixelaspect ratio of the input it receives from v4l2 device. But I can't seem to find a way to set struct v4l2_cropcap.pixelaspect when I'm outputting data to the device and the result is that VLC assumes pixelaspect is 1:1. I was hoping that VIDIOC_S_CROP [4] would allow setting pixelaspect but according to docs that is not case. What am I missing? The pixelaspect ratio returned by CROPCAP depends on the current video standard of the video receiver or transmitter. So for video capture the pixelaspect depends on the standard (50 vs 60 Hz) and the horizontal sampling frequency of the video receiver (hardware specific). For video output the pixelaspect depends also on the standard and on how the transmitter goes from digital to analog pixels (the reverse of what a receiver does). It is *not* the pixelaspect of the video data itself. For output it is the pixel aspect that the transmitter expects. Any difference between the two will need to be resolved somehow, typically by software or hardware scaling. Regards, Hans How to set pixelaspect values returned by VIDIOC_CROPCAP? [1]: https://github.com/umlaeute/v4l2loopback [2]: http://git.videolan.org/?p=vlc.git;a=blob;f=modules/access/v4l2/demux.c;hb=HEAD#l248 [3]: http://www.linuxtv.org/downloads/v4l-dvb-apis/vidioc-cropcap.html [4]: http://www.kernel.org/doc/htmldocs/media/vidioc-g-crop.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] Support for Asus MyCinema U3100Mini Plus
Hello
You have about all the possible info. There is chipset vendor driver
look example and existing Linux drivers for all the used chips. Just few
lines of code needed for the device profile. I surely can help, but it
is not something I would like to teach and say do that and test that. It
is wasting my time. I encourage you to take one simple USB capture from
Windows driver and look help from there. GPIOs are the first thing to test.
Also maintaining driver without a hardware is something that causes
always headache later when some changes are needed to do that driver :s
regards
Antti
On 09/16/2012 05:07 PM, Oliver Schinagl wrote:
Any pointers where else to look? I'm kinda lost at the moment :)
Oliver
On 09/10/12 19:28, Oliver Schinagl wrote:
On 09/10/12 16:29, Oliver Schinagl wrote:
On 10-09-12 13:46, Antti Palosaari wrote:
On 09/10/2012 12:58 PM, Oliver Schinagl wrote:
Changed the address as recommended, which after reading 7bit and 8bit
addressing makes perfect sense (drop the r/w bit and get the actual
address).
static struct fc2580_config af9035_fc2580_config = {
- .i2c_addr = 0xac,
+ .i2c_addr = 0x56,
.clock = 16384000,
};
So now the address should actually be correct ;)
Unfortunately, nothing. What other debug options do I need to enable
besides CONFIG_DVB_USB_DEBUG to get more interesting output?
For me it sees something happens as there is no I2C error seen anymore.
AF9035 driver uses Kernel dynamic debugs. CONFIG_DVB_USB_DEBUG is
legacy and proprietary DVB subsystem debug which should not be used
anymore.
You could order dynamic debugs like that:
modprobe dvb_usb_af9035; echo -n 'module dvb_usb_af9035 +p'
/sys/kernel/debug/dynamic_debug/control
For tuner, demod and dvb_usbv2 similarly if needed.
I've did and added output from control and dmesg output.
I don't exactly know how to read the dynamic debug output, the only
thing that jumped out at me, was:
drivers/media/dvb-frontends/af9033.c:327 [af9033]af9033_init =p %s:
unsupported tuner ID=%d\012
So I will search and see where in the driver the supported tunerID's are
stored and fix that.
Any other pointers/things you see I should look at?
Appearantly, I setup the tuner, like the others, but it skips that
because the tuner id is wrong/not set.
case AF9033_TUNER_FC2580:
len = ARRAY_SIZE(tuner_init_fc2580);
init = tuner_init_fc2580;
break;
So where is the tuner set?
I did find this bit:
tatic int af9035_read_config(struct dvb_usb_device *d)
{
snip
ret = af9035_rd_reg(d, EEPROM_1_TUNER_ID + eeprom_shift, tmp);
which suggests that it comes from the actual eeprom. I assumed that the
'init/script/firmware' bit, the first 'message' was the ID, 0x32 in the
case of this tuner. I guess I'm wrong?
The log is not exactly helpful either:
drivers/media/usb/dvb-usb-v2/af9035.c:542
[dvb_usb_af9035]af9035_read_config =_ %s: [%d]tuner=%02x\012
So close, yet so far. So if I'm right, the actual ID of the tuner and
the first byte in the init are not always the same? Then why use the
define in the first place there? And why would the 'official' code user
0x32 as tuner ID. Or is this simply a dec/hex conversion goof?
Oliver
Anyway, dmesg reports the following.
[60.071538] usb 1-3: new high-speed USB device number 3 using ehci_hcd
[60.192627] usb 1-3: New USB device found, idVendor=0b05,
idProduct=1779
[60.192638] usb 1-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[60.192646] usb 1-3: Product: AF9035A USB Device
[60.192652] usb 1-3: Manufacturer: Afa Technologies Inc.
[60.192657] usb 1-3: SerialNumber: AF010asdfasdf12314
[60.198686] input: Afa Technologies Inc. AF9035A USB Device as
/devices/pci:00/:00:12.2/usb1/1-3/1-3:1.1/input/input14
[60.198832] hid-generic 0003:0B05:1779.0003: input: USB HID v1.01
Keyboard [Afa Technologies Inc. AF9035A USB Device] on
usb-:00:12.2-3/input1
[60.263893] usbcore: registered new interface driver dvb_usb_af9035
[60.264605] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in cold
state
[60.273924] usb 1-3: dvb_usbv2: downloading firmware from file
'dvb-usb-af9035-02.fw'
[60.584267] dvb_usb_af9035: firmware version=11.5.9.0
[60.584287] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in warm
state
[60.586802] usb 1-3: dvb_usbv2: will pass the complete MPEG2 transport
stream to the software demuxer
[60.586871] DVB: registering new adapter (Asus U3100Mini Plus)
[60.595637] af9033: firmware version: LINK=11.5.9.0 OFDM=5.17.9.1
[60.595654] usb 1-3: DVB: registering adapter 0 frontend 0 (Afatech
AF9033 (DVB-T))...
[60.599889] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while
loading driver (-19)
I then tried using the firmware that came with said driver, as the
version seems slightly different/newer.
#define FW_RELEASE_VERSION v8_8_63_0
#define DVB_LL_VERSION1 11
#define DVB_LL_VERSION2 22
#define DVB_LL_VERSION3 12
#define DVB_LL_VERSION4 0
#define DVB_OFDM_VERSION1 5
#define DVB_OFDM_VERSION2 66
#define
Re: How to set pixelaspect in struct v4l2_cropcap returned by VIDIOC_CROPCAP?
On 9/16/12 7:28 PM, Hans Verkuil wrote: On Sun September 16 2012 17:32:52 Georgi Chorbadzhiyski wrote: Guys I'm adding v4l2 output device support for VLC/ffmpeg/libav (I'm using v4l2loopback [1] driver for testing) but I have a problem which I can't seem to find a solution. VLC [2] uses VIDIOC_CROPCAP [3] to detect the pixelaspect ratio of the input it receives from v4l2 device. But I can't seem to find a way to set struct v4l2_cropcap.pixelaspect when I'm outputting data to the device and the result is that VLC assumes pixelaspect is 1:1. I was hoping that VIDIOC_S_CROP [4] would allow setting pixelaspect but according to docs that is not case. What am I missing? The pixelaspect ratio returned by CROPCAP depends on the current video standard of the video receiver or transmitter. So for video capture the pixelaspect depends on the standard (50 vs 60 Hz) and the horizontal sampling frequency of the video receiver (hardware specific). For video output the pixelaspect depends also on the standard and on how the transmitter goes from digital to analog pixels (the reverse of what a receiver does). It is *not* the pixelaspect of the video data itself. For output it is the pixel aspect that the transmitter expects. Any difference between the two will need to be resolved somehow, typically by software or hardware scaling. Since I'm using virtual output v4l2 loopback device this means I have to set the standard somehow, right? -- Georgi Chorbadzhiyski http://georgi.unixsol.org/ -- 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] Support for Asus MyCinema U3100Mini Plus
I don't have windows, so capturing using windows is near impossible.
Also since the vendor driver used to work, I guess I will have to dig
into that more.
Since all the pieces should be there, fc2580 driver, af9033/5 driver,
it's just a matter of glueing things together, right? I'll dig further
into it and see what I can find/do.
On 09/16/12 18:43, Antti Palosaari wrote:
Hello
You have about all the possible info. There is chipset vendor driver
look example and existing Linux drivers for all the used chips. Just few
lines of code needed for the device profile. I surely can help, but it
is not something I would like to teach and say do that and test that. It
is wasting my time. I encourage you to take one simple USB capture from
Windows driver and look help from there. GPIOs are the first thing to test.
Also maintaining driver without a hardware is something that causes
always headache later when some changes are needed to do that driver :s
regards
Antti
On 09/16/2012 05:07 PM, Oliver Schinagl wrote:
Any pointers where else to look? I'm kinda lost at the moment :)
Oliver
On 09/10/12 19:28, Oliver Schinagl wrote:
On 09/10/12 16:29, Oliver Schinagl wrote:
On 10-09-12 13:46, Antti Palosaari wrote:
On 09/10/2012 12:58 PM, Oliver Schinagl wrote:
Changed the address as recommended, which after reading 7bit and 8bit
addressing makes perfect sense (drop the r/w bit and get the actual
address).
static struct fc2580_config af9035_fc2580_config = {
- .i2c_addr = 0xac,
+ .i2c_addr = 0x56,
.clock = 16384000,
};
So now the address should actually be correct ;)
Unfortunately, nothing. What other debug options do I need to enable
besides CONFIG_DVB_USB_DEBUG to get more interesting output?
For me it sees something happens as there is no I2C error seen
anymore.
AF9035 driver uses Kernel dynamic debugs. CONFIG_DVB_USB_DEBUG is
legacy and proprietary DVB subsystem debug which should not be used
anymore.
You could order dynamic debugs like that:
modprobe dvb_usb_af9035; echo -n 'module dvb_usb_af9035 +p'
/sys/kernel/debug/dynamic_debug/control
For tuner, demod and dvb_usbv2 similarly if needed.
I've did and added output from control and dmesg output.
I don't exactly know how to read the dynamic debug output, the only
thing that jumped out at me, was:
drivers/media/dvb-frontends/af9033.c:327 [af9033]af9033_init =p %s:
unsupported tuner ID=%d\012
So I will search and see where in the driver the supported tunerID's
are
stored and fix that.
Any other pointers/things you see I should look at?
Appearantly, I setup the tuner, like the others, but it skips that
because the tuner id is wrong/not set.
case AF9033_TUNER_FC2580:
len = ARRAY_SIZE(tuner_init_fc2580);
init = tuner_init_fc2580;
break;
So where is the tuner set?
I did find this bit:
tatic int af9035_read_config(struct dvb_usb_device *d)
{
snip
ret = af9035_rd_reg(d, EEPROM_1_TUNER_ID + eeprom_shift, tmp);
which suggests that it comes from the actual eeprom. I assumed that the
'init/script/firmware' bit, the first 'message' was the ID, 0x32 in the
case of this tuner. I guess I'm wrong?
The log is not exactly helpful either:
drivers/media/usb/dvb-usb-v2/af9035.c:542
[dvb_usb_af9035]af9035_read_config =_ %s: [%d]tuner=%02x\012
So close, yet so far. So if I'm right, the actual ID of the tuner and
the first byte in the init are not always the same? Then why use the
define in the first place there? And why would the 'official' code user
0x32 as tuner ID. Or is this simply a dec/hex conversion goof?
Oliver
Anyway, dmesg reports the following.
[60.071538] usb 1-3: new high-speed USB device number 3 using
ehci_hcd
[60.192627] usb 1-3: New USB device found, idVendor=0b05,
idProduct=1779
[60.192638] usb 1-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[60.192646] usb 1-3: Product: AF9035A USB Device
[60.192652] usb 1-3: Manufacturer: Afa Technologies Inc.
[60.192657] usb 1-3: SerialNumber: AF010asdfasdf12314
[60.198686] input: Afa Technologies Inc. AF9035A USB Device as
/devices/pci:00/:00:12.2/usb1/1-3/1-3:1.1/input/input14
[60.198832] hid-generic 0003:0B05:1779.0003: input: USB HID v1.01
Keyboard [Afa Technologies Inc. AF9035A USB Device] on
usb-:00:12.2-3/input1
[60.263893] usbcore: registered new interface driver dvb_usb_af9035
[60.264605] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in cold
state
[60.273924] usb 1-3: dvb_usbv2: downloading firmware from file
'dvb-usb-af9035-02.fw'
[60.584267] dvb_usb_af9035: firmware version=11.5.9.0
[60.584287] usb 1-3: dvb_usbv2: found a 'Asus U3100Mini Plus' in warm
state
[60.586802] usb 1-3: dvb_usbv2: will pass the complete MPEG2
transport
stream to the software demuxer
[60.586871] DVB: registering new adapter (Asus U3100Mini Plus)
[60.595637] af9033: firmware version: LINK=11.5.9.0 OFDM=5.17.9.1
[60.595654] usb 1-3: DVB: registering adapter 0 frontend 0 (Afatech
AF9033 (DVB-T))...
[60.599889] usb 1-3: dvb_usbv2: 'Asus
Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
On 09/16/2012 06:03 PM, Oliver Schinagl wrote:
I don't have windows, so capturing using windows is near impossible.
Also since the vendor driver used to work, I guess I will have to dig
into that more.
You could capture data from Linux too (eg. Wireshark).
But with a little experience you could see those GPIOs reading existing
Linux driver and then do some tests to see what happens. For example
some GPIO powers tuner off, you will see I2C error. Changing it back
error disappears.
Since all the pieces should be there, fc2580 driver, af9033/5 driver,
it's just a matter of glueing things together, right? I'll dig further
into it and see what I can find/do.
Correct. Tuner init (demod settings fc2580) for is needed for af9033.
And GPIOs for AF9035. In very bad luck some changes for fc2580 is needed
too, but it is not very, very, unlikely.
This patch is very similar you will need to do (tda18218 tuner support
for af9035):
http://patchwork.linuxtv.org/patch/10547/
regards
Antti
On 09/16/12 18:43, Antti Palosaari wrote:
Hello
You have about all the possible info. There is chipset vendor driver
look example and existing Linux drivers for all the used chips. Just few
lines of code needed for the device profile. I surely can help, but it
is not something I would like to teach and say do that and test that. It
is wasting my time. I encourage you to take one simple USB capture from
Windows driver and look help from there. GPIOs are the first thing to
test.
Also maintaining driver without a hardware is something that causes
always headache later when some changes are needed to do that
driver :s
regards
Antti
On 09/16/2012 05:07 PM, Oliver Schinagl wrote:
Any pointers where else to look? I'm kinda lost at the moment :)
Oliver
On 09/10/12 19:28, Oliver Schinagl wrote:
On 09/10/12 16:29, Oliver Schinagl wrote:
On 10-09-12 13:46, Antti Palosaari wrote:
On 09/10/2012 12:58 PM, Oliver Schinagl wrote:
Changed the address as recommended, which after reading 7bit and
8bit
addressing makes perfect sense (drop the r/w bit and get the actual
address).
static struct fc2580_config af9035_fc2580_config = {
- .i2c_addr = 0xac,
+ .i2c_addr = 0x56,
.clock = 16384000,
};
So now the address should actually be correct ;)
Unfortunately, nothing. What other debug options do I need to enable
besides CONFIG_DVB_USB_DEBUG to get more interesting output?
For me it sees something happens as there is no I2C error seen
anymore.
AF9035 driver uses Kernel dynamic debugs. CONFIG_DVB_USB_DEBUG is
legacy and proprietary DVB subsystem debug which should not be used
anymore.
You could order dynamic debugs like that:
modprobe dvb_usb_af9035; echo -n 'module dvb_usb_af9035 +p'
/sys/kernel/debug/dynamic_debug/control
For tuner, demod and dvb_usbv2 similarly if needed.
I've did and added output from control and dmesg output.
I don't exactly know how to read the dynamic debug output, the only
thing that jumped out at me, was:
drivers/media/dvb-frontends/af9033.c:327 [af9033]af9033_init =p %s:
unsupported tuner ID=%d\012
So I will search and see where in the driver the supported tunerID's
are
stored and fix that.
Any other pointers/things you see I should look at?
Appearantly, I setup the tuner, like the others, but it skips that
because the tuner id is wrong/not set.
case AF9033_TUNER_FC2580:
len = ARRAY_SIZE(tuner_init_fc2580);
init = tuner_init_fc2580;
break;
So where is the tuner set?
I did find this bit:
tatic int af9035_read_config(struct dvb_usb_device *d)
{
snip
ret = af9035_rd_reg(d, EEPROM_1_TUNER_ID + eeprom_shift,
tmp);
which suggests that it comes from the actual eeprom. I assumed that the
'init/script/firmware' bit, the first 'message' was the ID, 0x32 in the
case of this tuner. I guess I'm wrong?
The log is not exactly helpful either:
drivers/media/usb/dvb-usb-v2/af9035.c:542
[dvb_usb_af9035]af9035_read_config =_ %s: [%d]tuner=%02x\012
So close, yet so far. So if I'm right, the actual ID of the tuner and
the first byte in the init are not always the same? Then why use the
define in the first place there? And why would the 'official' code user
0x32 as tuner ID. Or is this simply a dec/hex conversion goof?
Oliver
Anyway, dmesg reports the following.
[60.071538] usb 1-3: new high-speed USB device number 3 using
ehci_hcd
[60.192627] usb 1-3: New USB device found, idVendor=0b05,
idProduct=1779
[60.192638] usb 1-3: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[60.192646] usb 1-3: Product: AF9035A USB Device
[60.192652] usb 1-3: Manufacturer: Afa Technologies Inc.
[60.192657] usb 1-3: SerialNumber: AF010asdfasdf12314
[60.198686] input: Afa Technologies Inc. AF9035A USB Device as
/devices/pci:00/:00:12.2/usb1/1-3/1-3:1.1/input/input14
[60.198832] hid-generic 0003:0B05:1779.0003: input: USB HID v1.01
Keyboard [Afa Technologies Inc. AF9035A USB Device] on
usb-:00:12.2-3/input1
[60.263893] usbcore: registered new interface
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sun Sep 16 19:00:20 CEST 2012 git hash:36aee5ff9098a871bda38dbbdad40ad59f6535cf gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS linux-2.6.37-x86_64: ERRORS linux-2.6.38.2-x86_64: ERRORS linux-2.6.39.1-x86_64: ERRORS linux-3.0-x86_64: ERRORS linux-3.1-x86_64: ERRORS linux-3.2.1-x86_64: ERRORS linux-3.3-x86_64: ERRORS linux-3.4-x86_64: ERRORS linux-3.5-x86_64: WARNINGS linux-3.6-rc2-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS linux-2.6.37-i686: ERRORS linux-2.6.38.2-i686: ERRORS linux-2.6.39.1-i686: ERRORS linux-3.0-i686: ERRORS linux-3.1-i686: ERRORS linux-3.2.1-i686: ERRORS linux-3.3-i686: ERRORS linux-3.4-i686: ERRORS linux-3.5-i686: WARNINGS linux-3.6-rc2-i686: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 2/9] ir-rx51: Handle signals properly
On Fri, Sep 14, 2012 at 10:58:53AM +0300, Timo Kokkonen wrote: It appears that all modern lirc drivers are now using the rc-core functionalities to implement the common stuff. When the rx51 lirc driver was first written, the core was not in place yet. Therefore it is implementing the file operations in the driver, which other rc drivers won't do today. So, I think it would make sense to modify the rx51 driver to use the rc core functionality. But if there is an ABI change ongoing, I could wait until you have that done before I start working on the change? There is no immediate need for porting to rc-core, AFAIK. OTOH I suspect that only some of the drivers using rc-core will only need to have their tx_ir method modified for a new sending/receiving ABI, so it shouldn't stop you. If anything it might make the driver smaller. At the moment I'm only just put initial patches together so I don't know when I or anyone else will have this finished. Sean -- 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: [RFCv3 API PATCH 15/31] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.
On 09/16/2012 05:33 PM, Laurent Pinchart wrote: On Sunday 16 September 2012 15:57:14 Hans Verkuil wrote: On Sat September 15 2012 22:16:24 Sylwester Nawrocki wrote: On 09/15/2012 02:35 PM, Hans Verkuil wrote: If we switch all existing drivers to monotonic timestamps in kernel release 3.x, v4l2-compliance can just use the version it gets from VIDIOC_QUERYCAP and enforce monotonic timestamps verification if the version is= 3.x. This isn't more difficult for apps to check than a dedicated flag (although it's less explicit). I think that checking for the driver (kernel) version is a very poor substitute for testing against a proper flag. That flag should be the default in this case. The flag should be set by the framework instead giving every driver the job of setting it. One alternative might be to use a v4l2_buffer flag instead. That does have the advantage that in the future we can add additional flags should we need to support different clocks. Should we ever add support to switch clocks dynamically, then a buffer flag is more suitable than a driver capability. In that scenario it does make real sense to have a flag (or really mask). Say something like this: /* Clock Mask */ V4L2_BUF_FLAG_CLOCK_MASK 0xf000 /* Possible Clocks */ V4L2_BUF_FLAG_CLOCK_SYSTEM 0x I realized that this should be called: V4L2_BUF_FLAG_CLOCK_UNKNOWN0x With a comment saying that is clock is either the system clock or a monotonic clock. That reflects the current situation correctly. V4L2_BUF_FLAG_CLOCK_MONOTONIC0x1000 There is already lots of overhead related to the buffers management, could we perhaps have the most common option defined in a way that drivers don't need to update each buffer's flags before dequeuing, only to indicate the timestamp type (other than flags being modified in videobuf) ? Well, if all vb2 drivers use the monotonic clock, then you could do it in __fill_v4l2_buffer: instead of clearing just the state flags you'd clear state + clock flags, and you OR in the monotonic flag in the case statement below (adding just a single b-flags |= line in the DEQUEUED case). So that wouldn't add any overhead. Not that I think setting a flag will add any measurable overhead in any case. Yes, that might be indeed negligible overhead, especially if it's done well. User space logic usually adds much more to complexity. Might be good idea to add some helpers to videobuf2, so handling timestamps is as simple as possible in drivers. This buffer flags idea sounds to me worse than the capability flag. After all the drivers should use monotonic clock timestamps, shouldn't they ? Yes. But you have monotonic and raw monotonic clocks at the moment, and perhaps others will be added in the future. You can't change clocks if you put this in the querycap capabilities. Fair enough. BTW, CLOCK_MONOTONIC_RAW is not defined in any POSIX standard, is it ? Have anyone has ever come with a use case for switching timestamps clock type, can anyone give an example of it ? How likely is we will ever need that ? Well, ALSA allows you to switch between gettimeofday and monotonic. So in theory at least if an app selects gettimeofday for alsa, that app might also want to select gettimeofday for v4l2. OK, I'm not complaining any more. :) I'd really like to keep this door open. My experience is that if something is possible, then someone somewhere will want to use it. Indeed, caps flags approach might be too limited anyway. And a v4l2 control might be not good for reporting things like these. As far as system timestamps are concerned I think the monotonic clock should be enough, at least for now. Raw monotonic could possibly be useful later. Another important use case I have in mind is to provide raw device timestamps. For instance UVC devices send a device clock timestamp along with video frames. That timestamp can be useful to userspace applications. Could be interesting to add support for something like this. Of what format are then such device timestamps ? -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
On 09/16/12 19:25, Antti Palosaari wrote:
On 09/16/2012 06:03 PM, Oliver Schinagl wrote:
I don't have windows, so capturing using windows is near impossible.
Also since the vendor driver used to work, I guess I will have to dig
into that more.
You could capture data from Linux too (eg. Wireshark).
Ah of course. I'll dig up the old vendor driver and see if I can get it
running on 3.2 or better yet, on 3.5/your-3.6. I know there's patches
for 3.2 but I've never tested those. Otherwise the older 2.6.2* series
should still work.
But with a little experience you could see those GPIOs reading existing
Linux driver and then do some tests to see what happens. For example
some GPIO powers tuner off, you will see I2C error. Changing it back
error disappears.
I have zero experience so I'll try to figure things out. I guess you
currently turn on/off GPIO's etc in the current driver? Any line which
does this so I can examine how it's done? As for the I2C errors, I
suppose the current driver will spew those out?
Speaking off, in my previous message, I wrote about the driver spitting
out the following error:
[dvb_usb_af9035]af9035_read_config =_ %s: [%d]tuner=%02x\012
None of the values where set however. Did I miss-configure anything for
it to cause to 'forget' substituting?
Since all the pieces should be there, fc2580 driver, af9033/5 driver,
it's just a matter of glueing things together, right? I'll dig further
into it and see what I can find/do.
Correct. Tuner init (demod settings fc2580) for is needed for af9033.
And GPIOs for AF9035. In very bad luck some changes for fc2580 is needed
too, but it is not very, very, unlikely.
This patch is very similar you will need to do (tda18218 tuner support
for af9035):
http://patchwork.linuxtv.org/patch/10547/
I re-did my patch using that as a template (before I used your work on
the rtl) and got the exact result.
Your rtl|fc2580 combo btw (from bare memory) didn't have the fc2580_init
stream in af9033_priv.h. What exactly gets init-ed there? The af9033 to
work with the fc2580?
regards
Antti
Thanks so far,
Oliver
On 09/16/12 18:43, Antti Palosaari wrote:
Hello
You have about all the possible info. There is chipset vendor driver
look example and existing Linux drivers for all the used chips. Just few
lines of code needed for the device profile. I surely can help, but it
is not something I would like to teach and say do that and test that. It
is wasting my time. I encourage you to take one simple USB capture from
Windows driver and look help from there. GPIOs are the first thing to
test.
Also maintaining driver without a hardware is something that causes
always headache later when some changes are needed to do that
driver :s
regards
Antti
On 09/16/2012 05:07 PM, Oliver Schinagl wrote:
Any pointers where else to look? I'm kinda lost at the moment :)
Oliver
On 09/10/12 19:28, Oliver Schinagl wrote:
On 09/10/12 16:29, Oliver Schinagl wrote:
On 10-09-12 13:46, Antti Palosaari wrote:
On 09/10/2012 12:58 PM, Oliver Schinagl wrote:
Changed the address as recommended, which after reading 7bit and
8bit
addressing makes perfect sense (drop the r/w bit and get the actual
address).
static struct fc2580_config af9035_fc2580_config = {
- .i2c_addr = 0xac,
+ .i2c_addr = 0x56,
.clock = 16384000,
};
So now the address should actually be correct ;)
Unfortunately, nothing. What other debug options do I need to
enable
besides CONFIG_DVB_USB_DEBUG to get more interesting output?
For me it sees something happens as there is no I2C error seen
anymore.
AF9035 driver uses Kernel dynamic debugs. CONFIG_DVB_USB_DEBUG is
legacy and proprietary DVB subsystem debug which should not be used
anymore.
You could order dynamic debugs like that:
modprobe dvb_usb_af9035; echo -n 'module dvb_usb_af9035 +p'
/sys/kernel/debug/dynamic_debug/control
For tuner, demod and dvb_usbv2 similarly if needed.
I've did and added output from control and dmesg output.
I don't exactly know how to read the dynamic debug output, the only
thing that jumped out at me, was:
drivers/media/dvb-frontends/af9033.c:327 [af9033]af9033_init =p %s:
unsupported tuner ID=%d\012
So I will search and see where in the driver the supported tunerID's
are
stored and fix that.
Any other pointers/things you see I should look at?
Appearantly, I setup the tuner, like the others, but it skips that
because the tuner id is wrong/not set.
case AF9033_TUNER_FC2580:
len = ARRAY_SIZE(tuner_init_fc2580);
init = tuner_init_fc2580;
break;
So where is the tuner set?
I did find this bit:
tatic int af9035_read_config(struct dvb_usb_device *d)
{
snip
ret = af9035_rd_reg(d, EEPROM_1_TUNER_ID + eeprom_shift,
tmp);
which suggests that it comes from the actual eeprom. I assumed that
the
'init/script/firmware' bit, the first 'message' was the ID, 0x32 in
the
case of this tuner. I guess I'm wrong?
The log is not exactly helpful either:
Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
On 09/17/2012 01:10 AM, Oliver Schinagl wrote: On 09/16/12 19:25, Antti Palosaari wrote: On 09/16/2012 06:03 PM, Oliver Schinagl wrote: I don't have windows, so capturing using windows is near impossible. Also since the vendor driver used to work, I guess I will have to dig into that more. You could capture data from Linux too (eg. Wireshark). Ah of course. I'll dig up the old vendor driver and see if I can get it running on 3.2 or better yet, on 3.5/your-3.6. I know there's patches for 3.2 but I've never tested those. Otherwise the older 2.6.2* series should still work. But with a little experience you could see those GPIOs reading existing Linux driver and then do some tests to see what happens. For example some GPIO powers tuner off, you will see I2C error. Changing it back error disappears. I have zero experience so I'll try to figure things out. I guess you currently turn on/off GPIO's etc in the current driver? Any line which does this so I can examine how it's done? As for the I2C errors, I suppose the current driver will spew those out? Those GPIOs are set in file af9035.c, functiuons: af9035_tuner_attach() and af9035_fc0011_tuner_callback(). For TDA18218 tuner there is no any GPIOs set, which could be wrong and it just works with good luck OR it is wired/connected directly so that GPIOs are not used at all. Speaking off, in my previous message, I wrote about the driver spitting out the following error: [dvb_usb_af9035]af9035_read_config =_ %s: [%d]tuner=%02x\012 It is the tuner ID value got from eeprom. You should take that number and add it to af9033.h file: #define AF9033_TUNER_FC25800x = insert number here None of the values where set however. Did I miss-configure anything for it to cause to 'forget' substituting? What you mean? Could you enable debugs, plug stick in and copy paste what debugs says? Since all the pieces should be there, fc2580 driver, af9033/5 driver, it's just a matter of glueing things together, right? I'll dig further into it and see what I can find/do. Correct. Tuner init (demod settings fc2580) for is needed for af9033. And GPIOs for AF9035. In very bad luck some changes for fc2580 is needed too, but it is not very, very, unlikely. This patch is very similar you will need to do (tda18218 tuner support for af9035): http://patchwork.linuxtv.org/patch/10547/ I re-did my patch using that as a template (before I used your work on the rtl) and got the exact result. Your rtl|fc2580 combo btw (from bare memory) didn't have the fc2580_init stream in af9033_priv.h. What exactly gets init-ed there? The af9033 to work with the fc2580? You have to add fc2580 init table to file af9033_priv.h. It configures all the settings needed for AF9033 demod in order to operate with FC2580 tuner. There is some values like tuner ID which is passed for AF9033 firmware, dunno what kind of tweaks it done. Maybe calculates some values like signal strengths and AGC values. It could work without, but at least performance is reduced. 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] [media] gscaler: mark it as BROKEN
Hi Mauro, On 2012년 09월 16일 00:38, Mauro Carvalho Chehab wrote: -EMISSINGMAKEFILE Without a Makefile, the driver will not compile, causing breakages for arm exynos5 sub-architecture. Cc: Shaik Ameer Basha shaik.am...@samsung.com Cc: Sungchun Kang sungchun.k...@samsung.com Cc: Seung-Woo Kim/Mobile S/W Platform Lab(DMC)/E4 sw0312@samsung.com Cc: Seung-Woo Kim sw0312@samsung.com is enough, but it is not big deal. Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- drivers/media/platform/Kconfig | 1 + drivers/media/platform/Makefile | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index 682594e..aa84d1d 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -184,6 +184,7 @@ config VIDEO_MX2_EMMAPRP config VIDEO_SAMSUNG_EXYNOS_GSC tristate Samsung Exynos G-Scaler driver depends on VIDEO_DEV VIDEO_V4L2 ARCH_EXYNOS5 + depends on BROKEN select VIDEOBUF2_DMA_CONTIG select V4L2_MEM2MEM_DEV help diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index baaa550..12d34c4 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -33,7 +33,9 @@ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_MFC) += s5p-mfc/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_TV) += s5p-tv/ obj-$(CONFIG_VIDEO_SAMSUNG_S5P_G2D) += s5p-g2d/ -obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/ + +# FIXME!!! This driver is broken, as there's no makefile there! +#obj-$(CONFIG_VIDEO_SAMSUNG_EXYNOS_GSC) += exynos-gsc/ obj-$(CONFIG_BLACKFIN) += blackfin/ Thanks and Regards, - Seung-Woo Kim -- Seung-Woo Kim Samsung Software RD Center -- -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] tua9001: enter full power save on attach
Disable RXEN and enable RESETN pins on attach to ensure chip is totally powered down after attach. Signed-off-by: Antti Palosaari cr...@iki.fi --- drivers/media/tuners/tua9001.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/media/tuners/tua9001.c b/drivers/media/tuners/tua9001.c index e6394fc..3896684 100644 --- a/drivers/media/tuners/tua9001.c +++ b/drivers/media/tuners/tua9001.c @@ -261,6 +261,16 @@ struct dvb_frontend *tua9001_attach(struct dvb_frontend *fe, TUA9001_CMD_CEN, 1); if (ret 0) goto err; + + ret = fe-callback(priv-i2c, DVB_FRONTEND_COMPONENT_TUNER, + TUA9001_CMD_RXEN, 0); + if (ret 0) + goto err; + + ret = fe-callback(priv-i2c, DVB_FRONTEND_COMPONENT_TUNER, + TUA9001_CMD_RESETN, 1); + if (ret 0) + goto err; } dev_info(priv-i2c-dev, -- 1.7.11.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] af9035: implement TUA9001 GPIOs correctly
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/af9035.c | 65 ++-
1 file changed, 48 insertions(+), 17 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/af9035.c
b/drivers/media/usb/dvb-usb-v2/af9035.c
index 89cc901..84b3b27 100644
--- a/drivers/media/usb/dvb-usb-v2/af9035.c
+++ b/drivers/media/usb/dvb-usb-v2/af9035.c
@@ -583,6 +583,52 @@ err:
return ret;
}
+static int af9035_tua9001_tuner_callback(struct dvb_usb_device *d,
+ int cmd, int arg)
+{
+ int ret;
+ u8 val;
+
+ dev_dbg(d-udev-dev, %s: cmd=%d arg=%d\n, __func__, cmd, arg);
+
+ /*
+* CEN always enabled by hardware wiring
+* RESETN GPIOT3
+* RXENGPIOT2
+*/
+
+ switch (cmd) {
+ case TUA9001_CMD_RESETN:
+ if (arg)
+ val = 0x00;
+ else
+ val = 0x01;
+
+ ret = af9035_wr_reg_mask(d, 0x00d8e7, val, 0x01);
+ if (ret 0)
+ goto err;
+ break;
+ case TUA9001_CMD_RXEN:
+ if (arg)
+ val = 0x01;
+ else
+ val = 0x00;
+
+ ret = af9035_wr_reg_mask(d, 0x00d8eb, val, 0x01);
+ if (ret 0)
+ goto err;
+ break;
+ }
+
+ return 0;
+
+err:
+ dev_dbg(d-udev-dev, %s: failed=%d\n, __func__, ret);
+
+ return ret;
+}
+
+
static int af9035_fc0011_tuner_callback(struct dvb_usb_device *d,
int cmd, int arg)
{
@@ -655,6 +701,8 @@ static int af9035_tuner_callback(struct dvb_usb_device *d,
int cmd, int arg)
switch (state-af9033_config[0].tuner) {
case AF9033_TUNER_FC0011:
return af9035_fc0011_tuner_callback(d, cmd, arg);
+ case AF9033_TUNER_TUA9001:
+ return af9035_tua9001_tuner_callback(d, cmd, arg);
default:
break;
}
@@ -779,23 +827,6 @@ static int af9035_tuner_attach(struct dvb_usb_adapter
*adap)
if (ret 0)
goto err;
- /* reset tuner */
- ret = af9035_wr_reg_mask(d, 0x00d8e7, 0x00, 0x01);
- if (ret 0)
- goto err;
-
- usleep_range(2000, 2);
-
- ret = af9035_wr_reg_mask(d, 0x00d8e7, 0x01, 0x01);
- if (ret 0)
- goto err;
-
- /* activate tuner RX */
- /* TODO: use callback for TUA9001 RXEN */
- ret = af9035_wr_reg_mask(d, 0x00d8eb, 0x01, 0x01);
- if (ret 0)
- goto err;
-
/* attach tuner */
fe = dvb_attach(tua9001_attach, adap-fe[0],
d-i2c_adap, af9035_tua9001_config);
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] af9033: sleep on attach
This reduces power consumption 10mA.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/dvb-frontends/af9033.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/dvb-frontends/af9033.c
b/drivers/media/dvb-frontends/af9033.c
index 0979ada..56e9611 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -909,6 +909,15 @@ struct dvb_frontend *af9033_attach(const struct
af9033_config *config,
OFDM=%d.%d.%d.%d\n, KBUILD_MODNAME, buf[0], buf[1],
buf[2], buf[3], buf[4], buf[5], buf[6], buf[7]);
+ /* sleep */
+ ret = af9033_wr_reg(state, 0x80004c, 1);
+ if (ret 0)
+ goto err;
+
+ ret = af9033_wr_reg(state, 0x80, 0);
+ if (ret 0)
+ goto err;
+
/* configure internal TS mode */
switch (state-cfg.ts_mode) {
case AF9033_TS_MODE_PARALLEL:
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/34] i.MX multi-platform support
The series enables multi-platform support for imx. Since the required
frameworks (clk, pwm) and spare_irq have already been adopted on imx,
the series is all about cleaning up mach/* headers. Along with the
changes, arch/arm/plat-mxc gets merged into arch/arm/mach-imx.
It's based on a bunch of branches (works from others), Rob's initial
multi-platform series, Arnd's platform-data and smp_ops (Marc's) and
imx 3.7 material (Sascha and myself).
It's available on branch below.
git://git.linaro.org/people/shawnguo/linux-2.6.git imx/multi-platform
It's been tested on imx5 and imx6, and only compile-tested on imx2 and
imx3, so testing on imx2/3 are appreciated.
Subsystem maintainers,
I plan to send the whole series via arm-soc tree at the end of 3.7
merge window when all dependant bits hit mainline. Please have a
look at the patches you get copied and provide ACKs if the changes
are good. Thanks.
Shawn Guo (34):
ARM: imx: include board headers in the same folder
ASoC: mx27vis: retrieve gpio numbers from platform_data
ARM: imx: move iomux drivers and headers into mach-imx
ARM: imx: remove unnecessary inclusion from device-imx*.h
ARM: imx: move platform device code into mach-imx
ARM: imx: merge plat-mxc into mach-imx
ARM: imx: include common.h rather than mach/common.h
ARM: imx: ARM: imx: include cpuidle.h rather than mach/cpuidle.h
ARM: imx: include iim.h rather than mach/iim.h
ARM: imx: include iram.h rather than mach/iram.h
ARM: imx: include ulpi.h rather than mach/ulpi.h
media: mx1_camera: remove the driver
ARM: imx: remove mach/dma-mx1-mx2.h
dma: ipu: rename mach/ipu.h to include/linux/dma/ipu-dma.h
dma: imx-sdma: remove unneeded mach/hardware.h inclusion
ASoC: imx-ssi: remove unneeded mach/hardware.h inclusion
usb: ehci-mxc: remove unneeded mach/hardware.h inclusion
video: mx3fb: remove unneeded mach/hardware.h inclusion
watchdog: imx2_wdt: remove unneeded mach/hardware.h inclusion
i2c: imx: remove mach/hardware.h inclusion
mtd: mxc_nand: remove mach/hardware.h inclusion
rtc: mxc_rtc: remove mach/hardware.h inclusion
dma: imx-dma: use devm_kzalloc and devm_request_irq
dma: imx-dma: retrieve MEM and IRQ from resources
dma: imx-dma: remove mach/hardware.h inclusion
media: mx2_camera: remove dead code in mx2_camera_add_device
media: mx2_camera: use managed functions to clean up code
media: mx2_camera: remove mach/hardware.h inclusion
mmc: mxcmmc: remove mach/hardware.h inclusion
video: imxfb: remove mach/hardware.h inclusion
ARM: imx: move debug macros to include/debug
ARM: imx: include hardware.h rather than mach/hardware.h
ARM: imx: remove header file mach/irqs.h
ARM: imx: enable multi-platform build
.../devicetree/bindings/i2c/fsl-imx-i2c.txt|4 +-
arch/arm/Kconfig | 15 +-
arch/arm/Kconfig.debug |8 +
arch/arm/Makefile |1 -
arch/arm/boot/dts/imx27.dtsi |4 +-
arch/arm/boot/dts/imx51.dtsi |4 +-
arch/arm/boot/dts/imx53.dtsi |6 +-
arch/arm/boot/dts/imx6q.dtsi |6 +-
.../mach/debug-macro.S = include/debug/imx.S} | 33 +-
arch/arm/{plat-mxc = mach-imx}/3ds_debugboard.c |2 +-
.../include/mach = mach-imx}/3ds_debugboard.h |0
arch/arm/mach-imx/Kconfig | 86 ++
arch/arm/mach-imx/Makefile | 23 +-
arch/arm/{plat-mxc = mach-imx}/avic.c |5 +-
.../include/mach = mach-imx}/board-mx31lilly.h|0
.../include/mach = mach-imx}/board-mx31lite.h |0
.../include/mach = mach-imx}/board-mx31moboard.h |0
.../include/mach = mach-imx}/board-pcm038.h |0
arch/arm/mach-imx/clk-imx1.c | 15 +-
arch/arm/mach-imx/clk-imx21.c | 14 +-
arch/arm/mach-imx/clk-imx25.c | 26 +-
arch/arm/mach-imx/clk-imx27.c | 36 +-
arch/arm/mach-imx/clk-imx31.c | 21 +-
arch/arm/mach-imx/clk-imx35.c | 13 +-
arch/arm/mach-imx/clk-imx51-imx53.c| 15 +-
arch/arm/mach-imx/clk-imx6q.c |3 +-
arch/arm/mach-imx/clk-pllv1.c |4 +-
.../{plat-mxc/include/mach = mach-imx}/common.h |0
arch/arm/mach-imx/cpu-imx25.c |5 +-
arch/arm/mach-imx/cpu-imx27.c |2 +-
arch/arm/mach-imx/cpu-imx31.c |7 +-
arch/arm/mach-imx/cpu-imx35.c |5 +-
arch/arm/mach-imx/cpu-imx5.c |3 +-
arch/arm/{plat-mxc = mach-imx}/cpu.c |3 +-
arch/arm/mach-imx/cpu_op-mx51.c|3 +-
arch/arm/{plat-mxc = mach-imx}/cpufreq.c |3 +-
arch/arm/{plat-mxc = mach-imx}/cpuidle.c |0
[PATCH 12/34] media: mx1_camera: remove the driver
The mx1_camera driver has been broken for a few release cycles since
commit 6bd0812 (dmaengine: imx-dma: merge old dma-v1.c with imx-dma.c).
It seems there is no one even compile tested it since then, as doing
so will end up with the following error.
CC drivers/media/video/mx1_camera.o
In file included from drivers/media/video/mx1_camera.c:44:0:
arch/arm/mach-imx/include/mach/dma-mx1-mx2.h:8:25: fatal error: mach/dma-v1.h:
No such file or directory
It looks that all the related folks have known the breakage [1], but
no one shows the interest to bring it back to work. Thus it becomes
a piece of unmaintained code, so let's remove it.
[1] https://lkml.org/lkml/2012/2/9/171
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Paulius Zaleckas paulius.zalec...@teltonika.lt
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: linux-media@vger.kernel.org
---
arch/arm/mach-imx/Makefile |3 -
arch/arm/mach-imx/clk-imx1.c|1 -
arch/arm/mach-imx/devices/Kconfig |3 -
arch/arm/mach-imx/devices/Makefile |1 -
arch/arm/mach-imx/devices/devices-common.h | 10 -
arch/arm/mach-imx/devices/platform-mx1-camera.c | 42 --
arch/arm/mach-imx/mx1-camera-fiq-ksym.c | 18 -
arch/arm/mach-imx/mx1-camera-fiq.S | 35 -
drivers/media/video/Kconfig | 12 -
drivers/media/video/Makefile|1 -
drivers/media/video/mx1_camera.c| 889 ---
include/linux/platform_data/camera-mx1.h| 35 -
12 files changed, 1050 deletions(-)
delete mode 100644 arch/arm/mach-imx/devices/platform-mx1-camera.c
delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq-ksym.c
delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq.S
delete mode 100644 drivers/media/video/mx1_camera.c
delete mode 100644 include/linux/platform_data/camera-mx1.h
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index fe47b71..538d0ee 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -35,9 +35,6 @@ obj-y += ssi-fiq.o
obj-y += ssi-fiq-ksym.o
endif
-# Support for CMOS sensor interface
-obj-$(CONFIG_MX1_VIDEO) += mx1-camera-fiq.o mx1-camera-fiq-ksym.o
-
# i.MX1 based machines
obj-$(CONFIG_ARCH_MX1ADS) += mach-mx1ads.o
obj-$(CONFIG_MACH_SCB9328) += mach-scb9328.o
diff --git a/arch/arm/mach-imx/clk-imx1.c b/arch/arm/mach-imx/clk-imx1.c
index b5f90cc..ebfffd2 100644
--- a/arch/arm/mach-imx/clk-imx1.c
+++ b/arch/arm/mach-imx/clk-imx1.c
@@ -84,7 +84,6 @@ int __init mx1_clocks_init(unsigned long fref)
i, PTR_ERR(clk[i]));
clk_register_clkdev(clk[dma_gate], ahb, imx-dma);
- clk_register_clkdev(clk[csi_gate], NULL, mx1-camera.0);
clk_register_clkdev(clk[mma_gate], mma, NULL);
clk_register_clkdev(clk[usbd_gate], NULL, imx_udc.0);
clk_register_clkdev(clk[per1], per, imx-gpt.0);
diff --git a/arch/arm/mach-imx/devices/Kconfig
b/arch/arm/mach-imx/devices/Kconfig
index cb3e3ee..09d796e 100644
--- a/arch/arm/mach-imx/devices/Kconfig
+++ b/arch/arm/mach-imx/devices/Kconfig
@@ -46,9 +46,6 @@ config IMX_HAVE_PLATFORM_IMX_UDC
config IMX_HAVE_PLATFORM_IPU_CORE
bool
-config IMX_HAVE_PLATFORM_MX1_CAMERA
- bool
-
config IMX_HAVE_PLATFORM_MX2_CAMERA
bool
diff --git a/arch/arm/mach-imx/devices/Makefile
b/arch/arm/mach-imx/devices/Makefile
index ff22ed1..3cfdc37 100644
--- a/arch/arm/mach-imx/devices/Makefile
+++ b/arch/arm/mach-imx/devices/Makefile
@@ -17,7 +17,6 @@ obj-$(CONFIG_IMX_HAVE_PLATFORM_IMX_SSI) += platform-imx-ssi.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_IMX_UART) += platform-imx-uart.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_IMX_UDC) += platform-imx_udc.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_IPU_CORE) += platform-ipu-core.o
-obj-$(CONFIG_IMX_HAVE_PLATFORM_MX1_CAMERA) += platform-mx1-camera.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_MX2_CAMERA) += platform-mx2-camera.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_EHCI) += platform-mxc-ehci.o
obj-$(CONFIG_IMX_HAVE_PLATFORM_MXC_MMC) += platform-mxc-mmc.o
diff --git a/arch/arm/mach-imx/devices/devices-common.h
b/arch/arm/mach-imx/devices/devices-common.h
index 9e3e3d8..34419b2 100644
--- a/arch/arm/mach-imx/devices/devices-common.h
+++ b/arch/arm/mach-imx/devices/devices-common.h
@@ -199,16 +199,6 @@ struct platform_device *__init imx_add_mx3_sdc_fb(
const struct imx_ipu_core_data *data,
struct mx3fb_platform_data *pdata);
-#include linux/platform_data/camera-mx1.h
-struct imx_mx1_camera_data {
- resource_size_t iobase;
- resource_size_t iosize;
- resource_size_t irq;
-};
-struct platform_device *__init imx_add_mx1_camera(
- const struct imx_mx1_camera_data *data,
- const struct mx1_camera_pdata *pdata);
-
#include linux/platform_data/camera-mx2.h
struct imx_mx2_camera_data {
resource_size_t iobasecsi;
diff --git
[PATCH 14/34] dma: ipu: rename mach/ipu.h to include/linux/dma/ipu-dma.h
The header ipu.h really belongs to dma subsystem rather than imx
platform. Rename it to ipu-dma.h and put it into include/linux/dma/.
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Vinod Koul vinod.k...@intel.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Florian Tobias Schandinat florianschandi...@gmx.de
Cc: linux-media@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
---
drivers/dma/ipu/ipu_idmac.c|3 +--
drivers/dma/ipu/ipu_irq.c |3 +--
drivers/media/video/mx3_camera.c |2 +-
drivers/video/mx3fb.c |2 +-
.../mach/ipu.h = include/linux/dma/ipu-dma.h |6 +++---
5 files changed, 7 insertions(+), 9 deletions(-)
rename arch/arm/mach-imx/include/mach/ipu.h = include/linux/dma/ipu-dma.h
(97%)
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index c7573e5..6585537 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -22,8 +22,7 @@
#include linux/interrupt.h
#include linux/io.h
#include linux/module.h
-
-#include mach/ipu.h
+#include linux/dma/ipu-dma.h
#include ../dmaengine.h
#include ipu_intern.h
diff --git a/drivers/dma/ipu/ipu_irq.c b/drivers/dma/ipu/ipu_irq.c
index fa95bcc..a5ee37d 100644
--- a/drivers/dma/ipu/ipu_irq.c
+++ b/drivers/dma/ipu/ipu_irq.c
@@ -15,8 +15,7 @@
#include linux/irq.h
#include linux/io.h
#include linux/module.h
-
-#include mach/ipu.h
+#include linux/dma/ipu-dma.h
#include ipu_intern.h
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index 1481b0d..892cba5 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -17,6 +17,7 @@
#include linux/vmalloc.h
#include linux/interrupt.h
#include linux/sched.h
+#include linux/dma/ipu-dma.h
#include media/v4l2-common.h
#include media/v4l2-dev.h
@@ -24,7 +25,6 @@
#include media/soc_camera.h
#include media/soc_mediabus.h
-#include mach/ipu.h
#include linux/platform_data/camera-mx3.h
#include linux/platform_data/dma-imx.h
diff --git a/drivers/video/mx3fb.c b/drivers/video/mx3fb.c
index d738108..3b63ad8 100644
--- a/drivers/video/mx3fb.c
+++ b/drivers/video/mx3fb.c
@@ -26,10 +26,10 @@
#include linux/console.h
#include linux/clk.h
#include linux/mutex.h
+#include linux/dma/ipu-dma.h
#include linux/platform_data/dma-imx.h
#include mach/hardware.h
-#include mach/ipu.h
#include linux/platform_data/video-mx3fb.h
#include asm/io.h
diff --git a/arch/arm/mach-imx/include/mach/ipu.h b/include/linux/dma/ipu-dma.h
similarity index 97%
rename from arch/arm/mach-imx/include/mach/ipu.h
rename to include/linux/dma/ipu-dma.h
index 539e559..1803111 100644
--- a/arch/arm/mach-imx/include/mach/ipu.h
+++ b/include/linux/dma/ipu-dma.h
@@ -9,8 +9,8 @@
* published by the Free Software Foundation.
*/
-#ifndef _IPU_H_
-#define _IPU_H_
+#ifndef __LINUX_DMA_IPU_DMA_H
+#define __LINUX_DMA_IPU_DMA_H
#include linux/types.h
#include linux/dmaengine.h
@@ -174,4 +174,4 @@ struct idmac_channel {
#define to_tx_desc(tx) container_of(tx, struct idmac_tx_desc, txd)
#define to_idmac_chan(c) container_of(c, struct idmac_channel, dma_chan)
-#endif
+#endif /* __LINUX_DMA_IPU_DMA_H */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 26/34] media: mx2_camera: remove dead code in mx2_camera_add_device
This is a piece of code becoming dead since commit 2c9ba37 ([media]
V4L: mx2_camera: remove unsupported i.MX27 DMA mode, make EMMA
mandatory). It should have been removed together with the commit.
Remove it now.
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: linux-media@vger.kernel.org
---
drivers/media/video/mx2_camera.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 965427f..89c7e28 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -441,11 +441,9 @@ static int mx2_camera_add_device(struct soc_camera_device
*icd)
csicr1 = CSICR1_MCLKEN;
- if (cpu_is_mx27()) {
+ if (cpu_is_mx27())
csicr1 |= CSICR1_PRP_IF_EN | CSICR1_FCC |
CSICR1_RXFF_LEVEL(0);
- } else if (cpu_is_mx27())
- csicr1 |= CSICR1_SOF_INTEN | CSICR1_RXFF_LEVEL(2);
pcdev-csicr1 = csicr1;
writel(pcdev-csicr1, pcdev-base_csi + CSICR1);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 27/34] media: mx2_camera: use managed functions to clean up code
Use managed functions to clean up the error handling code and function
mx2_camera_remove(). Along with the change, a few variables get removed
from struct mx2_camera_dev.
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: linux-media@vger.kernel.org
---
drivers/media/video/mx2_camera.c | 143 +++---
1 file changed, 39 insertions(+), 104 deletions(-)
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index 89c7e28..fe4c76c 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -274,12 +274,9 @@ struct mx2_camera_dev {
struct soc_camera_device *icd;
struct clk *clk_csi, *clk_emma_ahb, *clk_emma_ipg;
- unsigned intirq_csi, irq_emma;
void __iomem*base_csi, *base_emma;
- unsigned long base_dma;
struct mx2_camera_platform_data *pdata;
- struct resource *res_csi, *res_emma;
unsigned long platform_flags;
struct list_headcapture;
@@ -1607,64 +1604,59 @@ static irqreturn_t mx27_camera_emma_irq(int irq_emma,
void *data)
return IRQ_HANDLED;
}
-static int __devinit mx27_camera_emma_init(struct mx2_camera_dev *pcdev)
+static int __devinit mx27_camera_emma_init(struct platform_device *pdev)
{
- struct resource *res_emma = pcdev-res_emma;
+ struct mx2_camera_dev *pcdev = platform_get_drvdata(pdev);
+ struct resource *res_emma;
+ int irq_emma;
int err = 0;
- if (!request_mem_region(res_emma-start, resource_size(res_emma),
- MX2_CAM_DRV_NAME)) {
- err = -EBUSY;
+ res_emma = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ irq_emma = platform_get_irq(pdev, 1);
+ if (!res_emma || !irq_emma) {
+ dev_err(pcdev-dev, no EMMA resources\n);
goto out;
}
- pcdev-base_emma = ioremap(res_emma-start, resource_size(res_emma));
+ pcdev-base_emma = devm_request_and_ioremap(pcdev-dev, res_emma);
if (!pcdev-base_emma) {
- err = -ENOMEM;
- goto exit_release;
+ err = -EADDRNOTAVAIL;
+ goto out;
}
- err = request_irq(pcdev-irq_emma, mx27_camera_emma_irq, 0,
- MX2_CAM_DRV_NAME, pcdev);
+ err = devm_request_irq(pcdev-dev, irq_emma, mx27_camera_emma_irq, 0,
+ MX2_CAM_DRV_NAME, pcdev);
if (err) {
dev_err(pcdev-dev, Camera EMMA interrupt register failed \n);
- goto exit_iounmap;
+ goto out;
}
- pcdev-clk_emma_ipg = clk_get(pcdev-dev, emma-ipg);
+ pcdev-clk_emma_ipg = devm_clk_get(pcdev-dev, emma-ipg);
if (IS_ERR(pcdev-clk_emma_ipg)) {
err = PTR_ERR(pcdev-clk_emma_ipg);
- goto exit_free_irq;
+ goto out;
}
clk_prepare_enable(pcdev-clk_emma_ipg);
- pcdev-clk_emma_ahb = clk_get(pcdev-dev, emma-ahb);
+ pcdev-clk_emma_ahb = devm_clk_get(pcdev-dev, emma-ahb);
if (IS_ERR(pcdev-clk_emma_ahb)) {
err = PTR_ERR(pcdev-clk_emma_ahb);
- goto exit_clk_emma_ipg_put;
+ goto exit_clk_emma_ipg;
}
clk_prepare_enable(pcdev-clk_emma_ahb);
err = mx27_camera_emma_prp_reset(pcdev);
if (err)
- goto exit_clk_emma_ahb_put;
+ goto exit_clk_emma_ahb;
return err;
-exit_clk_emma_ahb_put:
+exit_clk_emma_ahb:
clk_disable_unprepare(pcdev-clk_emma_ahb);
- clk_put(pcdev-clk_emma_ahb);
-exit_clk_emma_ipg_put:
+exit_clk_emma_ipg:
clk_disable_unprepare(pcdev-clk_emma_ipg);
- clk_put(pcdev-clk_emma_ipg);
-exit_free_irq:
- free_irq(pcdev-irq_emma, pcdev);
-exit_iounmap:
- iounmap(pcdev-base_emma);
-exit_release:
- release_mem_region(res_emma-start, resource_size(res_emma));
out:
return err;
}
@@ -1672,9 +1664,8 @@ out:
static int __devinit mx2_camera_probe(struct platform_device *pdev)
{
struct mx2_camera_dev *pcdev;
- struct resource *res_csi, *res_emma;
- void __iomem *base_csi;
- int irq_csi, irq_emma;
+ struct resource *res_csi;
+ int irq_csi;
int err = 0;
dev_dbg(pdev-dev, initialising\n);
@@ -1687,21 +1678,20 @@ static int __devinit mx2_camera_probe(struct
platform_device *pdev)
goto exit;
}
- pcdev = kzalloc(sizeof(*pcdev), GFP_KERNEL);
+ pcdev = devm_kzalloc(pdev-dev, sizeof(*pcdev), GFP_KERNEL);
if (!pcdev) {
dev_err(pdev-dev, Could not allocate pcdev\n);
err = -ENOMEM;
goto exit;
}
- pcdev-clk_csi = clk_get(pdev-dev, ahb);
+ pcdev-clk_csi = devm_clk_get(pdev-dev, ahb);
if
[PATCH 28/34] media: mx2_camera: remove mach/hardware.h inclusion
It changes the driver to use platform_device_id rather than cpu_is_xxx
to determine the controller type, and updates the platform code
accordingly.
As the result, mach/hardware.h inclusion gets removed from the driver.
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: linux-media@vger.kernel.org
---
arch/arm/mach-imx/clk-imx25.c |6 +-
arch/arm/mach-imx/clk-imx27.c |6 +-
arch/arm/mach-imx/devices/devices-common.h |1 +
arch/arm/mach-imx/devices/platform-mx2-camera.c | 12 +--
drivers/media/video/mx2_camera.c| 95 +--
5 files changed, 85 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c
index 1aea073..71fe521 100644
--- a/arch/arm/mach-imx/clk-imx25.c
+++ b/arch/arm/mach-imx/clk-imx25.c
@@ -231,9 +231,9 @@ int __init mx25_clocks_init(void)
clk_register_clkdev(clk[esdhc2_ipg_per], per, sdhci-esdhc-imx25.1);
clk_register_clkdev(clk[esdhc2_ipg], ipg, sdhci-esdhc-imx25.1);
clk_register_clkdev(clk[esdhc2_ahb], ahb, sdhci-esdhc-imx25.1);
- clk_register_clkdev(clk[csi_ipg_per], per, mx2-camera.0);
- clk_register_clkdev(clk[csi_ipg], ipg, mx2-camera.0);
- clk_register_clkdev(clk[csi_ahb], ahb, mx2-camera.0);
+ clk_register_clkdev(clk[csi_ipg_per], per, imx25-camera.0);
+ clk_register_clkdev(clk[csi_ipg], ipg, imx25-camera.0);
+ clk_register_clkdev(clk[csi_ahb], ahb, imx25-camera.0);
clk_register_clkdev(clk[dummy], audmux, NULL);
clk_register_clkdev(clk[can1_ipg], NULL, flexcan.0);
clk_register_clkdev(clk[can2_ipg], NULL, flexcan.1);
diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index 5ff5cf0..e26de52 100644
--- a/arch/arm/mach-imx/clk-imx27.c
+++ b/arch/arm/mach-imx/clk-imx27.c
@@ -224,7 +224,7 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[per3_gate], per, imx-fb.0);
clk_register_clkdev(clk[lcdc_ipg_gate], ipg, imx-fb.0);
clk_register_clkdev(clk[lcdc_ahb_gate], ahb, imx-fb.0);
- clk_register_clkdev(clk[csi_ahb_gate], ahb, mx2-camera.0);
+ clk_register_clkdev(clk[csi_ahb_gate], ahb, imx27-camera.0);
clk_register_clkdev(clk[usb_div], per, fsl-usb2-udc);
clk_register_clkdev(clk[usb_ipg_gate], ipg, fsl-usb2-udc);
clk_register_clkdev(clk[usb_ahb_gate], ahb, fsl-usb2-udc);
@@ -251,8 +251,8 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[i2c2_ipg_gate], NULL, imx21-i2c.1);
clk_register_clkdev(clk[owire_ipg_gate], NULL, mxc_w1.0);
clk_register_clkdev(clk[kpp_ipg_gate], NULL, imx-keypad);
- clk_register_clkdev(clk[emma_ahb_gate], emma-ahb, mx2-camera.0);
- clk_register_clkdev(clk[emma_ipg_gate], emma-ipg, mx2-camera.0);
+ clk_register_clkdev(clk[emma_ahb_gate], emma-ahb, imx27-camera.0);
+ clk_register_clkdev(clk[emma_ipg_gate], emma-ipg, imx27-camera.0);
clk_register_clkdev(clk[emma_ahb_gate], ahb, m2m-emmaprp.0);
clk_register_clkdev(clk[emma_ipg_gate], ipg, m2m-emmaprp.0);
clk_register_clkdev(clk[iim_ipg_gate], iim, NULL);
diff --git a/arch/arm/mach-imx/devices/devices-common.h
b/arch/arm/mach-imx/devices/devices-common.h
index 7f2698c..8112a1a 100644
--- a/arch/arm/mach-imx/devices/devices-common.h
+++ b/arch/arm/mach-imx/devices/devices-common.h
@@ -202,6 +202,7 @@ struct platform_device *__init imx_add_mx3_sdc_fb(
#include linux/platform_data/camera-mx2.h
struct imx_mx2_camera_data {
+ const char *devid;
resource_size_t iobasecsi;
resource_size_t iosizecsi;
resource_size_t irqcsi;
diff --git a/arch/arm/mach-imx/devices/platform-mx2-camera.c
b/arch/arm/mach-imx/devices/platform-mx2-camera.c
index 9ad5b2d..b88877d 100644
--- a/arch/arm/mach-imx/devices/platform-mx2-camera.c
+++ b/arch/arm/mach-imx/devices/platform-mx2-camera.c
@@ -9,14 +9,16 @@
#include mach/hardware.h
#include devices-common.h
-#define imx_mx2_camera_data_entry_single(soc) \
+#define imx_mx2_camera_data_entry_single(soc, _devid) \
{ \
+ .devid = _devid,\
.iobasecsi = soc ## _CSI_BASE_ADDR, \
.iosizecsi = SZ_4K, \
.irqcsi = soc ## _INT_CSI, \
}
-#define imx_mx2_camera_data_entry_single_emma(soc) \
+#define imx_mx2_camera_data_entry_single_emma(soc, _devid) \
{ \
+ .devid = _devid,\
.iobasecsi = soc ## _CSI_BASE_ADDR, \
