RE: Setting up a GIT repository on linuxtv.org
>Andy Walls wrote: >Hi, > >I'm a GIT idiot, so I need a little help on getting a properly setup >repo at linuxtv.org. Can someone tell me if this is the right >procedure: > >$ ssh -t awa...@linuxtv.org git-menu >(clone linux-2.6.git naming it v4l-dvb <-- Is this right?) >$ git clone \ > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \ >v4l-dvb If I understand correctly, you won't be working on that repository directly (i.e. no working directory on the linuxtv server, only push/fetch(pull), and the actual work on your local machine), you should make it a bare repository by passing a --bare option to clone. Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D 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
Re: Setting up a GIT repository on linuxtv.org
Hi Pawel, On Monday 24 May 2010 09:08:51 Pawel Osciak wrote: > >Andy Walls wrote: > >Hi, > > > >I'm a GIT idiot, so I need a little help on getting a properly setup > >repo at linuxtv.org. Can someone tell me if this is the right > >procedure: > > > >$ ssh -t awa...@linuxtv.org git-menu > > > >(clone linux-2.6.git naming it v4l-dvb <-- Is this right?) > > > >$ git clone \ > > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \ > > > >v4l-dvb > > If I understand correctly, you won't be working on that repository directly > (i.e. no working directory on the linuxtv server, only push/fetch(pull), > and the actual work on your local machine), you should make it a bare > repository by passing a --bare option to clone. There's a slight misunderstanding here. The ssh command runs the git-menu application on the server. It doesn't open an interactive shell. The git clone command is then run locally, where a working directory is needed. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Setting up a GIT repository on linuxtv.org
Hi Laurent, >Laurent Pinchart wrote: >On Monday 24 May 2010 09:08:51 Pawel Osciak wrote: >> >Andy Walls wrote: >> >Hi, >> > >> >I'm a GIT idiot, so I need a little help on getting a properly setup >> >repo at linuxtv.org. Can someone tell me if this is the right >> >procedure: >> > >> >$ ssh -t awa...@linuxtv.org git-menu >> > >> >(clone linux-2.6.git naming it v4l-dvb <-- Is this right?) >> > >> >$ git clone \ >> > >> >git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \ >> > >> >v4l-dvb >> >> If I understand correctly, you won't be working on that repository directly >> (i.e. no working directory on the linuxtv server, only push/fetch(pull), >> and the actual work on your local machine), you should make it a bare >> repository by passing a --bare option to clone. > >There's a slight misunderstanding here. The ssh command runs the git-menu >application on the server. It doesn't open an interactive shell. The git >clone >command is then run locally, where a working directory is needed. Ah, I though the clone was executed remotely as well. Please ignore my post then and thanks to Laurent for noticing :) Best regards -- Pawel Osciak Linux Platform Group Samsung Poland R&D 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
Re: [PATCH 03/15] [RFCv2] Documentation: add v4l2-controls.txt documenting the new controls API.
Hi Laurent,
Thanks for your review! As always, it was very useful.
On Monday 24 May 2010 01:17:34 Laurent Pinchart wrote:
> Hi Hans,
>
> Thanks for the second RFC version. I've finally had time to review it. Many
> issues from the first version have been fixed, but there are some left (or at
> least topics that are still open for discussion). Here are my comments.
>
> On Sunday 16 May 2010 15:20:57 Hans Verkuil wrote:
> > Signed-off-by: Hans Verkuil
> > Reviewed-by: Laurent Pinchart
> > ---
> > Documentation/video4linux/v4l2-controls.txt | 600
> > +++ 1 files changed, 600 insertions(+), 0
> > deletions(-)
> > create mode 100644 Documentation/video4linux/v4l2-controls.txt
> >
> > diff --git a/Documentation/video4linux/v4l2-controls.txt
> > b/Documentation/video4linux/v4l2-controls.txt new file mode 100644
> > index 000..44246b2
> > --- /dev/null
> > +++ b/Documentation/video4linux/v4l2-controls.txt
> > @@ -0,0 +1,600 @@
> > +Introduction
> > +
> > +
> > +The V4L2 control API seems simple enough, but quickly becomes very hard to
> > +implement correctly in drivers. But much of the code needed to handle
> > controls
> > +is actually not driver specific and can be moved to the V4L core framework.
> > +
> > +After all, the only part that a driver developer is interested in is:
> > +
> > +1) How do I add a control?
> > +2) How do I set the control's value? (i.e. s_ctrl)
> > +
> > +And occasionally:
> > +
> > +3) How do I get the control's value? (i.e. g_volatile_ctrl)
> > +4) How do I validate the user's proposed control value? (i.e. try_ctrl)
> > +
> > +All the rest is something that can be done centrally.
> > +
> > +The control framework was created in order to implement all the rules of
> > the
> > +V4L2 specification with respect to controls in a central place. And to make
> > +life as easy as possible for the driver developer.
> > +
> > +Note that the control framework relies on the presence of a struct
> > v4l2_device
> > +for bridge drivers and struct v4l2_subdev for sub-device drivers.
>
> Didn't we agree on replacing the name bridge by something else ? "bridges"
> are
> a subset of the V4L2 devices.
What is a good name for such drivers? V4L2 drivers?
> > +Objects in the framework
> > +
> > +
> > +There are two main objects:
> > +
> > +The v4l2_ctrl object describes the control properties and keeps track of
> > the
> > +control's value (both the current value and the proposed new value).
> > +
> > +v4l2_ctrl_handler is the object that keeps track of controls. It maintains
> > a
> > +list of v4l2_ctrl objects that it owns and another list of references to
> > +controls, possibly to controls owned by other handlers.
> > +
> > +
> > +Basic usage for bridge and sub-device drivers
> > +=
> > +
> > +1) Prepare the driver:
> > +
> > +1.1) Add the handler to your driver's top-level struct:
> > +
> > + struct foo_dev {
> > + ...
> > + struct v4l2_ctrl_handler ctrl_handler;
> > + ...
> > + };
> > +
> > + struct foo_dev *foo;
> > +
> > +1.2) Initialize the handler:
> > +
> > + v4l2_ctrl_handler_init(&foo->ctrl_handler, nr_of_controls);
> > +
> > + The second argument is a hint telling the function how many controls
> > this
> > + handler is expected to handle. It will allocate a hashtable based on this
> > + information. It is a hint only.
> > +
> > +1.3) Hook the control handler into the driver:
> > +
> > +1.3.1) For bridge drivers do this:
> > +
> > + foo->v4l2_dev.ctrl_handler = &foo->ctrl_handler;
> > +
> > + Where foo->v4l2_dev is of type struct v4l2_device.
>
> Please add struct v4l2_device v4l2_dev in the foo_dev structure above.
Will do.
>
> > + Finally, remove all control functions from your v4l2_ioctl_ops:
> > + vidioc_queryctrl, vidioc_querymenu, vidioc_g_ctrl, vidioc_s_ctrl,
> > + vidioc_g_ext_ctrls, vidioc_try_ext_ctrls and vidioc_s_ext_ctrls.
> > + Those are now no longer needed.
> > +
> > +1.3.2) For sub-device drivers do this:
> > +
> > + foo->sd.ctrl_handler = &foo->ctrl_handler;
> > +
> > + Where foo->sd is of type struct v4l2_subdev.
> > +
> > + And set all core control ops in your struct v4l2_subdev_core_ops to
> > these
> > + helpers:
> > +
> > + .queryctrl = v4l2_subdev_queryctrl,
> > + .querymenu = v4l2_subdev_querymenu,
> > + .g_ctrl = v4l2_subdev_g_ctrl,
> > + .s_ctrl = v4l2_subdev_s_ctrl,
> > + .g_ext_ctrls = v4l2_subdev_g_ext_ctrls,
> > + .try_ext_ctrls = v4l2_subdev_try_ext_ctrls,
> > + .s_ext_ctrls = v4l2_subdev_s_ext_ctrls,
> > +
> > + Note: this is a temporary solution only. Once everything is converted to
> > + the control framework these helpers will no longer be needed.
>
> If I understand things properly, those operations are still needed to allow
> "legacy" V4L2 device drivers to use converted subdevices. I would then phrase
> it a bit differently:
>
> "Note: this is a temporary so
Re: [PATCH 03/15] [RFCv2] Documentation: add v4l2-controls.txt documenting the new controls API.
On Monday 24 May 2010 02:15:08 Andy Walls wrote: > On Mon, 2010-05-24 at 01:17 +0200, Laurent Pinchart wrote: > > Hi Hans, > > > > > > +Proposals for Extensions > > > + > > > + > > > +Some ideas for future extensions to the spec: > > > + > > > +1) Add a V4L2_CTRL_FLAG_HEX to have values shown as hexadecimal instead > > > of > > > +decimal. Useful for e.g. video_mute_yuv. > > > > Shown where ? > > In the output of `v4l2-ctl -L` or any other app that builds controls for > the user to see. This is really just a formatting hint for the > application, analogous to "%x" in a printf() format. I think there may > be a larger issue of control formatting hints here. > > > > So now for a digression: > > video_mute_yuv is both a very good and bad example: > > $ v4l2-ctl -L > ... > video_mute_yuv (int) : min=0 max=16777215 step=1 default=32896 value=32896 > ... > > The value is YUV values encoded as 0x00YYUUVV. For the cx18 driver the > default is 32869 or 0x008080 (no luminance and neutral red and blue > chrominance). A hex readout makes the control setting more readable. > > But even with improved formatting, this control is a still poor UI > element. Most people can't map a color word, like "green", to a (Y, U, > V) coordinate easily. > > I'll assert > > a. a menu with a few human-readable color names would be more useful True, but not as flexible. > or > > b. the control could really be broken up into three separate sliders, > obviating the need for the HEX formatting hint. Just because the MPEG > encoding engine wants it set as one value, doesn't mean humans must set > it that way. Hmm, I don't really like this idea. What you really want to communicate is that this is a color. How it is represented in a user interface is up to the application. So: c. we add a V4L2_CTRL_FLAG_COLOR flag. The problem is: how do you specify the colorspace and possibly color depth. And perhaps there is an alpha channel as well. The reason I went with a simple hex flag is that it is, well, simple. It greatly improves the readability of colors and other values that are more easily readable in hex format, without introducing the complexity that you get once you start talking about colors. Right now all the color controls that we have are in the 'advanced user' category so I would be happy with just providing a hex flag. Should color controls become much more important, then we can revisit this and make true color controls. Obviously, if someone wants to make a proposal for this now, then feel free. But I don't think it's worth the time and effort. Regards, Hans > I suppose since it's in ivtv and cx18, it's mine to fix. :) > > Regards, > Andy > > > > > +2) It is possible to mark in the controls array which controls have been > > > +successfully written and which failed by for example adding a bit to the > > > +control ID. Not sure if it is worth the effort, though. > > > > > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] drivers/media/dvb/dvb-usb/dib0700: fix return values
Propagte correct error values instead of returning -1 which just means
-EPERM ("Permission denied")
Signed-off-by: Daniel Mack
Cc: Wolfram Sang
Cc: Mauro Carvalho Chehab
Cc: Jiri Slaby
Cc: Dmitry Torokhov
Cc: Devin Heitmueller
Cc: linux-media@vger.kernel.org
---
drivers/media/dvb/dvb-usb/dib0700_core.c | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 4f961d2..d2dabac 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -640,10 +640,10 @@ int dib0700_rc_setup(struct dvb_usb_device *d)
return 0;
/* Set the IR mode */
- i = dib0700_ctrl_wr(d, rc_setup, 3);
- if (i<0) {
+ i = dib0700_ctrl_wr(d, rc_setup, sizeof(rc_setup));
+ if (i < 0) {
err("ir protocol setup failed");
- return -1;
+ return i;
}
if (st->fw_version < 0x10200)
@@ -653,14 +653,14 @@ int dib0700_rc_setup(struct dvb_usb_device *d)
purb = usb_alloc_urb(0, GFP_KERNEL);
if (purb == NULL) {
err("rc usb alloc urb failed\n");
- return -1;
+ return -ENOMEM;
}
purb->transfer_buffer = kzalloc(RC_MSG_SIZE_V1_20, GFP_KERNEL);
if (purb->transfer_buffer == NULL) {
err("rc kzalloc failed\n");
usb_free_urb(purb);
- return -1;
+ return -ENOMEM;
}
purb->status = -EINPROGRESS;
@@ -669,12 +669,10 @@ int dib0700_rc_setup(struct dvb_usb_device *d)
dib0700_rc_urb_completion, d);
ret = usb_submit_urb(purb, GFP_ATOMIC);
- if (ret != 0) {
+ if (ret)
err("rc submit urb failed\n");
- return -1;
- }
- return 0;
+ return ret;
}
static int dib0700_probe(struct usb_interface *intf,
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] drivers/media/dvb/dvb-usb/dib0700: CodingStyle fixes
Signed-off-by: Daniel Mack
Cc: Wolfram Sang
Cc: Mauro Carvalho Chehab
Cc: Jiri Slaby
Cc: Dmitry Torokhov
Cc: Devin Heitmueller
Cc: linux-media@vger.kernel.org
---
drivers/media/dvb/dvb-usb/dib0700_core.c | 66 --
1 files changed, 35 insertions(+), 31 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index d2dabac..45aec3a 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -53,7 +53,7 @@ static int dib0700_ctrl_wr(struct dvb_usb_device *d, u8 *tx,
u8 txlen)
int status;
deb_data(">>> ");
- debug_dump(tx,txlen,deb_data);
+ debug_dump(tx, txlen, deb_data);
status = usb_control_msg(d->udev, usb_sndctrlpipe(d->udev,0),
tx[0], USB_TYPE_VENDOR | USB_DIR_OUT, 0, 0, tx, txlen,
@@ -98,7 +98,7 @@ int dib0700_ctrl_rd(struct dvb_usb_device *d, u8 *tx, u8
txlen, u8 *rx, u8 rxlen
deb_info("ep 0 read error (status = %d)\n",status);
deb_data("<<< ");
- debug_dump(rx,rxlen,deb_data);
+ debug_dump(rx, rxlen, deb_data);
return status; /* length in case of success */
}
@@ -106,28 +106,29 @@ int dib0700_ctrl_rd(struct dvb_usb_device *d, u8 *tx, u8
txlen, u8 *rx, u8 rxlen
int dib0700_set_gpio(struct dvb_usb_device *d, enum dib07x0_gpios gpio, u8
gpio_dir, u8 gpio_val)
{
u8 buf[3] = { REQUEST_SET_GPIO, gpio, ((gpio_dir & 0x01) << 7) |
((gpio_val & 0x01) << 6) };
- return dib0700_ctrl_wr(d,buf,3);
+ return dib0700_ctrl_wr(d, buf, sizeof(buf));
}
static int dib0700_set_usb_xfer_len(struct dvb_usb_device *d, u16
nb_ts_packets)
{
-struct dib0700_state *st = d->priv;
-u8 b[3];
-int ret;
-
-if (st->fw_version >= 0x10201) {
- b[0] = REQUEST_SET_USB_XFER_LEN;
- b[1] = (nb_ts_packets >> 8)&0xff;
- b[2] = nb_ts_packets & 0xff;
-
- deb_info("set the USB xfer len to %i Ts packet\n", nb_ts_packets);
-
- ret = dib0700_ctrl_wr(d, b, 3);
-} else {
- deb_info("this firmware does not allow to change the USB xfer len\n");
- ret = -EIO;
-}
-return ret;
+ struct dib0700_state *st = d->priv;
+ u8 b[3];
+ int ret;
+
+ if (st->fw_version >= 0x10201) {
+ b[0] = REQUEST_SET_USB_XFER_LEN;
+ b[1] = (nb_ts_packets >> 8) & 0xff;
+ b[2] = nb_ts_packets & 0xff;
+
+ deb_info("set the USB xfer len to %i Ts packet\n",
nb_ts_packets);
+
+ ret = dib0700_ctrl_wr(d, b, 3);
+ } else {
+ deb_info("this firmware does not allow to change the USB xfer
len\n");
+ ret = -EIO;
+ }
+
+ return ret;
}
/*
@@ -178,7 +179,8 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
value = ((en_start << 7) | (en_stop << 6) |
(msg[i].len & 0x3F)) << 8 | i2c_dest;
/* I2C ctrl + FE bus; */
- index = ((gen_mode<<6)&0xC0) | ((bus_mode<<4)&0x30);
+ index = ((gen_mode << 6) & 0xC0) |
+ ((bus_mode << 4) & 0x30);
result = usb_control_msg(d->udev,
usb_rcvctrlpipe(d->udev, 0),
@@ -198,11 +200,12 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
} else {
/* Write request */
buf[0] = REQUEST_NEW_I2C_WRITE;
- buf[1] = (msg[i].addr << 1);
+ buf[1] = msg[i].addr << 1;
buf[2] = (en_start << 7) | (en_stop << 6) |
(msg[i].len & 0x3F);
/* I2C ctrl + FE bus; */
- buf[3] = ((gen_mode<<6)&0xC0) | ((bus_mode<<4)&0x30);
+ buf[3] = ((gen_mode << 6) & 0xC0) |
+((bus_mode << 4) & 0x30);
/* The Actual i2c payload */
memcpy(&buf[4], msg[i].buf, msg[i].len);
@@ -240,7 +243,7 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter *adap,
for (i = 0; i < num; i++) {
/* fill in the address */
- buf[1] = (msg[i].addr << 1);
+ buf[1] = msg[i].addr << 1;
/* fill the buffer */
memcpy(&buf[2], msg[i].buf, msg[i].len);
@@ -368,7 +371,8 @@ int dib0700_download_firmware(struct usb_device *udev,
const struct firmware *fw
u8 buf[260];
while ((ret = dvb_usb_get_hexline(fw, &hx, &pos)) > 0) {
- deb_fwdata("writing to address 0x%08x (buffer: 0x%02x
%02x)\n",hx.addr, hx.len, hx.chk);
+ deb_fwdata("writing to address 0x%08x (buffer: 0x%02x %02x)\n",
+ hx.addr, hx.len, hx.chk);
Re: [PATCH 2/2] drivers/media/dvb/dvb-usb/dib0700: CodingStyle fixes
On Mon, May 24, 2010 at 12:57:15PM +0200, Daniel Mack wrote: > Signed-off-by: Daniel Mack > Cc: Wolfram Sang > Cc: Mauro Carvalho Chehab > Cc: Jiri Slaby > Cc: Dmitry Torokhov > Cc: Devin Heitmueller > Cc: linux-media@vger.kernel.org Looks correct to me and definately more readable: Acked-by: Wolfram Sang -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH 1/2] drivers/media/dvb/dvb-usb/dib0700: fix return values
On Mon, May 24, 2010 at 12:57:14PM +0200, Daniel Mack wrote:
> Propagte correct error values instead of returning -1 which just means
> -EPERM ("Permission denied")
>
> Signed-off-by: Daniel Mack
> Cc: Wolfram Sang
> Cc: Mauro Carvalho Chehab
> Cc: Jiri Slaby
> Cc: Dmitry Torokhov
> Cc: Devin Heitmueller
> Cc: linux-media@vger.kernel.org
I am no specialist for this driver, but as I am on cc and it looks good to me
(no big changes, after all):
Acked-by: Wolfram Sang
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: Tentative agenda for Helsinki mini-summit
Hi Mauro, On Sunday 23 May 2010 14:21:46 Mauro Carvalho Chehab wrote: > Hans Verkuil wrote: [snip] > > Comments? Topics I missed? > > I'd like to add another topic: Remote Controllers. I propose to do a short > presentation on this theme, showing how the new RC subsystem was conceived > and discussing a little bit about possible evolutions of it. One of the > things I'm interested on getting feedback is about how Linux embedded > devices are currently handing IR. All Linux TV sets, set top boxes and > other device types have IR, but I've seen no contributions from embedded > developers at RC code. So, after a short presentation, I think we should > reserve some time for discussions. I have no experience at all with IR in V4L2, and I think that's true for the other developers at Nokia. Will there be someone at the mini-summit who has experience or is interested in the topic ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tentative agenda for Helsinki mini-summit
Hi Hans, On Sunday 23 May 2010 12:36:48 Hans Verkuil wrote: > Hi all, > > This is a tentative agenda for the Helsinki mini-summit on June 14-16. > > Please reply to this thread if you have comments or want to add topics. > > The overall layout of the summit is to use the first day to go through all > topics and either come to a conclusion quickly for the 'simple' topics, or > discuss enough so that everyone understands the problem for the more > complex issues. > > The second day will be used for in-depth discussions on those complex > topics and on the third day we will go through all topics again and > translate the discussions into something concrete like a time-line, action > items, etc. > > We have a lot to discuss, so we may have to split the second day into two > 'tracks', each discussing different topics. I hope it is not needed, but I > fear we may have no choice. If we do split up, then one track will touch on > the videobuf-related topics and the other on the remaining topics. > > The first day will also feature a few short presentations on various > topics. Presentations shouldn't be longer than, say, 10 minutes. These > presentations are meant to get everyone up to speed quickly. > > After each topic I've put the names of the main developers active in that > area. If you see your name, then make sure you know the status of that > topic so you can explain it to everyone else. If I think it warrants a > presentation, then I will mention that. Of course, if you disagree, or > want/don't want to do a presentation then just say so. It's a tentative > agenda only. > > The topics below are in no particular order except for the first one. I am > very pleased that Qualcomm has joined this project so I think it would be > nice to start the meeting off with a presentation on their HW architecture. > > 1) Presentation on the Qualcomm video hw architecture. Most of us have no >experience with Qualcomm hardware, so I've asked Jeff Zhong to give a > short overview of their video hardware. Generic comment about platform overview presentations: please skip the small details (we don't need a list of registers :-)), but make sure the overall architecture is properly explained. A functional block diagram is very helpful, and platform-specific features or restrictions should be explained where useful (such as requirements on memory types, hardware ability to run several things in parallel, status of the current driver if any, ...). > 2) Removal of V4L1: status of driver conversion in the kernel, status of >moving v4l1->v4l2 conversion into libv4l1. What needs to be done, when >will it be done and who will do it. Driver conversion: Hans Verkuil, >libv4l1 conversion: Hans de Goede. > > 3) videobuf/videobuf2: what are the shortcomings, what are the requirements > for a 'proper' videobuf implementation, can the existing videobuf be fixed > or do we need a videobuf2. If the latter, what would be needed to convert > existing drivers over to a videobuf2. Laurent Pinchart and Pawel Osciak. > This I'm sure requires a presentation. I will prepare a presentation on the current state of videobuf, highlighting the issues. I can also present the OMAP3 ISP video buffers handling code that I wrote to replace videobuf in that particular driver. > 4) Multi-planar support. Pawel Osciak. > > 5) Media Controller Roadmap. Laurent Pinchart. This probably warrants a > short presentation. There will be a presentation of the media controller concepts (to get everybody up to date) and on the current state of the implementation. I can also present our TODO list, but a proper roadmap is probably something we should discuss all together. > 6) TO DO list regarding V4L2 core framework including the new control > framework. Hans Verkuil. Will be a presentation. > > 7) Status of the Texas Instruments drivers: omapX (Hiremath Vaibhav) and > DM (Sergio Aguirre). Probably should be a short presentation. For the OMAP3 platform I (or maybe Sakari :-)) can explain the status of the driver. > 8) soc-camera status. Particularly with regards to the remaining soc-camera >dependencies in sensor drivers. Guennadi Liakhovetski. > > 9) Driver compliance. We need a framework for V4L2 driver compliance. Hans >Verkuil. > > 10) Discuss list of 'reference' programs to test against. Mauro? > > 11) Adopting old V4L1 programs and converting to V4L2. Hans de Goede? > > 12) Status of intel drivers. Xiaolin Zhang. > > It is my understanding that we will also have X11 and gstreamer experts on > hand. Topics relating to that are welcome. > > During the memory handling brainstorming session earlier this year we also > touched on creating some sort of a generic buffer model allowing for easy > exchange between v4l buffers, framebuffers, texture buffers, etc. It is my > opinion that we should not discuss this in Helsinki. The list of topics is > already quite long and I think it is too early to start working on
[PATCH v3 0/4] WL1273 FM Radio Driver
Hello again. And thanks for the comments. It the first patch I'm kind of suggesting a couple of additions to the general interface: signal level stuff in the hw seek struct and then a function / IOCTL for asking for minimum and maximum for the level. There are many changes I'll follow by commenting to Hans's comments: >> 1. WL1273_CID_FM_REGION for setting the region. This may not be a good >> candidate for standardization as the region control shouldn't exist >> in the kernel in general... > >Is this region relevant for receive, transmit or both? Region is relevant for receiving only. Now I've changes the naming to "band" because TI uses that in their latest document version. >> 2. WL1273_CID_FM_SEEK_SPACING: defines what resolution is used when scanning >> automatically for stations (50KHz, 100KHz or 200KHz). This could be >> useful in general. Could this be a field in the v4l2_hw_freq_seek struct? > >I think this belongs in v4l2_hw_freq_seek. I've added spacing to the hw seek struct. >> 3. WL1273_CID_FM_RDS_CTRL for turning on and off the RDS reception / >> transmission. To me this seems like a useful standard control... > >This already exists. You can enable/disable RDS by setting the > V4L2_TUNER_SUB_RDS subchannel bit when calling S_TUNER or S_MODULATOR. I did this. >> 4. WL1273_CID_SEARCH_LVL for setting the threshold level when detecting radio >> channels when doing automatic scan. This could be useful for fine tuning >> because automatic scanning seems to be kind of problematic... This could >> also be a field in the v4l2_hw_freq_seek struct? > >This too seems reasonable to add to v4l2_hw_freq_seek. Although what sort of >unit this level would have might be tricky. What is the unit for your hardware? I've added this as well. The unit is some kind of dB value: "8 bit signed number in 2âs complement format Each LSB = 1.5051 dBuV". I also added min and max values for the level. >> Could the VIDIOC_S_MODULATOR and VIDIOC_S_TUNER IOCTLs be used for setting >> the TX/RX mode? > >Not entirely sure what you want to achieve here. I gather that the radio is >either receiving, transmitting or off? So it can't receive and transmit at the >same time, right? Yes the radio can only transmit or receive at a time. And the states are: On (RX or TX), Off and Suspended. In the suspended mode that firmware patch is kept in the memory and it doesn't need to get uploaded again when operation resumes. > would expect in that case that calling S_TUNER or S_MODULATOR would switch it > to either receive or transmit mode. S_HW_FREQ_SEEK would of course also switch > it to receive mode. I added this... > There isn't anything to turn off the radio at the moment. Perhaps you can just > automatically turn it off if nobody has the radio device or alsa device open? Yes that can be done. Also volume control could be used. But also there's nothing to put the radio to stand-by (suspension). >> Now there already exits a class for fm transmitters: V4L2_CTRL_CLASS_FM_TX. >> Should a corresponding class be created for FM tuners? > >I'm not sure that we need any. I think the only control that we need is to set >the region, and I think that is more appropriate as a private (?) user control >since it is definitely something that users should be easily able to change. OK, that's fine by me >This probably should be discussed a bit more. Ok. There's also two "new" things. The chip supports in addition to the normal HW seek a HW block seek, which finds all receivable channels at once. And then there's a RSSI block scan that be used in both RX and TX modes to find transmitting radio stations. Should we try to get these also into the general interface? Cheers, Matti Matti J. Aaltonen (4): V4L2: Add features to the interface. MFD: WL1273 FM Radio: MFD driver for the FM radio. ASoC: WL1273 FM Radio Digital audio codec. V4L2: WL1273 FM Radio: Controls for the FM radio. drivers/media/radio/Kconfig| 15 + drivers/media/radio/Makefile |1 + drivers/media/radio/radio-wl1273.c | 1876 drivers/mfd/Kconfig|6 + drivers/mfd/Makefile |2 + drivers/mfd/wl1273-core.c | 606 include/linux/mfd/wl1273-core.h| 326 +++ include/linux/videodev2.h |6 +- include/media/v4l2-ioctl.h |2 + sound/soc/codecs/Kconfig |6 + sound/soc/codecs/Makefile |2 + sound/soc/codecs/wl1273.c | 588 +++ sound/soc/codecs/wl1273.h | 40 + 13 files changed, 3475 insertions(+), 1 deletions(-) create mode 100644 drivers/media/radio/radio-wl1273.c create mode 100644 drivers/mfd/wl1273-core.c create mode 100644 include/linux/mfd/wl1273-core.h create mode 100644 sound/soc/codecs/wl1273.c create mode 100644 sound/soc/codecs/wl1273.h -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord.
[PATCH v3 3/4] ASoC: WL1273 FM Radio Digital audio codec.
The codec handles digital audio input to and output from the
WL1273 FM radio.
Signed-off-by: Matti J. Aaltonen
---
sound/soc/codecs/Kconfig |6 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/wl1273.c | 588 +
sound/soc/codecs/wl1273.h | 40 +++
4 files changed, 636 insertions(+), 0 deletions(-)
create mode 100644 sound/soc/codecs/wl1273.c
create mode 100644 sound/soc/codecs/wl1273.h
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 52b005f..c4769f2 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -35,6 +35,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TWL4030 if TWL4030_CORE
select SND_SOC_UDA134X
select SND_SOC_UDA1380 if I2C
+ select SND_SOC_WL1273 if I2C
select SND_SOC_WM8350 if MFD_WM8350
select SND_SOC_WM8400 if MFD_WM8400
select SND_SOC_WM8510 if SND_SOC_I2C_AND_SPI
@@ -161,6 +162,11 @@ config SND_SOC_UDA134X
config SND_SOC_UDA1380
tristate
+config SND_SOC_WL1273
+ tristate
+ select WL1273_CORE
+ default n
+
config SND_SOC_WM8350
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index dbaecb1..2a7c564 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -22,6 +22,7 @@ snd-soc-tlv320dac33-objs := tlv320dac33.o
snd-soc-twl4030-objs := twl4030.o
snd-soc-uda134x-objs := uda134x.o
snd-soc-uda1380-objs := uda1380.o
+snd-soc-wl1273-objs := wl1273.o
snd-soc-wm8350-objs := wm8350.o
snd-soc-wm8400-objs := wm8400.o
snd-soc-wm8510-objs := wm8510.o
@@ -78,6 +79,7 @@ obj-$(CONFIG_SND_SOC_TLV320DAC33) += snd-soc-tlv320dac33.o
obj-$(CONFIG_SND_SOC_TWL4030) += snd-soc-twl4030.o
obj-$(CONFIG_SND_SOC_UDA134X) += snd-soc-uda134x.o
obj-$(CONFIG_SND_SOC_UDA1380) += snd-soc-uda1380.o
+obj-$(CONFIG_SND_SOC_WL1273) += snd-soc-wl1273.o
obj-$(CONFIG_SND_SOC_WM8350) += snd-soc-wm8350.o
obj-$(CONFIG_SND_SOC_WM8400) += snd-soc-wm8400.o
obj-$(CONFIG_SND_SOC_WM8510) += snd-soc-wm8510.o
diff --git a/sound/soc/codecs/wl1273.c b/sound/soc/codecs/wl1273.c
new file mode 100644
index 000..ab36c0b
--- /dev/null
+++ b/sound/soc/codecs/wl1273.c
@@ -0,0 +1,588 @@
+/*
+ * ALSA SoC WL1273 codec driver
+ *
+ * Author: Matti Aaltonen,
+ *
+ * Copyright: (C) 2010 Nokia Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#undef DEBUG
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "wl1273.h"
+
+static int snd_wl1273_fm_set_i2s_mode(struct wl1273_core *core,
+ int rate, int width)
+{
+ struct device *dev = &core->i2c_dev->dev;
+ int r = 0;
+ u16 mode;
+
+ dev_dbg(dev, "rate: %d\n", rate);
+ dev_dbg(dev, "width: %d\n", width);
+
+ mutex_lock(&core->lock);
+
+ mode = core->i2s_mode & ~WL1273_IS2_WIDTH & ~WL1273_IS2_RATE;
+
+ switch (rate) {
+ case 48000:
+ mode |= WL1273_IS2_RATE_48K;
+ break;
+ case 44100:
+ mode |= WL1273_IS2_RATE_44_1K;
+ break;
+ case 32000:
+ mode |= WL1273_IS2_RATE_32K;
+ break;
+ case 22050:
+ mode |= WL1273_IS2_RATE_22_05K;
+ break;
+ case 16000:
+ mode |= WL1273_IS2_RATE_16K;
+ break;
+ case 12000:
+ mode |= WL1273_IS2_RATE_12K;
+ break;
+ case 11025:
+ mode |= WL1273_IS2_RATE_11_025;
+ break;
+ case 8000:
+ mode |= WL1273_IS2_RATE_8K;
+ break;
+ default:
+ dev_err(dev, "Sampling rate: %d not supported\n", rate);
+ r = -EINVAL;
+ goto out;
+ }
+
+ switch (width) {
+ case 16:
+ mode |= WL1273_IS2_WIDTH_32;
+ break;
+ case 20:
+ mode |= WL1273_IS2_WIDTH_40;
+ break;
+ case 24:
+ mode |= WL1273_IS2_WIDTH_48;
+ break;
+ case 25:
+ mode |= WL1273_IS2_WIDTH_50;
+ break;
+ case 30:
+ mode |= WL1273_IS2_WIDTH_60;
+ break;
+ case 32:
+ mode |= WL1273_IS2_WIDTH_64;
+ break
[PATCH v3 1/4] V4L2: Add features to the interface.
Add fields spacing, level_min, level_max and level to struct v4l2_hw_freq_seek.
The level is used for determining which channels are considered receivable
during HW scan.
Add VIDIOC_G_HW_FREQ_SEEK to IOCTL codes. This is used for getting the minimum
and
maximum values for the level field in the v4l2_hw_freq_seek struct.
Signed-off-by: Matti J. Aaltonen
---
include/linux/videodev2.h |6 +-
include/media/v4l2-ioctl.h |2 ++
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 418dacf..7a81a9c 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -1377,7 +1377,11 @@ struct v4l2_hw_freq_seek {
enum v4l2_tuner_type type;
__u32 seek_upward;
__u32 wrap_around;
- __u32 reserved[8];
+ __u32 spacing;
+ __s32 level_min;
+ __s32 level_max;
+ __s32 level;
+ __u32 reserved[4];
};
/*
diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index e8ba0f2..828cf13 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -220,6 +220,8 @@ struct v4l2_ioctl_ops {
/* Log status ioctl */
int (*vidioc_log_status) (struct file *file, void *fh);
+ int (*vidioc_g_hw_freq_seek) (struct file *file, void *fh,
+ struct v4l2_hw_freq_seek *a);
int (*vidioc_s_hw_freq_seek) (struct file *file, void *fh,
struct v4l2_hw_freq_seek *a);
--
1.6.1.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/4] V4L2: WL1273 FM Radio: Controls for the FM radio.
This file implements V4L2 controls for using the Texas Instruments
WL1273 FM Radio.
Signed-off-by: Matti J. Aaltonen
---
drivers/media/radio/Kconfig| 15 +
drivers/media/radio/Makefile |1 +
drivers/media/radio/radio-wl1273.c | 1876
3 files changed, 1892 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/radio/radio-wl1273.c
diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 83567b8..209fd37 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -452,4 +452,19 @@ config RADIO_TIMBERDALE
found behind the Timberdale FPGA on the Russellville board.
Enabling this driver will automatically select the DSP and tuner.
+config RADIO_WL1273
+ tristate "Texas Instruments WL1273 I2C FM Radio"
+depends on I2C && VIDEO_V4L2 && SND
+ select FW_LOADER
+ ---help---
+ Choose Y here if you have this FM radio chip.
+
+ In order to control your radio card, you will need to use programs
+ that are compatible with the Video For Linux 2 API. Information on
+ this API and pointers to "v4l2" programs may be found at
+ .
+
+ To compile this driver as a module, choose M here: the
+ module will be called radio-wl1273.
+
endif # RADIO_ADAPTERS
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index f615583..d297074 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -26,5 +26,6 @@ obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o
obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o
obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o
+obj-$(CONFIG_RADIO_WL1273) += radio-wl1273.o
EXTRA_CFLAGS += -Isound
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
new file mode 100644
index 000..f19b100
--- /dev/null
+++ b/drivers/media/radio/radio-wl1273.c
@@ -0,0 +1,1876 @@
+/*
+ * Driver for the Texas Instruments WL1273 FM radio.
+ *
+ * Copyright (C) Nokia Corporation
+ * Author: Matti J. Aaltonen
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#undef DEBUG
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_DESC "Wl1273 FM Radio - V4L2"
+
+#define WL1273_POWER_SET_OFF 0
+#define WL1273_POWER_SET_FM(1 << 0)
+#define WL1273_POWER_SET_RDS (1 << 1)
+#define WL1273_POWER_SET_RETENTION (1 << 4)
+
+#define WL1273_PUPD_SET_OFF0x00
+#define WL1273_PUPD_SET_ON 0x01
+#define WL1273_PUPD_SET_RETENTION 0x10
+
+#define WL1273_FREQ_MULT (1 / 625)
+#define WL1273_INV_FREQ_MULT (625 / 1)
+/*
+ * static unsigned char radio_band - Band
+ *
+ * The bands are 0=Japan, 1=USA-Europe. USA-Europe is the default.
+ */
+static unsigned char radio_band = 1;
+module_param(radio_band, byte, 0);
+MODULE_PARM_DESC(radio_band, "Band: 0=Japan, 1=USA-Europe*");
+
+/*
+ * static int radio_nr - The number of the radio device
+ *
+ * The default is 0.
+ */
+static int radio_nr = -1;
+module_param(radio_nr, int, 0);
+MODULE_PARM_DESC(radio_nr, "Radio Nr");
+
+struct wl1273_device {
+ struct v4l2_device v4l2dev;
+ struct video_device videodev;
+ struct device *dev;
+ struct wl1273_core *core;
+ bool rds_on;
+};
+
+static int wl1273_fm_set_tx_freq(struct wl1273_core *core, unsigned int freq)
+{
+ int r = 0;
+
+ if (freq < core->bands[core->band].bottom_frequency) {
+ dev_err(&core->i2c_dev->dev,
+ "Frequency out of range: %d < %d\n",
+ freq, core->bands[core->band].bottom_frequency);
+ return -EDOM;
+ }
+
+ if (freq > core->bands[core->band].top_frequency) {
+ dev_err(&core->i2c_dev->dev,
+ "Frequency out of range: %d > %d\n",
+ freq, core->bands[core->band].top_frequency);
+ return -EDOM;
+ }
+
+ /*
+* The driver works better with this msleep,
+* the documentation doesn't mention it.
+*/
+ msleep(5);
+ dev_dbg(&core->i2c_dev->dev, "%s: freq: %d kHz\n", __func__, freq);
+
+ INIT_COMPLETION(core->busy);
+ /* Set the curr
[PATCH v3 2/4] MFD: WL1273 FM Radio: MFD driver for the FM radio.
This is a parent driver for two child drivers: the V4L2 driver and
the ALSA codec driver. The MFD part provides the I2C communication
to the device and a couple of functions that are called from both
children.
Signed-off-by: Matti J. Aaltonen
---
drivers/mfd/Kconfig |6 +
drivers/mfd/Makefile|2 +
drivers/mfd/wl1273-core.c | 606 +++
include/linux/mfd/wl1273-core.h | 326 +
4 files changed, 940 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/wl1273-core.c
create mode 100644 include/linux/mfd/wl1273-core.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 413576a..5998a94 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -135,6 +135,12 @@ config TWL4030_CODEC
select MFD_CORE
default n
+config WL1273_CORE
+ bool
+ depends on I2C
+ select MFD_CORE
+ default n
+
config MFD_TMIO
bool
default n
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 78295d6..46e611d 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -30,6 +30,8 @@ obj-$(CONFIG_TWL4030_CORE)+= twl-core.o twl4030-irq.o
twl6030-irq.o
obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
obj-$(CONFIG_TWL4030_CODEC)+= twl4030-codec.o
+obj-$(CONFIG_WL1273_CORE) += wl1273-core.o
+
obj-$(CONFIG_MFD_MC13783) += mc13783-core.o
obj-$(CONFIG_MFD_CORE) += mfd-core.o
diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c
new file mode 100644
index 000..7e02c36
--- /dev/null
+++ b/drivers/mfd/wl1273-core.c
@@ -0,0 +1,606 @@
+/*
+ * MFD driver for wl1273 FM radio and audio codec submodules.
+ *
+ * Author: Matti Aaltonen
+ *
+ * Copyright: (C) 2010 Nokia Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#undef DEBUG
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_DESC "WL1273 FM Radio Core"
+
+#define WL1273_IRQ_MASK (WL1273_FR_EVENT | \
+ WL1273_POW_ENB_EVENT)
+
+static const struct band_info bands[] = {
+ /* Japan */
+ {
+ .bottom_frequency = 76000,
+ .top_frequency = 9,
+ .band = 0,
+ },
+ /* USA & Europe */
+ {
+ .bottom_frequency = 87500,
+ .top_frequency = 108000,
+ .band = 1,
+ },
+};
+
+/*
+ * static unsigned char radio_band - Band
+ *
+ * The bands are 0=Japan, 1=USA-Europe. USA-Europe is the default.
+ */
+static unsigned char radio_band = 1;
+module_param(radio_band, byte, 0);
+MODULE_PARM_DESC(radio_band, "Band: 0=Japan, 1=USA-Europe*");
+
+/*
+ * static unsigned int rds_buf - the number of RDS buffer blocks used.
+ *
+ * The default number is 100.
+ */
+static unsigned int rds_buf = 100;
+module_param(rds_buf, uint, 0);
+MODULE_PARM_DESC(rds_buf, "RDS buffer entries: *100*");
+
+int wl1273_fm_read_reg(struct wl1273_core *core, u8 reg, u16 *value)
+{
+ struct i2c_client *client = core->i2c_dev;
+ u8 b[2];
+ int r;
+
+ r = i2c_smbus_read_i2c_block_data(client, reg, 2, b);
+ if (r != 2) {
+ dev_err(&client->dev, "%s: Read: %d fails.\n", __func__, reg);
+ return -EREMOTEIO;
+ }
+
+ *value = (u16)b[0] << 8 | b[1];
+
+ return 0;
+}
+EXPORT_SYMBOL(wl1273_fm_read_reg);
+
+int wl1273_fm_write_cmd(struct wl1273_core *core, u8 cmd, u16 param)
+{
+ struct i2c_client *client = core->i2c_dev;
+ u8 buf[] = { (param >> 8) & 0xff, param & 0xff };
+ int r;
+
+ r = i2c_smbus_write_i2c_block_data(client, cmd, 2, buf);
+ if (r) {
+ dev_err(&client->dev, "%s: Cmd: %d fails.\n", __func__, cmd);
+ return r;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(wl1273_fm_write_cmd);
+
+int wl1273_fm_write_data(struct wl1273_core *core, u8 *data, u16 len)
+{
+ struct i2c_client *client = core->i2c_dev;
+ struct i2c_msg msg[1];
+ int r;
+
+ msg[0].addr = client->addr;
+ msg[0].flags = 0;
+ msg[0].buf = data;
+ msg[0].len = len;
+
+ r = i2c_transfer(client->a
[PATCH v2 2/3] mx27: add support for the CSI device
Signed-off-by: Baruch Siach
---
arch/arm/mach-mx2/clock_imx27.c |2 +-
arch/arm/mach-mx2/devices.c | 31 +++
arch/arm/mach-mx2/devices.h |1 +
3 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-mx2/clock_imx27.c b/arch/arm/mach-mx2/clock_imx27.c
index 0f0823c..5a1aa15 100644
--- a/arch/arm/mach-mx2/clock_imx27.c
+++ b/arch/arm/mach-mx2/clock_imx27.c
@@ -644,7 +644,7 @@ static struct clk_lookup lookups[] = {
_REGISTER_CLOCK("spi_imx.1", NULL, cspi2_clk)
_REGISTER_CLOCK("spi_imx.2", NULL, cspi3_clk)
_REGISTER_CLOCK("imx-fb.0", NULL, lcdc_clk)
- _REGISTER_CLOCK(NULL, "csi", csi_clk)
+ _REGISTER_CLOCK("mx2-camera.0", NULL, csi_clk)
_REGISTER_CLOCK("fsl-usb2-udc", "usb", usb_clk)
_REGISTER_CLOCK("fsl-usb2-udc", "usb_ahb", usb_clk1)
_REGISTER_CLOCK("mxc-ehci.0", "usb", usb_clk)
diff --git a/arch/arm/mach-mx2/devices.c b/arch/arm/mach-mx2/devices.c
index b91e412..6a49c79 100644
--- a/arch/arm/mach-mx2/devices.c
+++ b/arch/arm/mach-mx2/devices.c
@@ -40,6 +40,37 @@
#include "devices.h"
+#ifdef CONFIG_MACH_MX27
+static struct resource mx27_camera_resources[] = {
+ {
+ .start = MX27_CSI_BASE_ADDR,
+ .end = MX27_CSI_BASE_ADDR + 0x1f,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = MX27_EMMA_PRP_BASE_ADDR,
+ .end = MX27_EMMA_PRP_BASE_ADDR + 0x1f,
+ .flags = IORESOURCE_MEM,
+ }, {
+ .start = MX27_INT_CSI,
+ .end = MX27_INT_CSI,
+ .flags = IORESOURCE_IRQ,
+ },{
+ .start = MX27_INT_EMMAPRP,
+ .end = MX27_INT_EMMAPRP,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+struct platform_device mx27_camera_device = {
+ .name = "mx2-camera",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(mx27_camera_resources),
+ .resource = mx27_camera_resources,
+ .dev = {
+ .coherent_dma_mask = 0x,
+ },
+};
+#endif
+
/*
* SPI master controller
*
diff --git a/arch/arm/mach-mx2/devices.h b/arch/arm/mach-mx2/devices.h
index 84ed513..8bdf018 100644
--- a/arch/arm/mach-mx2/devices.h
+++ b/arch/arm/mach-mx2/devices.h
@@ -29,6 +29,7 @@ extern struct platform_device mxc_i2c_device1;
extern struct platform_device mxc_sdhc_device0;
extern struct platform_device mxc_sdhc_device1;
extern struct platform_device mxc_otg_udc_device;
+extern struct platform_device mx27_camera_device;
extern struct platform_device mxc_otg_host;
extern struct platform_device mxc_usbh1;
extern struct platform_device mxc_usbh2;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] mx25: add support for the CSI device
Signed-off-by: Baruch Siach
---
arch/arm/mach-mx25/clock.c| 14 --
arch/arm/mach-mx25/devices.c | 22 ++
arch/arm/mach-mx25/devices.h |1 +
arch/arm/plat-mxc/include/mach/mx25.h |2 ++
4 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mx25/clock.c b/arch/arm/mach-mx25/clock.c
index 1550149..7a98d18 100644
--- a/arch/arm/mach-mx25/clock.c
+++ b/arch/arm/mach-mx25/clock.c
@@ -129,6 +129,11 @@ static unsigned long get_rate_lcdc(struct clk *clk)
return get_rate_per(7);
}
+static unsigned long get_rate_csi(struct clk *clk)
+{
+ return get_rate_per(0);
+}
+
static unsigned long get_rate_otg(struct clk *clk)
{
return 4800; /* FIXME */
@@ -174,6 +179,8 @@ DEFINE_CLOCK(cspi3_clk, 0, CCM_CGCR1, 7, get_rate_ipg,
NULL, NULL);
DEFINE_CLOCK(fec_ahb_clk, 0, CCM_CGCR0, 23, NULL, NULL, NULL);
DEFINE_CLOCK(lcdc_ahb_clk, 0, CCM_CGCR0, 24, NULL, NULL, NULL);
DEFINE_CLOCK(lcdc_per_clk, 0, CCM_CGCR0, 7, NULL, NULL, &lcdc_ahb_clk);
+DEFINE_CLOCK(csi_ahb_clk, 0, CCM_CGCR0, 18, get_rate_csi, NULL, NULL);
+DEFINE_CLOCK(csi_per_clk, 0, CCM_CGCR0, 0, get_rate_csi, NULL, &csi_ahb_clk);
DEFINE_CLOCK(uart1_clk, 0, CCM_CGCR2, 14, get_rate_uart, NULL, &uart_per_clk);
DEFINE_CLOCK(uart2_clk, 0, CCM_CGCR2, 15, get_rate_uart, NULL, &uart_per_clk);
DEFINE_CLOCK(uart3_clk, 0, CCM_CGCR2, 16, get_rate_uart, NULL, &uart_per_clk);
@@ -191,6 +198,7 @@ DEFINE_CLOCK(i2c_clk,0, CCM_CGCR0, 6,
get_rate_i2c, NULL, NULL);
DEFINE_CLOCK(fec_clk, 0, CCM_CGCR1, 15, get_rate_ipg, NULL, &fec_ahb_clk);
DEFINE_CLOCK(dryice_clk, 0, CCM_CGCR1, 8, get_rate_ipg, NULL, NULL);
DEFINE_CLOCK(lcdc_clk, 0, CCM_CGCR1, 29, get_rate_lcdc, NULL, &lcdc_per_clk);
+DEFINE_CLOCK(csi_clk,0, CCM_CGCR1, 4, get_rate_csi, NULL, &csi_per_clk);
#define _REGISTER_CLOCK(d, n, c) \
{ \
@@ -225,6 +233,7 @@ static struct clk_lookup lookups[] = {
_REGISTER_CLOCK("fec.0", NULL, fec_clk)
_REGISTER_CLOCK("imxdi_rtc.0", NULL, dryice_clk)
_REGISTER_CLOCK("imx-fb.0", NULL, lcdc_clk)
+ _REGISTER_CLOCK("mx2-camera.0", NULL, csi_clk)
};
int __init mx25_clocks_init(void)
@@ -239,8 +248,9 @@ int __init mx25_clocks_init(void)
__raw_writel((0xf << 16) | (3 << 26), CRM_BASE + CCM_CGCR1);
__raw_writel((1 << 5), CRM_BASE + CCM_CGCR2);
- /* Clock source for lcdc is upll */
- __raw_writel(__raw_readl(CRM_BASE+0x64) | (1 << 7), CRM_BASE + 0x64);
+ /* Clock source for lcdc and csi is upll */
+ __raw_writel(__raw_readl(CRM_BASE+0x64) | (1 << 7) | (1 << 0),
+ CRM_BASE + 0x64);
mxc_timer_init(&gpt_clk, MX25_IO_ADDRESS(MX25_GPT1_BASE_ADDR), 54);
diff --git a/arch/arm/mach-mx25/devices.c b/arch/arm/mach-mx25/devices.c
index 3f4b8a0..bc6d189 100644
--- a/arch/arm/mach-mx25/devices.c
+++ b/arch/arm/mach-mx25/devices.c
@@ -500,3 +500,25 @@ struct platform_device mx25_fb_device = {
.coherent_dma_mask = 0x,
},
};
+
+static struct resource mx25_csi_resources[] = {
+ {
+ .start = MX25_CSI_BASE_ADDR,
+ .end= MX25_CSI_BASE_ADDR + 0xfff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = MX25_INT_CSI,
+ .flags = IORESOURCE_IRQ
+ },
+};
+
+struct platform_device mx25_csi_device = {
+ .name = "mx2-camera",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(mx25_csi_resources),
+ .resource = mx25_csi_resources,
+ .dev= {
+ .coherent_dma_mask = 0x,
+ },
+};
diff --git a/arch/arm/mach-mx25/devices.h b/arch/arm/mach-mx25/devices.h
index 39560e1..1e80ac2 100644
--- a/arch/arm/mach-mx25/devices.h
+++ b/arch/arm/mach-mx25/devices.h
@@ -21,3 +21,4 @@ extern struct platform_device mx25_fec_device;
extern struct platform_device mxc_nand_device;
extern struct platform_device mx25_rtc_device;
extern struct platform_device mx25_fb_device;
+extern struct platform_device mx25_csi_device;
diff --git a/arch/arm/plat-mxc/include/mach/mx25.h
b/arch/arm/plat-mxc/include/mach/mx25.h
index 4eb6e33..5e6a8b5 100644
--- a/arch/arm/plat-mxc/include/mach/mx25.h
+++ b/arch/arm/plat-mxc/include/mach/mx25.h
@@ -34,11 +34,13 @@
#define MX25_NFC_BASE_ADDR 0xbb00
#define MX25_DRYICE_BASE_ADDR 0x53ffc000
#define MX25_LCDC_BASE_ADDR0x53fbc000
+#define MX25_CSI_BASE_ADDR 0x53ff8000
#define MX25_INT_DRYICE25
#define MX25_INT_FEC 57
#define MX25_INT_NANDFC33
#define MX25_INT_LCDC 39
+#define MX25_INT_CSI 17
#if defined(IMX_NEEDS_DEPRECATED_SYMBOLS)
#define UART1_BASE_ADDRMX25_UART1_BASE_ADDR
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.ker
[PATCH v2 0/3] Driver for the i.MX2x CMOS Sensor Interface
This series contains a soc_camera driver for the i.MX25/i.MX27 CSI device, and platform code for the i.MX25 and i.MX27 chips. This driver is based on a driver for i.MX27 CSI from Sascha Hauer, that Alan Carvalho de Assis has posted in linux-media last December[1]. I tested the mx2_camera driver on the i.MX25 PDK. Sascha Hauer has tested a earlier version of this driver on an i.MX27 based board. I included in this version some fixes from Sascha that enable i.MX27 support. [1] https://patchwork.kernel.org/patch/67636/ Changes v1 -> v2 Addressed the comments of Guennadi Liakhovetski except from the following: 1. The mclk_get_divisor implementation, since I don't know what this code is good for 2. mx2_videobuf_release should not set pcdev->active on i.MX27, because mx27_camera_frame_done needs this pointer 3. In mx27_camera_emma_buf_init I don't know the meaning of those hard coded magic numbers Applied i.MX27 fixes from Sascha. Baruch Siach (3): mx2_camera: Add soc_camera support for i.MX25/i.MX27 mx27: add support for the CSI device mx25: add support for the CSI device arch/arm/mach-mx2/clock_imx27.c |2 +- arch/arm/mach-mx2/devices.c | 31 + arch/arm/mach-mx2/devices.h |1 + arch/arm/mach-mx25/clock.c | 14 +- arch/arm/mach-mx25/devices.c | 22 + arch/arm/mach-mx25/devices.h |1 + arch/arm/plat-mxc/include/mach/memory.h |4 +- arch/arm/plat-mxc/include/mach/mx25.h|2 + arch/arm/plat-mxc/include/mach/mx2_cam.h | 46 + drivers/media/video/Kconfig | 13 + drivers/media/video/Makefile |1 + drivers/media/video/mx2_camera.c | 1471 ++ 12 files changed, 1603 insertions(+), 5 deletions(-) create mode 100644 arch/arm/plat-mxc/include/mach/mx2_cam.h create mode 100644 drivers/media/video/mx2_camera.c -- 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 v2 1/3] mx2_camera: Add soc_camera support for i.MX25/i.MX27
This is the soc_camera support developed by Sascha Hauer for the i.MX27. Alan
Carvalho de Assis modified the original driver to get it working on more recent
kernels. I modified it further to add support for i.MX25. This driver has been
tested on i.MX25 and i.MX27 based platforms.
Signed-off-by: Baruch Siach
---
arch/arm/plat-mxc/include/mach/memory.h |4 +-
arch/arm/plat-mxc/include/mach/mx2_cam.h | 46 +
drivers/media/video/Kconfig | 13 +
drivers/media/video/Makefile |1 +
drivers/media/video/mx2_camera.c | 1471 ++
5 files changed, 1533 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/plat-mxc/include/mach/mx2_cam.h
create mode 100644 drivers/media/video/mx2_camera.c
diff --git a/arch/arm/plat-mxc/include/mach/memory.h
b/arch/arm/plat-mxc/include/mach/memory.h
index c4b40c3..5803836 100644
--- a/arch/arm/plat-mxc/include/mach/memory.h
+++ b/arch/arm/plat-mxc/include/mach/memory.h
@@ -44,12 +44,12 @@
*/
#define CONSISTENT_DMA_SIZE SZ_8M
-#elif defined(CONFIG_MX1_VIDEO)
+#elif defined(CONFIG_MX1_VIDEO) || defined(CONFIG_MX2_VIDEO)
/*
* Increase size of DMA-consistent memory region.
* This is required for i.MX camera driver to capture at least four VGA frames.
*/
#define CONSISTENT_DMA_SIZE SZ_4M
-#endif /* CONFIG_MX1_VIDEO */
+#endif /* CONFIG_MX1_VIDEO || CONFIG_MX2_VIDEO */
#endif /* __ASM_ARCH_MXC_MEMORY_H__ */
diff --git a/arch/arm/plat-mxc/include/mach/mx2_cam.h
b/arch/arm/plat-mxc/include/mach/mx2_cam.h
new file mode 100644
index 000..3c080a3
--- /dev/null
+++ b/arch/arm/plat-mxc/include/mach/mx2_cam.h
@@ -0,0 +1,46 @@
+/*
+ * mx2-cam.h - i.MX27/i.MX25 camera driver header file
+ *
+ * Copyright (C) 2003, Intel Corporation
+ * Copyright (C) 2008, Sascha Hauer
+ * Copyright (C) 2010, Baruch Siach
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#ifndef __MACH_MX2_CAM_H_
+#define __MACH_MX2_CAM_H_
+
+#define MX2_CAMERA_SWAP16 (1 << 0)
+#define MX2_CAMERA_EXT_VSYNC (1 << 1)
+#define MX2_CAMERA_CCIR(1 << 2)
+#define MX2_CAMERA_CCIR_INTERLACE (1 << 3)
+#define MX2_CAMERA_HSYNC_HIGH (1 << 4)
+#define MX2_CAMERA_GATED_CLOCK (1 << 5)
+#define MX2_CAMERA_INV_DATA(1 << 6)
+#define MX2_CAMERA_PCLK_SAMPLE_RISING (1 << 7)
+#define MX2_CAMERA_PACK_DIR_MSB(1 << 8)
+
+/**
+ * struct mx2_camera_platform_data - optional platform data for mx2_camera
+ * @flags: any combination of MX2_CAMERA_*
+ * @clk: clock rate of the csi block / 2
+ */
+struct mx2_camera_platform_data {
+ unsigned long flags;
+ unsigned long clk;
+};
+
+#endif /* __MACH_MX2_CAM_H_ */
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 9644cf7..73b87a9 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -949,6 +949,19 @@ config VIDEO_OMAP2
---help---
This is a v4l2 driver for the TI OMAP2 camera capture interface
+config MX2_VIDEO
+bool
+
+config VIDEO_MX2
+ tristate "i.MX27/i.MX25 Camera Sensor Interface driver"
+ depends on VIDEO_DEV && SOC_CAMERA && (MACH_MX27 || ARCH_MX25)
+ select VIDEOBUF_DMA_CONTIG
+ select MX2_VIDEO
+ ---help---
+ This is a v4l2 driver for the i.MX27 and the i.MX25 Camera Sensor
+ Interface
+
+
#
# USB Multimedia device configuration
#
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index c51c386..72615fd 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -156,6 +156,7 @@ obj-$(CONFIG_SOC_CAMERA)+= soc_camera.o
soc_mediabus.o
obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
# soc-camera host drivers have to be linked after camera drivers
obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
+obj-$(CONFIG_VIDEO_MX2)+= mx2_camera.o
obj-$(CONFIG_VIDEO_MX3)+= mx3_camera.o
obj-$(CONFIG_VIDEO_PXA27x) += pxa_camera.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU) += sh_mobile_ceu_camera.o
diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
new file mode 100644
index 000..d0a3950
--- /dev/null
+++ b/drivers/media/video/mx2_camera.c
Re: [PATCH v2 0/3] Driver for the i.MX2x CMOS Sensor Interface
Hi Baruch On Mon, 24 May 2010, Baruch Siach wrote: > This series contains a soc_camera driver for the i.MX25/i.MX27 CSI device, and > platform code for the i.MX25 and i.MX27 chips. This driver is based on a > driver for i.MX27 CSI from Sascha Hauer, that Alan Carvalho de Assis has > posted in linux-media last December[1]. I tested the mx2_camera driver on the > i.MX25 PDK. Sascha Hauer has tested a earlier version of this driver on an > i.MX27 based board. I included in this version some fixes from Sascha that > enable i.MX27 support. > > [1] https://patchwork.kernel.org/patch/67636/ Thanks for the patches! I'll have a look at them in the next couple of days. I presume, you do not expect this driver to make it into 2.6.35? rc1 is expected any time now, so, we'll take our time and prepare it for 2.6.36, right? Thanks Guennadi > > Changes v1 -> v2 > Addressed the comments of Guennadi Liakhovetski except from the following: > > 1. The mclk_get_divisor implementation, since I don't know what this code >is good for > > 2. mx2_videobuf_release should not set pcdev->active on i.MX27, because >mx27_camera_frame_done needs this pointer > > 3. In mx27_camera_emma_buf_init I don't know the meaning of those hard >coded magic numbers > > Applied i.MX27 fixes from Sascha. > > Baruch Siach (3): > mx2_camera: Add soc_camera support for i.MX25/i.MX27 > mx27: add support for the CSI device > mx25: add support for the CSI device > > arch/arm/mach-mx2/clock_imx27.c |2 +- > arch/arm/mach-mx2/devices.c | 31 + > arch/arm/mach-mx2/devices.h |1 + > arch/arm/mach-mx25/clock.c | 14 +- > arch/arm/mach-mx25/devices.c | 22 + > arch/arm/mach-mx25/devices.h |1 + > arch/arm/plat-mxc/include/mach/memory.h |4 +- > arch/arm/plat-mxc/include/mach/mx25.h|2 + > arch/arm/plat-mxc/include/mach/mx2_cam.h | 46 + > drivers/media/video/Kconfig | 13 + > drivers/media/video/Makefile |1 + > drivers/media/video/mx2_camera.c | 1471 > ++ > 12 files changed, 1603 insertions(+), 5 deletions(-) > create mode 100644 arch/arm/plat-mxc/include/mach/mx2_cam.h > create mode 100644 drivers/media/video/mx2_camera.c > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 03/15] [RFCv2] Documentation: add v4l2-controls.txt documenting the new controls API.
On Monday 24 May 2010 11:44:16 Hans Verkuil wrote: > Hi Laurent, > > Thanks for your review! As always, it was very useful. I've incorporated most points in my ctrlfw3 branch: http://git.linuxtv.org/hverkuil/v4l-dvb.git?a=shortlog;h=refs/heads/ctrlfw3 Main changes: - Replaced 'bridge driver' by 'V4L2 driver'. - Added is_volatile and is_uninitialized flags (to control whether g_volatile_ctrl or init should be called). - Added is_volatile, is_uninitialized and is_private flags to v4l2_ctrl_config. - If the name field in struct v4l2_ctrl_config is NULL, then assume it is a standard control and fill in the defaults accordingly. These two changes together make it possible to make an array of struct v4l2_ctrl_config to create all controls. Perhaps v4l2_ctrl_new_custom should be renamed to v4l2_ctrl_new? - v4l2_ctrl_new_std_menu now has a 'max' argument. - v4l2_ctrl_new_std can no longer be used to create a standard menu control. This should prevent confusion regarding step and skip_mask. - v4l2_ctrl_active and v4l2_ctrl_grab set the flag atomically, so can be called from anywhere. I did not yet change anything regarding the init return type. I'm really not sure what userspace is supposed to do here. If you fail initializing a control, does that mean that -EIO should be returned? The only way this can fail is if there is a hardware problem, right? Can you give some background info on how this is currently handled in uvc? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Driver for the i.MX2x CMOS Sensor Interface
Hi Guennadi,
On Mon, May 24, 2010 at 03:34:32PM +0200, Guennadi Liakhovetski wrote:
> On Mon, 24 May 2010, Baruch Siach wrote:
>
> > This series contains a soc_camera driver for the i.MX25/i.MX27 CSI device,
> > and
> > platform code for the i.MX25 and i.MX27 chips. This driver is based on a
> > driver for i.MX27 CSI from Sascha Hauer, that Alan Carvalho de Assis has
> > posted in linux-media last December[1]. I tested the mx2_camera driver on
> > the
> > i.MX25 PDK. Sascha Hauer has tested a earlier version of this driver on an
> > i.MX27 based board. I included in this version some fixes from Sascha that
> > enable i.MX27 support.
> >
> > [1] https://patchwork.kernel.org/patch/67636/
>
> Thanks for the patches! I'll have a look at them in the next couple of
> days. I presume, you do not expect this driver to make it into 2.6.35? rc1
> is expected any time now, so, we'll take our time and prepare it for
> 2.6.36, right?
I don't expect this driver to be in 2.6.35. It's not that urgent. This code
should also do some time in -next.
Thanks for your continued support.
baruch
> >
> > Changes v1 -> v2
> > Addressed the comments of Guennadi Liakhovetski except from the
> > following:
> >
> > 1. The mclk_get_divisor implementation, since I don't know what this
> > code
> >is good for
> >
> > 2. mx2_videobuf_release should not set pcdev->active on i.MX27, because
> >mx27_camera_frame_done needs this pointer
> >
> > 3. In mx27_camera_emma_buf_init I don't know the meaning of those hard
> >coded magic numbers
> >
> > Applied i.MX27 fixes from Sascha.
> >
> > Baruch Siach (3):
> > mx2_camera: Add soc_camera support for i.MX25/i.MX27
> > mx27: add support for the CSI device
> > mx25: add support for the CSI device
> >
> > arch/arm/mach-mx2/clock_imx27.c |2 +-
> > arch/arm/mach-mx2/devices.c | 31 +
> > arch/arm/mach-mx2/devices.h |1 +
> > arch/arm/mach-mx25/clock.c | 14 +-
> > arch/arm/mach-mx25/devices.c | 22 +
> > arch/arm/mach-mx25/devices.h |1 +
> > arch/arm/plat-mxc/include/mach/memory.h |4 +-
> > arch/arm/plat-mxc/include/mach/mx25.h|2 +
> > arch/arm/plat-mxc/include/mach/mx2_cam.h | 46 +
> > drivers/media/video/Kconfig | 13 +
> > drivers/media/video/Makefile |1 +
> > drivers/media/video/mx2_camera.c | 1471
> > ++
> > 12 files changed, 1603 insertions(+), 5 deletions(-)
> > create mode 100644 arch/arm/plat-mxc/include/mach/mx2_cam.h
> > create mode 100644 drivers/media/video/mx2_camera.c
> >
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] drivers/media/dvb/dvb-usb/dib0700: CodingStyle fixes
See comments below:
On Mon, May 24, 2010 at 6:57 AM, Daniel Mack wrote:
> @@ -106,28 +106,29 @@ int dib0700_ctrl_rd(struct dvb_usb_device *d, u8 *tx,
> u8 txlen, u8 *rx, u8 rxlen
> int dib0700_set_gpio(struct dvb_usb_device *d, enum dib07x0_gpios gpio, u8
> gpio_dir, u8 gpio_val)
> {
> u8 buf[3] = { REQUEST_SET_GPIO, gpio, ((gpio_dir & 0x01) << 7) |
> ((gpio_val & 0x01) << 6) };
> - return dib0700_ctrl_wr(d,buf,3);
> + return dib0700_ctrl_wr(d, buf, sizeof(buf));
> }
>
> static int dib0700_set_usb_xfer_len(struct dvb_usb_device *d, u16
> nb_ts_packets)
> {
> - struct dib0700_state *st = d->priv;
> - u8 b[3];
> - int ret;
> -
> - if (st->fw_version >= 0x10201) {
> - b[0] = REQUEST_SET_USB_XFER_LEN;
> - b[1] = (nb_ts_packets >> 8)&0xff;
> - b[2] = nb_ts_packets & 0xff;
> -
> - deb_info("set the USB xfer len to %i Ts packet\n", nb_ts_packets);
> -
> - ret = dib0700_ctrl_wr(d, b, 3);
> - } else {
> - deb_info("this firmware does not allow to change the USB xfer len\n");
> - ret = -EIO;
> - }
> - return ret;
> + struct dib0700_state *st = d->priv;
> + u8 b[3];
> + int ret;
> +
> + if (st->fw_version >= 0x10201) {
> + b[0] = REQUEST_SET_USB_XFER_LEN;
> + b[1] = (nb_ts_packets >> 8) & 0xff;
> + b[2] = nb_ts_packets & 0xff;
> +
> + deb_info("set the USB xfer len to %i Ts packet\n",
> nb_ts_packets);
> +
> + ret = dib0700_ctrl_wr(d, b, 3);
sizeof(b) would be better than the hard-coded value of 3 above.
> + } else {
> + deb_info("this firmware does not allow to change the USB xfer
> len\n");
> + ret = -EIO;
> + }
> +
> + return ret;
> }
>
> /*
Everything else looks good.
Regards,
David Ellingsworth
--
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] IR/imon: clean up usage of bools
There was a mix of 0/1 and false/true. Pick one convention and stick
with it (I picked false/true).
Signed-off-by: Jarod Wilson
---
drivers/media/IR/imon.c | 48 +++---
1 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/media/IR/imon.c b/drivers/media/IR/imon.c
index 5e20456..2bae9ba 100644
--- a/drivers/media/IR/imon.c
+++ b/drivers/media/IR/imon.c
@@ -385,7 +385,7 @@ static int display_open(struct inode *inode, struct file
*file)
err("%s: display port is already open", __func__);
retval = -EBUSY;
} else {
- ictx->display_isopen = 1;
+ ictx->display_isopen = true;
file->private_data = ictx;
dev_dbg(ictx->dev, "display port opened\n");
}
@@ -422,7 +422,7 @@ static int display_close(struct inode *inode, struct file
*file)
err("%s: display is not open", __func__);
retval = -EIO;
} else {
- ictx->display_isopen = 0;
+ ictx->display_isopen = false;
dev_dbg(ictx->dev, "display port closed\n");
if (!ictx->dev_present_intf0) {
/*
@@ -491,12 +491,12 @@ static int send_packet(struct imon_context *ictx)
}
init_completion(&ictx->tx.finished);
- ictx->tx.busy = 1;
+ ictx->tx.busy = true;
smp_rmb(); /* ensure later readers know we're busy */
retval = usb_submit_urb(ictx->tx_urb, GFP_KERNEL);
if (retval) {
- ictx->tx.busy = 0;
+ ictx->tx.busy = false;
smp_rmb(); /* ensure later readers know we're not busy */
err("%s: error submitting urb(%d)", __func__, retval);
} else {
@@ -682,7 +682,7 @@ static ssize_t store_associate_remote(struct device *d,
return -ENODEV;
mutex_lock(&ictx->lock);
- ictx->rf_isassociating = 1;
+ ictx->rf_isassociating = true;
send_associate_24g(ictx);
mutex_unlock(&ictx->lock);
@@ -950,7 +950,7 @@ static void usb_tx_callback(struct urb *urb)
ictx->tx.status = urb->status;
/* notify waiters that write has finished */
- ictx->tx.busy = 0;
+ ictx->tx.busy = false;
smp_rmb(); /* ensure later readers know we're not busy */
complete(&ictx->tx.finished);
}
@@ -1215,7 +1215,7 @@ static bool imon_mouse_event(struct imon_context *ictx,
{
char rel_x = 0x00, rel_y = 0x00;
u8 right_shift = 1;
- bool mouse_input = 1;
+ bool mouse_input = true;
int dir = 0;
/* newer iMON device PAD or mouse button */
@@ -1246,7 +1246,7 @@ static bool imon_mouse_event(struct imon_context *ictx,
} else if (ictx->kc == KEY_CHANNELDOWN && (buf[2] & 0x40) != 0x40) {
dir = -1;
} else
- mouse_input = 0;
+ mouse_input = false;
if (mouse_input) {
dev_dbg(ictx->dev, "sending mouse data via input subsystem\n");
@@ -1450,7 +1450,7 @@ static void imon_incoming_packet(struct imon_context
*ictx,
unsigned char *buf = urb->transfer_buffer;
struct device *dev = ictx->dev;
u32 kc;
- bool norelease = 0;
+ bool norelease = false;
int i;
u64 temp_key;
u64 panel_key = 0;
@@ -1517,7 +1517,7 @@ static void imon_incoming_packet(struct imon_context
*ictx,
!(buf[1] & 0x1 || buf[1] >> 2 & 0x1))) {
len = 8;
imon_pad_to_keys(ictx, buf);
- norelease = 1;
+ norelease = true;
}
if (debug) {
@@ -1580,7 +1580,7 @@ not_input_data:
(buf[6] == 0x5E && buf[7] == 0xDF))) { /* DT */
dev_warn(dev, "%s: remote associated refid=%02X\n",
__func__, buf[1]);
- ictx->rf_isassociating = 0;
+ ictx->rf_isassociating = false;
}
}
@@ -1790,9 +1790,9 @@ static bool imon_find_endpoints(struct imon_context *ictx,
int ifnum = iface_desc->desc.bInterfaceNumber;
int num_endpts = iface_desc->desc.bNumEndpoints;
int i, ep_dir, ep_type;
- bool ir_ep_found = 0;
- bool display_ep_found = 0;
- bool tx_control = 0;
+ bool ir_ep_found = false;
+ bool display_ep_found = false;
+ bool tx_control = false;
/*
* Scan the endpoint list and set:
@@ -1808,13 +1808,13 @@ static bool imon_find_endpoints(struct imon_context
*ictx,
ep_type == USB_ENDPOINT_XFER_INT) {
rx_endpoint = ep;
- ir_ep_found = 1;
+ ir_ep_found = true;
dev_dbg(ictx->dev, "%s: found IR endpoint\n", __func__);
} else if (!display_ep_found && ep_dir == USB_DIR_OUT &&
ep_type == USB_ENDPOINT_XFER_INT) {
[PATCH] IR/imon: add auto-config for 0xffdc rf device
Add auto-config support for iMON 2.4G LT RF device, based on
debug output from Giulio Amodeo in Red Hat bugzilla #572288.
Also flips the switch on only setting up the rf associate sysfs
attr only if we think we're looking at an RF device, vs. previously,
setting up the attr for all 0xffdc devices, so its possible (but a bit
unlikely) there's another iMON RF device we'll have to fix up.
Nb: should be applied after "IR/imon: clean up usage of bools", or there
will be a slight contextual mismatch.
Signed-off-by: Jarod Wilson
---
drivers/media/IR/imon.c | 27 +--
1 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/media/IR/imon.c b/drivers/media/IR/imon.c
index 5e20456..0e43795 100644
--- a/drivers/media/IR/imon.c
+++ b/drivers/media/IR/imon.c
@@ -94,6 +94,7 @@ struct imon_context {
bool display_supported; /* not all controllers do */
bool display_isopen;/* display port has been opened */
+ bool rf_device; /* true if iMON 2.4G LT/DT RF device */
bool rf_isassociating; /* RF remote associating */
bool dev_present_intf0; /* USB device presence, interface 0 */
bool dev_present_intf1; /* USB device presence, interface 1 */
@@ -1465,7 +1466,7 @@ static void imon_incoming_packet(struct imon_context
*ictx,
idev = ictx->idev;
/* filter out junk data on the older 0xffdc imon devices */
- if ((buf[0] == 0xff) && (buf[7] == 0xff))
+ if ((buf[0] == 0xff) && (buf[1] == 0xff) && (buf[2] == 0xff))
return;
/* Figure out what key was pressed */
@@ -1908,6 +1909,7 @@ static struct imon_context *imon_init_intf0(struct
usb_interface *intf)
ictx->dev_present_intf0 = true;
ictx->rx_urb_intf0 = rx_urb;
ictx->tx_urb = tx_urb;
+ ictx->rf_device = false;
ictx->vendor = le16_to_cpu(ictx->usbdev_intf0->descriptor.idVendor);
ictx->product = le16_to_cpu(ictx->usbdev_intf0->descriptor.idProduct);
@@ -2047,6 +2049,12 @@ static void imon_get_ffdc_type(struct imon_context *ictx)
dev_info(ictx->dev, "0xffdc iMON Knob, iMON IR");
ictx->display_supported = false;
break;
+ /* iMON 2.4G LT (usb stick), no display, iMON RF */
+ case 0x4e:
+ dev_info(ictx->dev, "0xffdc iMON 2.4G LT, iMON RF");
+ ictx->display_supported = false;
+ ictx->rf_device = true;
+ break;
/* iMON VFD, no IR (does have vol knob tho) */
case 0x35:
dev_info(ictx->dev, "0xffdc iMON VFD + knob, no IR");
@@ -2197,15 +2205,6 @@ static int __devinit imon_probe(struct usb_interface
*interface,
goto fail;
}
- if (product == 0xffdc) {
- /* RF products *also* use 0xffdc... sigh... */
- sysfs_err = sysfs_create_group(&interface->dev.kobj,
-
&imon_rf_attribute_group);
- if (sysfs_err)
- err("%s: Could not create RF sysfs entries(%d)",
- __func__, sysfs_err);
- }
-
} else {
/* this is the secondary interface on the device */
ictx = imon_init_intf1(interface, first_if_ctx);
@@ -2233,6 +2232,14 @@ static int __devinit imon_probe(struct usb_interface
*interface,
imon_set_display_type(ictx, interface);
+ if (product == 0xffdc && ictx->rf_device) {
+ sysfs_err = sysfs_create_group(&interface->dev.kobj,
+
&imon_rf_attribute_group);
+ if (sysfs_err)
+ err("%s: Could not create RF sysfs entries(%d)",
+ __func__, sysfs_err);
+ }
+
if (ictx->display_supported)
imon_init_display(ictx, interface);
}
--
Jarod Wilson
ja...@redhat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers/media/dvb/dvb-usb/dib0700: CodingStyle fixes
Signed-off-by: Daniel Mack
Cc: Wolfram Sang
Cc: Mauro Carvalho Chehab
Cc: Jiri Slaby
Cc: Dmitry Torokhov
Cc: Devin Heitmueller
Cc: linux-media@vger.kernel.org
---
drivers/media/dvb/dvb-usb/dib0700_core.c | 66 --
1 files changed, 35 insertions(+), 31 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index d2dabac..7deade7 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -53,7 +53,7 @@ static int dib0700_ctrl_wr(struct dvb_usb_device *d, u8 *tx,
u8 txlen)
int status;
deb_data(">>> ");
- debug_dump(tx,txlen,deb_data);
+ debug_dump(tx, txlen, deb_data);
status = usb_control_msg(d->udev, usb_sndctrlpipe(d->udev,0),
tx[0], USB_TYPE_VENDOR | USB_DIR_OUT, 0, 0, tx, txlen,
@@ -98,7 +98,7 @@ int dib0700_ctrl_rd(struct dvb_usb_device *d, u8 *tx, u8
txlen, u8 *rx, u8 rxlen
deb_info("ep 0 read error (status = %d)\n",status);
deb_data("<<< ");
- debug_dump(rx,rxlen,deb_data);
+ debug_dump(rx, rxlen, deb_data);
return status; /* length in case of success */
}
@@ -106,28 +106,29 @@ int dib0700_ctrl_rd(struct dvb_usb_device *d, u8 *tx, u8
txlen, u8 *rx, u8 rxlen
int dib0700_set_gpio(struct dvb_usb_device *d, enum dib07x0_gpios gpio, u8
gpio_dir, u8 gpio_val)
{
u8 buf[3] = { REQUEST_SET_GPIO, gpio, ((gpio_dir & 0x01) << 7) |
((gpio_val & 0x01) << 6) };
- return dib0700_ctrl_wr(d,buf,3);
+ return dib0700_ctrl_wr(d, buf, sizeof(buf));
}
static int dib0700_set_usb_xfer_len(struct dvb_usb_device *d, u16
nb_ts_packets)
{
-struct dib0700_state *st = d->priv;
-u8 b[3];
-int ret;
-
-if (st->fw_version >= 0x10201) {
- b[0] = REQUEST_SET_USB_XFER_LEN;
- b[1] = (nb_ts_packets >> 8)&0xff;
- b[2] = nb_ts_packets & 0xff;
-
- deb_info("set the USB xfer len to %i Ts packet\n", nb_ts_packets);
-
- ret = dib0700_ctrl_wr(d, b, 3);
-} else {
- deb_info("this firmware does not allow to change the USB xfer len\n");
- ret = -EIO;
-}
-return ret;
+ struct dib0700_state *st = d->priv;
+ u8 b[3];
+ int ret;
+
+ if (st->fw_version >= 0x10201) {
+ b[0] = REQUEST_SET_USB_XFER_LEN;
+ b[1] = (nb_ts_packets >> 8) & 0xff;
+ b[2] = nb_ts_packets & 0xff;
+
+ deb_info("set the USB xfer len to %i Ts packet\n",
nb_ts_packets);
+
+ ret = dib0700_ctrl_wr(d, b, sizeof(b));
+ } else {
+ deb_info("this firmware does not allow to change the USB xfer
len\n");
+ ret = -EIO;
+ }
+
+ return ret;
}
/*
@@ -178,7 +179,8 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
value = ((en_start << 7) | (en_stop << 6) |
(msg[i].len & 0x3F)) << 8 | i2c_dest;
/* I2C ctrl + FE bus; */
- index = ((gen_mode<<6)&0xC0) | ((bus_mode<<4)&0x30);
+ index = ((gen_mode << 6) & 0xC0) |
+ ((bus_mode << 4) & 0x30);
result = usb_control_msg(d->udev,
usb_rcvctrlpipe(d->udev, 0),
@@ -198,11 +200,12 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
} else {
/* Write request */
buf[0] = REQUEST_NEW_I2C_WRITE;
- buf[1] = (msg[i].addr << 1);
+ buf[1] = msg[i].addr << 1;
buf[2] = (en_start << 7) | (en_stop << 6) |
(msg[i].len & 0x3F);
/* I2C ctrl + FE bus; */
- buf[3] = ((gen_mode<<6)&0xC0) | ((bus_mode<<4)&0x30);
+ buf[3] = ((gen_mode << 6) & 0xC0) |
+((bus_mode << 4) & 0x30);
/* The Actual i2c payload */
memcpy(&buf[4], msg[i].buf, msg[i].len);
@@ -240,7 +243,7 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter *adap,
for (i = 0; i < num; i++) {
/* fill in the address */
- buf[1] = (msg[i].addr << 1);
+ buf[1] = msg[i].addr << 1;
/* fill the buffer */
memcpy(&buf[2], msg[i].buf, msg[i].len);
@@ -368,7 +371,8 @@ int dib0700_download_firmware(struct usb_device *udev,
const struct firmware *fw
u8 buf[260];
while ((ret = dvb_usb_get_hexline(fw, &hx, &pos)) > 0) {
- deb_fwdata("writing to address 0x%08x (buffer: 0x%02x
%02x)\n",hx.addr, hx.len, hx.chk);
+ deb_fwdata("writing to address 0x%08x (buffer: 0x%02x %02x)\n",
+ hx.addr, hx.len, hx.ch
Kernel oops with current hg (ir-sysfs.c ?)
I guess it is a similar problem like the one that was solved a few months ago with this patch: http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/14232 I compiled the current v4l-dvb hg against the 2.6.32 Ubuntu 10.04 kernel May 24 13:30:22 ubuntuvdr1 kernel: [5.629408] DVB: registering new adapter (TT-Budget C-1501 PCI) May 24 13:30:22 ubuntuvdr1 kernel: [5.646949] tda9887 3-0043: i2c i/o error: rc == -5 (should be 4) May 24 13:30:22 ubuntuvdr1 kernel: [5.649823] tda9887 3-0043: i2c i/o error: rc == -5 (should be 4) May 24 13:30:22 ubuntuvdr1 kernel: [5.666028] adapter has MAC addr = 00:d0:5c:c6:5a:11 May 24 13:30:22 ubuntuvdr1 kernel: [5.692518] Registered IR keymap rc-tt-1500 May 24 13:30:22 ubuntuvdr1 kernel: [5.692545] BUG: unable to handle kernel NULL pointer dereference at (null) May 24 13:30:22 ubuntuvdr1 kernel: [5.692554] IP: [] ir_register_class+0x3e/0x190 [ir_core] May 24 13:30:22 ubuntuvdr1 kernel: [5.692566] *pde = May 24 13:30:22 ubuntuvdr1 kernel: [5.692571] Oops: [#1] SMP May 24 13:30:22 ubuntuvdr1 kernel: [5.692575] last sysfs file: /sys/module/ir_core/initstate May 24 13:30:22 ubuntuvdr1 kernel: [5.692580] Modules linked in: rc_tt_1500 tda10021 snd_hda_codec_realtek tuner_simple tuner_types tda9887 tda8290 tuner msp3400 snd_hda_intel$ May 24 13:30:22 ubuntuvdr1 kernel: [5.692659] May 24 13:30:22 ubuntuvdr1 kernel: [5.692663] Pid: 375, comm: modprobe Not tainted (2.6.32-22-generic #33-Ubuntu) M56S-S3 May 24 13:30:22 ubuntuvdr1 kernel: [5.692669] EIP: 0060:[] EFLAGS: 00010246 CPU: 0 May 24 13:30:22 ubuntuvdr1 kernel: [5.692677] EIP is at ir_register_class+0x3e/0x190 [ir_core] May 24 13:30:22 ubuntuvdr1 kernel: [5.692681] EAX: EBX: f6375000 ECX: EDX: 0100 May 24 13:30:22 ubuntuvdr1 kernel: [5.692686] ESI: f4fa6000 EDI: EBP: f61d5d78 ESP: f61d5d4c May 24 13:30:22 ubuntuvdr1 kernel: [5.692691] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 May 24 13:30:22 ubuntuvdr1 kernel: [5.692697] Process modprobe (pid: 375, ti=f61d4000 task=f61b6680 task.ti=f61d4000) May 24 13:30:22 ubuntuvdr1 kernel: [5.692704] Stack: May 24 13:30:22 ubuntuvdr1 kernel: [5.692707] 0246 f825ba47 c24054e0 f825ba47 001d5d64 0128 f4fa6000 003f May 24 13:30:22 ubuntuvdr1 kernel: [5.692717] <0> faee9068 0027 f4fa6000 f61d5db0 f825bb7c 009f f8ce32ef May 24 13:30:22 ubuntuvdr1 kernel: [5.692728] <0> c0588f82 f825cc11 0296 f637513c f6375120 f6375000 f6827000 f4fa6000 May 24 13:30:22 ubuntuvdr1 kernel: [5.692741] Call Trace: May 24 13:30:22 ubuntuvdr1 kernel: [5.692750] [] ? __ir_input_register+0x167/0x350 [ir_core] May 24 13:30:22 ubuntuvdr1 kernel: [5.692759] [] ? __ir_input_register+0x167/0x350 [ir_core] May 24 13:30:22 ubuntuvdr1 kernel: [5.692769] [] ? __ir_input_register+0x29c/0x350 [ir_core] May 24 13:30:22 ubuntuvdr1 kernel: [5.692779] [] ? printk+0x1d/0x23 May 24 13:30:22 ubuntuvdr1 kernel: [5.692789] [] ? budget_ci_attach+0x193/0xd80 [budget_ci] May 24 13:30:22 ubuntuvdr1 kernel: [5.692800] [] ? saa7146_init_one+0x7dc/0x860 [saa7146] May 24 13:30:22 ubuntuvdr1 kernel: [5.692811] [] ? dma_generic_alloc_coherent+0x0/0xc0 May 24 13:30:22 ubuntuvdr1 kernel: [5.692821] [] ? local_pci_probe+0x13/0x20 May 24 13:30:22 ubuntuvdr1 kernel: [5.692827] [] ? pci_device_probe+0x68/0x90 May 24 13:30:22 ubuntuvdr1 kernel: [5.692835] [] ? really_probe+0x4d/0x140 May 24 13:30:22 ubuntuvdr1 kernel: [5.692843] [] ? pm_runtime_barrier+0x4e/0xc0 May 24 13:30:22 ubuntuvdr1 kernel: [5.692850] [] ? driver_probe_device+0x3c/0x60 May 24 13:30:22 ubuntuvdr1 kernel: [5.692857] [] ? __driver_attach+0x81/0x90 May 24 13:30:22 ubuntuvdr1 kernel: [5.692864] [] ? bus_for_each_dev+0x53/0x80 May 24 13:30:22 ubuntuvdr1 kernel: [5.692871] [] ? driver_attach+0x1e/0x20 May 24 13:30:22 ubuntuvdr1 kernel: [5.692877] [] ? __driver_attach+0x0/0x90 May 24 13:30:22 ubuntuvdr1 kernel: [5.692884] [] ? bus_add_driver+0xd5/0x280 May 24 13:30:22 ubuntuvdr1 kernel: [5.692890] [] ? pci_device_remove+0x0/0x40 May 24 13:30:22 ubuntuvdr1 kernel: [5.692897] [] ? driver_register+0x6a/0x130 May 24 13:30:22 ubuntuvdr1 kernel: [5.692903] [] ? __pci_register_driver+0x45/0xb0 May 24 13:30:22 ubuntuvdr1 kernel: [5.692913] [] ? saa7146_register_extension+0x53/0x90 [saa7146] May 24 13:30:22 ubuntuvdr1 kernel: [5.692923] [] ? budget_ci_init+0xd/0xf [budget_ci] May 24 13:30:22 ubuntuvdr1 kernel: [5.692929] [] ? do_one_initcall+0x31/0x190 May 24 13:30:22 ubuntuvdr1 kernel: [5.692937] [] ? budget_ci_init+0x0/0xf [budget_ci] May 24 13:30:22 ubuntuvdr1 kernel: [5.692945] [] ? sys_init_module+0xb0/0x210 May 24 13:30:22 ubuntuvdr1 kernel: [5.692951] [] ? syscall_call+0x7/0xb May 24 13:30:22 ubuntuvdr1 kernel: [5.692956] Cod
Re: [PATCH] drivers/media/dvb/dvb-usb/dib0700: CodingStyle fixes
On Mon, May 24, 2010 at 05:23:05PM +0200, Daniel Mack wrote: > Signed-off-by: Daniel Mack > Cc: Wolfram Sang > Cc: Mauro Carvalho Chehab > Cc: Jiri Slaby > Cc: Dmitry Torokhov > Cc: Devin Heitmueller > Cc: linux-media@vger.kernel.org Not sure how I got on the list but chnages look good to me. Thanks. -- Dmitry -- 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 v2] video/saa7134: change dprintk() to i2cdprintk()
The problem is that dprintk() dereferences "dev" which is null here.
The i2cdprintk() uses "ir" so that's OK.
Also removed a duplicated break statement.
Signed-off-by: Dan Carpenter
---
v2: Jean Delvare suggested that I use i2cdprintk() instead of modifying
dprintk().
diff --git a/drivers/media/video/saa7134/saa7134-input.c
b/drivers/media/video/saa7134/saa7134-input.c
index e5565e2..7691bf2 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -141,8 +141,8 @@ static int get_key_flydvb_trio(struct IR_i2c *ir, u32
*ir_key, u32 *ir_raw)
struct saa7134_dev *dev = ir->c->adapter->algo_data;
if (dev == NULL) {
- dprintk("get_key_flydvb_trio: "
-"gir->c->adapter->algo_data is NULL!\n");
+ i2cdprintk("get_key_flydvb_trio: "
+ "gir->c->adapter->algo_data is NULL!\n");
return -EIO;
}
@@ -195,8 +195,8 @@ static int get_key_msi_tvanywhere_plus(struct IR_i2c *ir,
u32 *ir_key,
/* is needed to access GPIO. Used by the saa_readl macro. */
struct saa7134_dev *dev = ir->c->adapter->algo_data;
if (dev == NULL) {
- dprintk("get_key_msi_tvanywhere_plus: "
- "gir->c->adapter->algo_data is NULL!\n");
+ i2cdprintk("get_key_msi_tvanywhere_plus: "
+ "gir->c->adapter->algo_data is NULL!\n");
return -EIO;
}
@@ -815,7 +815,6 @@ int saa7134_input_init1(struct saa7134_dev *dev)
mask_keyup = 0x02;
polling = 50; /* ms */
break;
- break;
}
if (NULL == ir_codes) {
printk("%s: Oops: IR config error [card=%d]\n",
--
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] drivers/media/dvb/dvb-usb/dib0700: CodingStyle fixes
On Mon, May 24, 2010 at 08:56:24AM -0700, Dmitry Torokhov wrote: > On Mon, May 24, 2010 at 05:23:05PM +0200, Daniel Mack wrote: > > Signed-off-by: Daniel Mack > > Cc: Wolfram Sang > > Cc: Mauro Carvalho Chehab > > Cc: Jiri Slaby > > Cc: Dmitry Torokhov > > Cc: Devin Heitmueller > > Cc: linux-media@vger.kernel.org > > Not sure how I got on the list but chnages look good to me. get_maintainer.pl :) Daniel -- 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: ideal DVB-C PCI/e card? [linux-media]
Anyone? Thank-you! On 22/05/10, Jed wrote: Hi All, I put this one out there 3-weeks ago Just putting it out one last time to hear other peoples thoughts. I was wondering if anyone can recommend a decent PCI/e DVB-C tuner? Ideally it'd be dual DVB-C, the only one I've found is more than dual DVB-C & is far too expensive. I guess that's the reality of the market right now... I'm subscribed to a PayTV provider here in Australia that uses an encryption scheme called NDS or Videoguard2. So I'll also need the right card reader and combo of software in order to decrypt and then capture. This stuff I can mostly work out for myself... But if you have any knowledge or experience in that area, then I'd be most appreciative if you can share. As it definitely isn't for technical minnows! Oh and in case you're worried, doing this sort of thing is not -yet- illegal in Australia. It may be soon though, thanks to the FTA our former Prime Minister established with the U.S. All the best, Jed -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch v2] video/saa7134: change dprintk() to i2cdprintk()
Hi Dan,
On Mon, 24 May 2010 17:59:36 +0200, Dan Carpenter wrote:
> The problem is that dprintk() dereferences "dev" which is null here.
> The i2cdprintk() uses "ir" so that's OK.
>
> Also removed a duplicated break statement.
Mixing two unrelated fixes in the same patch is a bad idea. Here, the
replacement of dprintk() with i2cdprintk() fixes a potential NULL
pointer dereference, this might be worth backporting to stable kernel
series. The double break, OTOH, can't cause any harm, it's a simple
clean-up. So separate patches would be preferable.
>
> Signed-off-by: Dan Carpenter
> ---
> v2: Jean Delvare suggested that I use i2cdprintk() instead of modifying
> dprintk().
>
> diff --git a/drivers/media/video/saa7134/saa7134-input.c
> b/drivers/media/video/saa7134/saa7134-input.c
> index e5565e2..7691bf2 100644
> --- a/drivers/media/video/saa7134/saa7134-input.c
> +++ b/drivers/media/video/saa7134/saa7134-input.c
> @@ -141,8 +141,8 @@ static int get_key_flydvb_trio(struct IR_i2c *ir, u32
> *ir_key, u32 *ir_raw)
> struct saa7134_dev *dev = ir->c->adapter->algo_data;
>
> if (dev == NULL) {
> - dprintk("get_key_flydvb_trio: "
> - "gir->c->adapter->algo_data is NULL!\n");
> + i2cdprintk("get_key_flydvb_trio: "
> +"gir->c->adapter->algo_data is NULL!\n");
> return -EIO;
> }
>
> @@ -195,8 +195,8 @@ static int get_key_msi_tvanywhere_plus(struct IR_i2c *ir,
> u32 *ir_key,
> /* is needed to access GPIO. Used by the saa_readl macro. */
> struct saa7134_dev *dev = ir->c->adapter->algo_data;
> if (dev == NULL) {
> - dprintk("get_key_msi_tvanywhere_plus: "
> - "gir->c->adapter->algo_data is NULL!\n");
> + i2cdprintk("get_key_msi_tvanywhere_plus: "
> +"gir->c->adapter->algo_data is NULL!\n");
> return -EIO;
> }
>
> @@ -815,7 +815,6 @@ int saa7134_input_init1(struct saa7134_dev *dev)
> mask_keyup = 0x02;
> polling = 50; /* ms */
> break;
> - break;
> }
> if (NULL == ir_codes) {
> printk("%s: Oops: IR config error [card=%d]\n",
Acked-by: Jean Delvare
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Mon May 24 19:00:22 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14873:b576509ea6d2 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 4fcfa8824391ef0f9cff82122067f31c6d920921 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-rc7-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-rc7-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.34-rc7-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-rc7-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-rc7-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc7-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-rc7-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-rc7-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-rc7-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The 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
business email lists for sale
Here's some of the healthcare lists we have: Alternative Medicine - 1,141,602 total records with 36,320 emails and 38.935 fax numbers Dentists - 164k records, 45k emails, 77k fax numbers Psychologists - 272,188 records and 9,874 emails Theres many more too, just send me an email here for additional info/samples: loretta.co...@inspiresuccess.in Send email to disapp...@inspiresuccess.in for deleted status -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] Add the viafb video capture driver
On Sun, 23 May 2010 09:51:47 -0300 Mauro Carvalho Chehab wrote: > The driver is OK to my eyes. I just found 2 minor coding style issues. > it is ok to me if you want to sent it via your git tree. > > Acked-by: Mauro Carvalho Chehab Great, thanks for taking a look! All of the precursor stuff is in mainline now, so it can go via whatever path. I'll just go ahead and request a pull in the near future unless somebody objects. > > + .sizeimage = VGA_WIDTH*VGA_HEIGHT*2, > > CodingStyle: please use spaces between values/operators. Not sure why, but > newer versions of checkpatch.pl don't complain anymore on some cases. Interesting...for all of my programming life I've left out spaces around multiplicative operators - a way of showing that they bind more tightly than the additive variety. I thought everybody else did that too. CodingStyle agrees with you, though; I'll append a patch fixing these up. Learn something every day... Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/5] Add the viafb video capture driver
Jonathan Corbet wrote: > On Sun, 23 May 2010 09:51:47 -0300 > Mauro Carvalho Chehab wrote: > >> The driver is OK to my eyes. I just found 2 minor coding style issues. >> it is ok to me if you want to sent it via your git tree. >> >> Acked-by: Mauro Carvalho Chehab > > Great, thanks for taking a look! > > All of the precursor stuff is in mainline now, so it can go via whatever > path. I'll just go ahead and request a pull in the near future unless > somebody objects. OK. >>> + .sizeimage = VGA_WIDTH*VGA_HEIGHT*2, >> CodingStyle: please use spaces between values/operators. Not sure why, but >> newer versions of checkpatch.pl don't complain anymore on some cases. > > Interesting...for all of my programming life I've left out spaces around > multiplicative operators - a way of showing that they bind more tightly > than the additive variety. I thought everybody else did that too. > CodingStyle agrees with you, though; I'll append a patch fixing these up. We all have some sort of different CodingStyle that were inherited from previous programming practices... I used to just not add any space at all at expressions, as C is a compact language, and I was a bit lazy ;) Yet, when reviewing lots of code, those spaces help to read a code quicker than without. Not sure why, but my guess is that the brain can do a faster parsing when the words are separated from operators. Or maybe it is just because it is easier to parse patches when everybody uses the same Coding Style. > Learn something every day... Very true ;) -- Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xc5000, rework xc_write_reg
Hi Devin > On Tue, May 18, 2010 at 3:30 AM, Dmitri Belimov > wrote: > > Hi > > > > Rework xc_write_reg function for correct read register of the > > xc5000. It is very useful for tm6000. > > > > Tested for tm6000 and for saa7134 works well. > > Hi Dmitri, > > I've put this on my list of patches to review. My concern is that the > xc_wait logic is pretty nasty since it's related to timing of the bus > (it took several weeks as well as a dozen emails with the people at > Xceive), and hence I am loathed to change it since it took quite a bit > of time to test against all the different cards that use xc5000 (and > in some cases there were bugs exposed in various bridge's i2c > implementations). > > That said, I think I actually did attempt to implement a patch > comparable to what you did here, but I backed it out for some reason. > I will need to review my trees and my notes to see what the rationale > was for doing such. Ok. I can test your solution on our hardware. XC5000+SAA7134 XC5000+TM6010 With my best regards, Dmitry. > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] Driver for the i.MX2x CMOS Sensor Interface
On Mon, May 24, 2010 at 04:20:38PM +0300, Baruch Siach wrote: > This series contains a soc_camera driver for the i.MX25/i.MX27 CSI device, and > platform code for the i.MX25 and i.MX27 chips. This driver is based on a > driver for i.MX27 CSI from Sascha Hauer, that Alan Carvalho de Assis has > posted in linux-media last December[1]. I tested the mx2_camera driver on the > i.MX25 PDK. Sascha Hauer has tested a earlier version of this driver on an > i.MX27 based board. I included in this version some fixes from Sascha that > enable i.MX27 support. > > [1] https://patchwork.kernel.org/patch/67636/ > > Changes v1 -> v2 > Addressed the comments of Guennadi Liakhovetski except from the following: > > 1. The mclk_get_divisor implementation, since I don't know what this code >is good for I'll have a look at this soon. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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
