Re: [PATCH 1/10 - v2] vpfe capture bridge driver for DM355 and DM6446
On Tuesday 16 June 2009 16:26:05 Karicheri, Muralidharan wrote: Hans, Thanks for the response. snip Polarities have to be set for each side, that's correct. The other parameters are common for both. Although I can think of scenarios where the bus width can differ between host and subdev (e.g. subdev sends data on 8 pins and the host captures on 10 with the least significant two pins pulled low). But that's probably really paranoid of me :-) [MK] You are right on width. The MT9T001/31 sensor has 10 bits and MT9P031 has 12 bits, but on DM355 we the vpfe will take in only 10 bits and on DM365 it takes 12 bits. But this is applicable only on the host (vpfe) side though (at least in this case) , not on sub device side. Can you post your latest proposal for the s_bus op? I propose a few changes: the name of the struct should be something like v4l2_bus_settings, the master/slave bit should be renamed to something like 'host_is_master', and we should have two widths: subdev_width and host_width. That way the same structure can be used for both host and subdev, unless some of the polarities are inverted. In that case you need to make two structs, one for host and one for the subdev. It is possible to add info on inverters to the struct, but unless inverters are used a lot more frequently than I expect I am inclined not to do that at this time. snip First of all, this isn't a blocking issue at all. This is more a nice-to-have. The reason I mentioned it is because of how we use this (or the dm646x to be precise) at my work: the dm646x is connected to our FPGA so we had to make dummy encoder/decoder drivers to allow it to work with that driver. What made that somewhat annoying is that those dummy drivers really didn't do anything since the FPGA isn't programmed from the linux kernel at all. So we have basically dead code in our kernel just to satisfy a dm646x driver requirement. And you are right: a subdev is bus independent, so it is perfectly possible to make a dummy subdev instead. The key phrase was really 'doesn't require any setup'. It would be nice to be able to use this driver 'standalone' without requiring a subdev. Something to think about. And apologies for my poor review comment, that was phrased rather badly. [MK] This is the first version of the driver and I assure you that there are opportunities to improve the driver as we add more features. Since many of the other activities like adding camera interface, supporting resizer/previewer are dependent on this, it is important for us to get this to the kernel tree as quickly as possible. So I would prefer to keep it as is now and change it part of later patches. If this can go in 2.6.31, that will be really great. It's no problem to keep this as is. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: [PULL] generic image bounds setting and alignment function
On Tue, 16 Jun 2009, Trent Piepho wrote:
On Tue, 16 Jun 2009, Guennadi Liakhovetski wrote:
01/14: compat: handle __fls
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=c4b55ce6c273
02/14: v4l2: Create helper function for bounding and aligning images
http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=b4d3ec8d363d
I am sorry, I will not bother with saving, reformatting, pasting... Just
wanted to ask about this place:
I guess you do not use Mercurial like all other v4l-dvb developers?
I do use hg, though not for development, but for interacting with all
other v4l-dvb developers
Because you are making a big deal about a simple operation than can be done
with a few keystrokes. If I wanted this patch quoted in my editor, I can
simply type: !!cd ~/v4l-dvb ; hg export b4d3ec8d363d | sed 's/^/ /'
No, typing this is not a big deal, as you say. But I do not understand
_wny_ everyone, wishing to review / comment on your patches has to do
that. And another problem of your approach you confirm yourself in this
post:
That is less then you wrote to complain how about how hard this is for you.
+ if (walign + halign salign) {
+ /* Max walign where there is still a valid width */
+ unsigned int wmaxa = __fls(wmax ^ (wmin - 1));
I cannot follow correctness of the above, sorry. Take a simple example:
wmax=0x7f, wmin=7, wmaxa = __fls(0x7f ^ 6) = __fls(0x79) = 0. And the
comment says it's the maximum walign where there is still a valid width.
What am I missing?
What you are missing is __fls vs __ffs. __fls() finds the _last_ set bit.
In this case __fls(0x79) = 6. Which is correct as 1 6 = 0x40, and there
is a multiple of 0x40 between 0x7f and 7, while there are no multiples of
the next higher alignment, 0x80, between 0x7f and 7.
Right, indeed, for some reason I swapped fls and ffs in my head. Thanks
for explaining.
In a more difficult example, wmax=0x7f and wmin=0x71, the largest alignment
possible is 1 3 == 0x08. The next higher alignment, 0x10, will not work
as 0x70 is too small and 0x80 is too large. __fls(0x7f ^ 0x70) =
__fls(0x0f) = 3.
+
+ /* up the smaller alignment until we have enough */
+ do {
+ if (walign = halign walign wmaxa) {
Thank you for bringing this code up again, as I now realize there is a bug
here. It doesn't check if halign is below hmaxa, or even calculate hmaxa.
I thought this would be ok because the code isn't designed to handle
impossible constraints. But it might increase halign too much when it's
possible to satisfy the salign requirement by increasing walign.
See? Now hg will have two patches, which Mauro will then have to merge
into one when exporting to git, and which then will be very difficult to
trace back from git to its hg origins. Although, once the code is in git,
who will ever want to look at its hgorigin?... And this happens because
everyone gets to see and review your patches only when they are already in
your external repository ready to be pulled by the maintainer.
So, there are two problems here: _how_ your patches have to be reviewed
and _when_ they get to be seen.
Thanks
Guennadi
---
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
PULL request - http://linuxtv.org/hg/~hgoede/gspca
Hi Mauro, Can you please pull from: http://linuxtv.org/hg/~hgoede/gspca I've asked JF Moine a couple of days ago if he wanted this to go through his tree or directly, but have not received an answer, as there is one important bugfix in this tree I'm now asking you to pull this directly. For the following: 1) Fix a NULL pointer dereference introduced by changes from your recent pull from JF Moine's tree 2) Add support for ov511(+) and ov518(+) cams 3) Various bugfixes for ov519 based cams Regards, Hans p.s. Given that I'm currently doing quite a bit of gspca work I think its best for the future if I just send pull requests to you directly is that ok ? -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-misc
On Tuesday 16 June 2009 02:03:54 Mauro Carvalho Chehab wrote:
Em Mon, 15 Jun 2009 23:35:59 +0200
Hans Verkuil hverk...@xs4all.nl escreveu:
By looking on this patch, it is obfuscating the function even more.
Creating more confusion on it, due to some reasons:
1) The name kernel number doesn't seem much appropriate. Any number
used in kernel can be called as a kernel number.
Actually, that is apparently what the number X is called in a node like
/dev/videoX. I didn't make up that term, it's what I found when reading
'man udev'. Since udev deals extensively with these concepts I borrowed
the udev terminology for this. If someone knows a better word, then I'm
happy to use that.
Ah, now I see where you got this. Yet, this is what man udev says:
$number, %n
The kernel number for this device. For example, ’sda3’ has
kernel number of ’3’
$major, %M
The kernel major number for the device.
$minor %m
The kernel minor number for the device.
See, on all all tree is calls kernel [something] number. Seems
confusing enough to avoid those names at the V4L2 core. Also, even the
man needed to give an example, showing that this nomenclature may not be
widely understood.
Maybe we can just call it as dev_number and properly explain its
meaning.
That's said, the logic of when minor range is not fixed seems broken,
as it will change only an internal representation of the device. So
the module parameters that reflect at nr var won't work as
expected.
No, they work exactly as expected: if you set nr to 1 then you get a
/dev/video1 node no matter what the FIXED_MINOR_RANGES setting is
(provided there isn't already a /dev/video1 node, in which case it will
find the next available kernel number).
So, the current code seems too complex and broken.
No, it's neither too complex nor broken, although it clearly needs
still more comments.
The code is complex. For example, take a look at this:
#ifdef CONFIG_VIDEO_FIXED_MINOR_RANGES
...
#else
/* The kernel number and minor numbers are independent */
for (i = 0; i VIDEO_NUM_DEVICES; i++)
if (video_device[i] == NULL)
break;
if (i == VIDEO_NUM_DEVICES) {
..
return -ENFILE;
}
#endif
vdev-minor = i + minor_offset;
...
/* Should not happen since we thought this minor was free */
WARN_ON(video_device[vdev-minor] != NULL);
when !FIXED_MINOR_RANGES, you're return if all video_device[i] are used.
Then, you do a WARN_ON(video_device[i + minor_offset]) instead of
video_device[i].
People need to look back at the code to identify that minor_offset is
equal to 0 when !FIXED_MINOR_RANGES.
Also, by letting the function to allocate a device even when video_device
!= NULL seems broken. It should instead call WARN and return with
-EINVAL.
That's better, yes. I remember that at the time I wasn't sure what to do
here and I agree I made the wrong choice.
The presence of the #if's, plus the high number of phases at the same
function make it harder to read and understand. The code will be more
readable if we break it into a few static functions (that will be inline
anyway, due to gcc optimizer).
Just as reference, the behavior before changeset 9133 is:
switch (type) {
case VFL_TYPE_GRABBER:
base = MINOR_VFL_TYPE_GRABBER_MIN;
...
}
i = base + nr;
vfd-minor = i;
where nr is auto-selected for negative values, or just used above
otherwise.
That's said, IMO, we need to rework at the function, making it
simpler, and fixing the behavior where the user wants to select a
minor.
The user doesn't select a minor number, the user selects a kernel
number. With udev minor numbers have become completely uninteresting
and unless FIXED_MINOR_RANGES is set each node will be assigned the
first free minor number.
OK, now I see what you're meaning.
With respect to the code, I still think it does too much into just one
function. It may make sense to break the code into more functions to
allow an easier understanding.
I'll attempt that this weekend.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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
Convert cpia driver to v4l2, drop parallel port version support?
Hi, I recently have been bying second hand usb webcams left and right one of them (a creative unknown model) uses the cpia1 chipset, and works with the v4l1 driver currently in the kernel. One of these days I would like to convert it to a v4l2 driver using gspca as basis, this however will cause us to use parallel port support (that or we need to keep the old code around for the parallel port version). I personally think that loosing support for the parallel port version is ok given that the parallel port itslef is rapidly disappearing, what do you think ? Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] generic image bounds setting and alignment function
On Tue, 16 Jun 2009, Trent Piepho wrote:
On Tue, 16 Jun 2009, Mauro Carvalho Chehab wrote:
Em Tue, 16 Jun 2009 17:57:20 +0200 (CEST)
Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu:
On Sat, 30 May 2009, Trent Piepho wrote:
+ if (walign + halign salign) {
+ /* Max walign where there is still a valid width */
+ unsigned int wmaxa = __fls(wmax ^ (wmin - 1));
I cannot follow correctness of the above, sorry. Take a simple example:
wmax=0x7f, wmin=7, wmaxa = __fls(0x7f ^ 6) = __fls(0x79) = 0. And the
comment says it's the maximum walign where there is still a valid width.
What am I missing?
+
+ /* up the smaller alignment until we have enough */
+ do {
+ if (walign = halign walign wmaxa) {
As I'm still cooking the patches, I prefer to postpone the align ones until
we
are comfortable with them.
Trent,
Could you please take a look on the above comments
There is no bug with the wmaxa code, but there is a different bug
elsewhere.
Please pull from http://linuxtv.org/hg/~tap/fix
for the following changeset:
01/01: v4l2: Fix flaw in alignment code
http://linuxtv.org/hg/~tap/fix?cmd=changeset;node=4ef7fb102b6c
/* up the smaller alignment until we have enough */
do {
- if (walign = halign walign wmaxa) {
+ if (halign = hmaxa ||
+ (walign = halign walign wmaxa)) {
Do I understand it right now, that as soon as your halign now reaches
hmaxa, you'll stop incrementing halign and then keep incrementing walign
even beyond wmaxa?...
*w = clamp_align(*w, wmin, wmax, walign + 1);
walign = __ffs(*w);
} else {
Thanks
Guennadi
---
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: Convert cpia driver to v4l2, drop parallel port version support?
Hi, I recently have been bying second hand usb webcams left and right one of them (a creative unknown model) uses the cpia1 chipset, and works with the v4l1 driver currently in the kernel. One of these days I would like to convert it to a v4l2 driver using gspca as basis, this however will cause us to use parallel port support (that or we need to keep the old code around for the parallel port version). I personally think that loosing support for the parallel port version is ok given that the parallel port itslef is rapidly disappearing, what do you think ? I agree wholeheartedly. If we remove pp support, then we can also remove the bw-qcam and c-qcam drivers since they too use the parallel port. BTW, I also have a cpia1 camera available for testing. I can also test ov511 (I saw that you added support for that to gspca). Ditto for the stv680 and w9968cf. Note that I can mail these devices to you if you want to work on integrating them into gspca. I'm pretty sure I won't have time for that myself. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] adding support for setting bus parameters in sub device
On Mon, Jun 15, 2009 at 12:33 AM, Guennadi Liakhovetskig.liakhovet...@gmx.de wrote: On Fri, 12 Jun 2009, Hans Verkuil wrote: On Friday 12 June 2009 14:59:03 Guennadi Liakhovetski wrote: On Fri, 12 Jun 2009, Hans Verkuil wrote: 1. it is very unusual that the board designer has to mandate what signal polarity has to be used - only when there's additional logic between the capture device and the host. So, we shouldn't overload all boards with this information. Board-code authors will be grateful to us! I talked to my colleague who actually designs boards like that about what he would prefer. His opinion is that he wants to set this himself, rather than leave it as the result of a software negotiation. It simplifies verification and debugging the hardware, and in addition there may be cases where subtle timing differences between e.g. sampling on a falling edge vs rising edge can actually become an important factor, particularly on high frequencies. Let me guess, your coworker is a hardware designer? Letting hardware people do hardware design is usually a good idea, but I'm yet to see good software written by hardware people. =) I'd say this is different. You're talking about cases where you _want_ to be able to configure it explicitly, I am saying you do not have to _force_ all to do this. Now, this selection only makes sense if both are configurable, right? In this case, e.g., pxa270 driver does support platform-specified preference. So, if both the host and the client can configure either polarity in the software you _can_ still specify the preferred one in platform data and it will be used. I think, the ability to specify inverters and the preferred polarity should cover all possible cases. In my opinion you should always want to set this explicitly. This is not something you want to leave to chance. Say you autoconfigure this. Now someone either changes the autoconf algorithm, or a previously undocumented register was discovered for the i2c device and it can suddenly configure the polarity of some signal that was previously thought to be fixed, or something else happens causing a different polarity to be negotiated. TBH, the argumentation like someone changes the autoconf algorithm or previously undocumented register is discovered doesn't convince me. In any case, I am adding authors, maintainers and major contributors to various soc-camera host drivers to CC and asking them to express their opinion on this matter. I will not add anything else here to avoid any unfair competition:-) they will have to go a couple emails back in this thread to better understand what is being discussed here. I think automatic negotiation is a good thing if it is implemented correctly. Actually, i think modelling software after hardware is a good thing and from that perspective the soc_camera was (and still is) a very good fit for our on-chip SoC. Apart from host/sensor separation, the main benefits in my mind are autonegotiation and separate configuration for camera sensor, capture interface and board. I don't mind doing the same outside soc_camera, and I agree with Hans that in some cases it's nice to hard code and skip the magic negotiation. I'm however pretty sure the soc_camera allows hard coding though, so in that case you get the best of two worlds. Cheers, / magnus -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] adding support for setting bus parameters in sub device
On Tue, Jun 16, 2009 at 11:33 PM, Karicheri, Muralidharanm-kariche...@ti.com wrote: snip [MK]In that case can't the driver just ignore the field polarity? I assume that drivers implement the parameter that has support in hardware. So it is not an issue. No, because the same driver runs on hardware that also has the field signal. So we need to be able to give information about which signals that the board actually implement. We already do this with the soc_camera framework and it is working just fine. Hardware with field signal used (driver use polarity from platform data and set it in the hardware) Hardware with field signal not used (In this case, even though the driver sets it in the hardware, it is not really used in the hardware design and hence is a don't care. right? So I don't see why it matters. Maybe I'm misunderstanding what you are trying to do. But how can the camera sensor driver check if the field signal is present or not? The camera sensor driver may need information if a pin is present or not for some decision? Perhaps for hardware configuration? A good example IMO is the tw9910 driver and the mpout signal. Right now the mpout configuration is part of the platform data, but maybe it would make more sense to allow the driver to check if field is used on the platform and if so configure the pin accordingly. / magnus -- 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] [09051_49] Siano: smscore - upgrade firmware loading engine
On Tue, Jun 16, 2009 at 7:44 PM, Mauro Carvalho
Chehabmche...@infradead.org wrote:
Em Tue, 16 Jun 2009 15:39:01 +0300
Udi Atar u...@siano-ms.com escreveu:
The README.patches file in v4l-dvb clearly states that it is OK to use
version checking to allow backporting.
k) Sometimes it is necessary to introduce some testing code inside a
module or remove parts that are not yet finished. Also, compatibility
tests may be required to provide backporting.
To allow compatibility tests, linux/version.h is automatically
included by the building system. This allows adding tests like:
#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16)
#include linux/mutex.h
#else
#include asm/semaphore.h
#endif
The patch allows older version of the kernel, and embedded platforms, that
choose not to include the request firmware mechanism to continue working
with the Siano driver.
I don't see a big issue with this, provided that this won't affect the
upstream driver.
As for the SMS_HOSTLIB_SUBSYS, the Siano driver supports standards which are
not currently implemented in V4L (i.e. CMMB). I see no reason why we should
create a duplicate driver for DVB-T and CMMB, if the codebase is exactly the
same.
The proper way is to add support for those standards at DVB API, instead of
using a proprietary API.
In order to keep the merging process of the pending patches, I suggest you to
remove the the SMS_HOSTLIB_SUBSYS part from this patch and re-submit the
pending ones up to the point where the only pending issue to sync your
codebase
with kernel being the API for those non-supported standards. After that, we
can
discuss the API improvement needs to support the missing standards.
Best regards,
Udi Atar
-Original Message-
From: linux-media-ow...@vger.kernel.org
[mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Michael Krufky
Sent: Tuesday, May 19, 2009 7:24 PM
To: Uri Shkolnik
Cc: LinuxML; Mauro Carvalho Chehab
Subject: Re: [PATCH] [09051_49] Siano: smscore - upgrade firmware loading
engine
On Tue, May 19, 2009 at 11:43 AM, Uri Shkolnik uri...@yahoo.com wrote:
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1242748115 -10800
# Node ID 4d75f9d1c4f96d65a8ad312c21e488a212ee58a3
# Parent cfb4106f3ceaee9fe8f7e3acc9d4adec1baffe5e
[09051_49] Siano: smscore - upgrade firmware loading engine
From: Uri Shkolnik u...@siano-ms.com
Upgrade the firmware loading (download and switching) engine.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r cfb4106f3cea -r 4d75f9d1c4f9
linux/drivers/media/dvb/siano/smscoreapi.c
--- a/linux/drivers/media/dvb/siano/smscoreapi.c Tue May 19
18:38:07 2009 +0300
+++ b/linux/drivers/media/dvb/siano/smscoreapi.c Tue May 19
18:48:35 2009 +0300
@@ -28,7 +28,7 @@
#include linux/dma-mapping.h
#include linux/delay.h
#include linux/io.h
-
+#include linux/uaccess.h
#include linux/firmware.h
#include linux/wait.h
#include asm/byteorder.h
@@ -36,7 +36,13 @@
#include smscoreapi.h
#include sms-cards.h
#include smsir.h
-#include smsendian.h
+#define MAX_GPIO_PIN_NUMBER 31
+
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 10)
+#define REQUEST_FIRMWARE_SUPPORTED
+#else
+#define DEFAULT_FW_FILE_PATH /lib/firmware
+#endif
static int sms_dbg;
module_param_named(debug, sms_dbg, int, 0644);
@@ -459,8 +465,6 @@ static int smscore_init_ir(struct smscor
msg-msgData[0] = coredev-ir.controller;
msg-msgData[1] = coredev-ir.timeout;
- smsendian_handle_tx_message(
- (struct SmsMsgHdr_ST2 *)msg);
rc = smscore_sendrequest_and_wait(coredev,
msg,
msg-xMsgHeader. msgLength,
coredev-ir_init_done);
@@ -486,12 +490,16 @@ static int smscore_init_ir(struct smscor
*/
int smscore_start_device(struct smscore_device_t *coredev)
{
- int rc = smscore_set_device_mode(
- coredev,
smscore_registry_getmode(coredev-devpath));
+ int rc;
+
+#ifdef REQUEST_FIRMWARE_SUPPORTED
+ rc = smscore_set_device_mode(coredev, smscore_registry_getmode(
+ coredev-devpath));
if (rc 0) {
- sms_info(set device mode faile , rc %d, rc);
+ sms_info(set device mode failed , rc %d, rc);
return rc;
}
+#endif
kmutex_lock(g_smscore_deviceslock);
@@ -632,11 +640,14 @@ static int smscore_load_firmware_from_fi
Re: [PATCH] adding support for setting bus parameters in sub device
On Mon, Jun 15, 2009 at 12:33 AM, Guennadi Liakhovetskig.liakhovet...@gmx.de wrote: On Fri, 12 Jun 2009, Hans Verkuil wrote: On Friday 12 June 2009 14:59:03 Guennadi Liakhovetski wrote: On Fri, 12 Jun 2009, Hans Verkuil wrote: 1. it is very unusual that the board designer has to mandate what signal polarity has to be used - only when there's additional logic between the capture device and the host. So, we shouldn't overload all boards with this information. Board-code authors will be grateful to us! I talked to my colleague who actually designs boards like that about what he would prefer. His opinion is that he wants to set this himself, rather than leave it as the result of a software negotiation. It simplifies verification and debugging the hardware, and in addition there may be cases where subtle timing differences between e.g. sampling on a falling edge vs rising edge can actually become an important factor, particularly on high frequencies. Let me guess, your coworker is a hardware designer? Letting hardware people do hardware design is usually a good idea, but I'm yet to see good software written by hardware people. =) I agree. That's why I'm doing the software part :-) I'd say this is different. You're talking about cases where you _want_ to be able to configure it explicitly, I am saying you do not have to _force_ all to do this. Now, this selection only makes sense if both are configurable, right? In this case, e.g., pxa270 driver does support platform-specified preference. So, if both the host and the client can configure either polarity in the software you _can_ still specify the preferred one in platform data and it will be used. I think, the ability to specify inverters and the preferred polarity should cover all possible cases. In my opinion you should always want to set this explicitly. This is not something you want to leave to chance. Say you autoconfigure this. Now someone either changes the autoconf algorithm, or a previously undocumented register was discovered for the i2c device and it can suddenly configure the polarity of some signal that was previously thought to be fixed, or something else happens causing a different polarity to be negotiated. TBH, the argumentation like someone changes the autoconf algorithm or previously undocumented register is discovered doesn't convince me. In any case, I am adding authors, maintainers and major contributors to various soc-camera host drivers to CC and asking them to express their opinion on this matter. I will not add anything else here to avoid any unfair competition:-) they will have to go a couple emails back in this thread to better understand what is being discussed here. I think automatic negotiation is a good thing if it is implemented correctly. Actually, i think modelling software after hardware is a good thing and from that perspective the soc_camera was (and still is) a very good fit for our on-chip SoC. Apart from host/sensor separation, the main benefits in my mind are autonegotiation and separate configuration for camera sensor, capture interface and board. I don't mind doing the same outside soc_camera, and I agree with Hans that in some cases it's nice to hard code and skip the magic negotiation. I'm however pretty sure the soc_camera allows hard coding though, so in that case you get the best of two worlds. It is my strong opinion that while autonegotiation is easy to use, it is not a wise choice to make. Filling in a single struct with the bus settings to use for each board-subdev combination (usually there is only one) is simple, straight-forward and unambiguous. And I really don't see why that should take much time at all. And I consider it a very good point that the programmer is forced to think about this for a bit. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: How to handle v4l1 - v4l2 driver transition
Em Wed, 17 Jun 2009 08:54:20 +0200 Hans de Goede hdego...@redhat.com escreveu: Hi all, I've recently been working on adding support for cams with the ov511(+) and ov518(+) to the gspca ov519 driver. I'm happy to announce that work is finished, see: http://linuxtv.org/hg/~hgoede/gspca And the pull request I just send. This does lead to the question what to do with the existing in kernel v4l1 ov511 driver, which claims to support these 2 bridges too (but since the decompression code has been removed actually only works with the 511 in uncompressed mode). It is clear that the ov518 usb-id's should be removed from the ov511 driver. But that still leaves the ov511 support, we could just completely remove the ov511 driver, as the code in gspca should cover all supported devices (and his been tested with a few). However the downside of removing it is that people who used to have a working ov511 setup now will need to have a (very recent) libv4l to keep their setup working. So I guess that the best way forward is to mark the driver as deprecated now and remove it in say 2 releases? It seems a good strategy to me, provided that all USB ID's found at the original ov511 are also present on gspca. If so, please send the deprecate patch as well. I'll add it on my -git tree. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html 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] adding support for setting bus parameters in sub device
On Wed, 17 Jun 2009, Hans Verkuil wrote: It is my strong opinion that while autonegotiation is easy to use, it is not a wise choice to make. Filling in a single struct with the bus settings to use for each board-subdev combination (usually there is only one) is simple, straight-forward and unambiguous. And I really don't see why that should take much time at all. And I consider it a very good point that the programmer is forced to think about this for a bit. Ok, my opinion is, that we should keep autonegotiation, but if you like, we can print a BIG-FAT-WARNING if both polarities are supported and no platform preference is set. I think, we've heard all opinions, unless someone would like to add something? Would it be fair to ask Mauro to make a decision? Or we can just count votes (which I would obviously prefer), but I'll accept Mauro's decision too. Thanks Guennadi --- 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: OMAP patches for linux-media
Em Wed, 17 Jun 2009 08:30:13 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: On Tuesday 16 June 2009 15:40:18 Mauro Carvalho Chehab wrote: Hi Sakari and others, I'm seeing lots of patches and discussions for OMAP and DaVinci being handled at the linux-media Mailing List, as part of the development process of the open source drivers. However, it is hard to track all those discussions and be sure what patches are ready for merging and what patches are just RFC. On the development model we use here, we have driver maintainers that are responsible to discuss about improvements on their drivers. They are generally the driver authors or the one that first started submitting the patches for that driver(s). One of the roles of the driver maintainers is to collect the patches for the drivers they maintain, merge on their trees, and periodically ask the patch merge. One fundamental concept on Kernel development is the concept of Commit earlier and commit often, meaning that the better is to send small, incremental, and periodic patches, than wait until having everything done, then submit a big patch. Every time I receive a big patch I need to postpone its analysis and open a big window on my schedule to analyze it. Of course, this means to postpone it, and generally results on lots of comments going back to developer, that, in turn, will need to do lots of changes and return me back with another big patch for me to analyze again, resulting on a long period of time for merging it. As you, Sakari, was the first one that started merging the OMAP drivers, I was expecting that you would be the one that will handle the figure of the driver maintainer for OMAP. I even created you an account at linuxtv for you to create your trees there and ask me to merge from it. Unfortunately, you haven't sent me any pull requests yet along this year. This is concerning me a lot, since, at the end, I'll need to review big piles of patches and/or drivers when you decide to submit the final version. So, I decided to send you this email, c/c a random list of people that I believe are involved on the submit and/or review process of those patches, in the hope to better understand and to discuss what's happening and how can we speedup the merge process of those patches. I have proposed this before, but I'll do it again: I'm more than happy to be the official person who collects and organizes the omap and davinci patches for you and who does the initial reviews. This is effectively already the case since I've been reviewing both omap and davinci patches pretty much from the beginning. As I said before, in general the maintainer is the driver author or the first submitter. Submitting patches for me is part of maintainer's hole. It is also a maintainers responsibility to receive bug fixes and patches from other developers and deal with them. In the case where the chipset manufacturer is providing official support, it is preferred if they are also handling this task. Of course they can delegate this task to someone else. While we are still bound to mercurial, the maintainer(s) should use it for sending me pull requests, especially for a high traffic of patches like what we're having. I hope we can migrate the development model to -git, but this may still take some time. From my side, I'm ok if they prefer to delegate maintainer's task to you. I'm also ok if they want to do by themselves. As there are multiple driver sets involved (OMAP, OMAP2, OMAP3, OMAP4, DaVinci), eventually the task can be split on different maintainers, provided that I know exactly who is maintaining what drivers. Just let me know what fits better. Both the omap2/3 display driver and the davinci drivers are now very close to be ready for inclusion in the kernel as my last reviews only found some minor things. Part of the reason for the delays for both omap and davinci was that they had to be modified for v4l2_subdev, which was an absolute necessity, and because they simply needed quite a bit of work to make them suitable for inclusion in the kernel. Ok. 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
[PATCH] v4l: add cropping prototypes to struct v4l2_subdev_video_ops
Add g_crop, s_crop and cropcap methods to video v4l2-subdev operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Hans, is this all that's needed?
include/media/v4l2-subdev.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..673a4e1 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -215,6 +215,9 @@ struct v4l2_subdev_video_ops {
int (*g_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
int (*try_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
int (*s_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
+ int (*cropcap)(struct v4l2_subdev *sd, struct v4l2_cropcap *cc);
+ int (*g_crop)(struct v4l2_subdev *sd, struct v4l2_crop *crop);
+ int (*s_crop)(struct v4l2_subdev *sd, struct v4l2_crop *crop);
int (*g_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum
*fsize);
--
1.6.2.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] soc-camera: ov7670 merged multiple drivers and moved over to v4l2-subdev
Hans Verkuil wrote: On Tuesday 16 June 2009 16:45:04 Jonathan Cameron wrote: Guennadi Liakhovetski wrote: On Mon, 15 Jun 2009, Jonathan Cameron wrote: From: Jonathan Cameron ji...@cam.ac.uk OV7670 soc-camera driver. Merge of drivers from Jonathan Corbet, Darius Augulis and Jonathan Cameron Could you please, describe in more detail how you merged them? Mostly by combining the various register sets and then adding pretty much all the functionality in each of them, testing pretty much everything. Note that a lot of what was in those drivers (usually labeled as untested) simply doesn't work and is based on 'magic' register sets provided by omnivision. However, I am not sure this is the best way to go. I think, a better approach would be to take a driver currently in the mainline, perhaps, the most feature-complete one if there are several of them there, That is more or less what I've done (it's based on Jonathan Corbet's driver). Darius' driver and mine have never been in mainline. Darius' was a complete rewrite based on doc's he has under NDA. Mine was based on Jonathan Corbet's one with a few bits leveraged from a working tinyos driver for the platform I'm using (principally because Omnivision are ignoring both myself and the board supplier). convert it and its user(s) to v4l2-subdev, extend it with any features missing in it and present in other drivers, then switch users of all other ov7670 drivers over to this one, That's the problem. The only mainlined driver is specifically for an OLPC machine. The driver is tied to specific i2c device and doesn't use anything anywhere near soc-camera or v4l2-subdev. Yes, it does. ov7670.c was converted to v4l2-subdev in 2.6.30. Ah! thanks for the heads up on that. Some how I missed that entirely. While it would be nice to get a single driver working for this hardware as well as more conventional soc-camera devices, it isn't going to happen without a lot of input from someone with an olpc. The chip is interfaced through a Marvell 88alp101 'cafe' chip which does a whole host of random things alongside being video processor and taking a quick look at that would be written in a completely different fashion if it were done now (mfd with subdevices etc, v4l2-sudev) So basically in the ideal world it would happen exactly as you've suggested, but I doubt it'll happen any time soon and in the meantime there is no in kernel support for those of us using the chip on other platforms. *looks hopefully in the direction of Jonathan Corbet and other olpc owners* I have an olpc, but I still haven't had the time to setup a proper test environment on it. However, I managed to clear my backlog of reviews in the past few days so hopefully I can find some time this weekend to set it up. Cool. and finally make it work with soc-camera. This way you get a series of smaller and reviewable patches, instead of a completely new driver, that reproduces a lot of existing code but has to be reviewed anew. How does this sound? Would be fine if the original driver (or anything terribly close to it) were useable on a platform I actually have without more or less being rewritten. I can back track the driver to be as close to that as possible and still functional, but I'm not entirely sure it will make the code any easier to review and you'll loose a lot the functionality lifted from Darius' as my original drivers. The original posting I made was as close as you can reasonably get to Jonathan's original driver. http://patchwork.kernel.org/patch/12192/ At the time it wasn't really reviewed (beyond a few comments) as you were just commencing the soc-camera conversion and it made sense to wait for after that. I'm not really sure how we should proceed with this. I'm particularly loath to touch the olpc driver unless we have a reasonable number of people willing to test. The current ov7670.c driver in the 2.6.30 tree (and the v4l-dvb repository) is already v4l2_subdev based and should be reusable in other platforms, including soc-camera once that has also been converted to use v4l2_subdev. Excellent, I'll look at moving the functionality patches based on this driver and Darius' on to that then. Sorry for repeating some of your work, I somehow completely forgot your original email saying this was on it's way! Jonathan -- 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: Convert cpia driver to v4l2, drop parallel port version support?
On 06/17/2009 09:43 AM, Hans Verkuil wrote: Hi, I recently have been bying second hand usb webcams left and right one of them (a creative unknown model) uses the cpia1 chipset, and works with the v4l1 driver currently in the kernel. One of these days I would like to convert it to a v4l2 driver using gspca as basis, this however will cause us to loose parallel port support (that or we need to keep the old code around for the parallel port version). I personally think that loosing support for the parallel port version is ok given that the parallel port itself is rapidly disappearing, what do you think ? I agree wholeheartedly. If we remove pp support, then we can also remove the bw-qcam and c-qcam drivers since they too use the parallel port. Ok :) BTW, I also have a cpia1 camera available for testing. I can also test ov511 (I saw that you added support for that to gspca). Ditto for the stv680 and w9968cf. Note that I can mail these devices to you if you want to work on integrating them into gspca. I'm pretty sure I won't have time for that myself. Yes I want to work on integrating them into gspca (as time permits). If you could mail them to me that would be great! Esp the w9968cf one, once that is moved to gspca, we can get rid of the entire ovcamchip stuff (eventually it would be good to move to a model where the sensor drivers are seperated again, but I'm waiting to see what comes out of the soc / ov7660 discussion for this). I'll send my postal address in a private mail. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Convert cpia driver to v4l2, drop parallel port version support?
Em Wed, 17 Jun 2009 09:43:50 +0200 (CEST) Hans Verkuil hverk...@xs4all.nl escreveu: I recently have been bying second hand usb webcams left and right one of them (a creative unknown model) uses the cpia1 chipset, and works with the v4l1 driver currently in the kernel. One of these days I would like to convert it to a v4l2 driver using gspca as basis, this however will cause us to use parallel port support (that or we need to keep the old code around for the parallel port version). I personally think that loosing support for the parallel port version is ok given that the parallel port itslef is rapidly disappearing, what do you think ? I agree wholeheartedly. If we remove pp support, then we can also remove the bw-qcam and c-qcam drivers since they too use the parallel port. Maybe I'm too nostalgic, but those are the first V4L drivers. It would be fun to keep supporting them with V4L2 API ;) That's said, while it is probably not that hard to develop a gspca-pp driver, I'm not against removing parallel port support or even removing those drivers due to technical reasons, like the end of V4L1 drivers. By looking at the remaining V4L1 drivers, we have: ov511 - already implemented with V4L2 on gspca. Can be easily removed; se401, stv680, usbvideo, vicam - USB V4L1 drivers. IMO, it is valuable to convert them to gspca; cpia2, pwc - supports both V4L1 and V4L2 API. It shouldn't be hard to convert them to vidio_ioctl2 and remove V4L1 API. stradis - a saa7146 V4L1 only driver - I never understood this one well, since there is already another saa7146 driver running V4L2, used by mxb, hexium_gemini and hexium_orion. To make things worse, stradis, mxb and hexium_orion are registering for the same PCI device (the generic saa7146 PCI ID). If nobody volunteers to convert and test with V4L2, then maybe we can just remove it. The better conversion would probably be to use the V4L2 support at the saa7146 driver. arv - seems to be a VGA output driver - Only implements 3 ioctls: VIDIOCGCAP and VIDIOCGWIN/VIDIOCSWIN. It shouldn't be hard to convert it to V4L2. I'm not sure if this is still used in practice. bw-qcam, pms, c-qcam, cpia, w9966 - very old drivers that use direct io and/or parport; IMO, after having all USB ID's for se401, stv680, usbvideo and vicam devices supported by a V4L2 driver, we can just remove V4L1 ioctls from cpia2 and pwc, and the drivers that will still remain using only the legacy API can be dropped. Anything more converted will be a bonus 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: Convert cpia driver to v4l2, drop parallel port version support?
Em Wed, 17 Jun 2009 06:56:21 -0300 Mauro Carvalho Chehab mche...@infradead.org escreveu: Em Wed, 17 Jun 2009 09:43:50 +0200 (CEST) Hans Verkuil hverk...@xs4all.nl escreveu: I recently have been bying second hand usb webcams left and right one of them (a creative unknown model) uses the cpia1 chipset, and works with the v4l1 driver currently in the kernel. One of these days I would like to convert it to a v4l2 driver using gspca as basis, this however will cause us to use parallel port support (that or we need to keep the old code around for the parallel port version). I personally think that loosing support for the parallel port version is ok given that the parallel port itslef is rapidly disappearing, what do you think ? I agree wholeheartedly. If we remove pp support, then we can also remove the bw-qcam and c-qcam drivers since they too use the parallel port. Maybe I'm too nostalgic, but those are the first V4L drivers. It would be fun to keep supporting them with V4L2 API ;) That's said, while it is probably not that hard to develop a gspca-pp driver, I'm not against removing parallel port support or even removing those drivers due to technical reasons, like the end of V4L1 drivers. By looking at the remaining V4L1 drivers, we have: ov511 - already implemented with V4L2 on gspca. Can be easily removed; se401, stv680, usbvideo, vicam - USB V4L1 drivers. IMO, it is valuable to convert them to gspca; In time: w9968cf cpia2, pwc - supports both V4L1 and V4L2 API. It shouldn't be hard to convert them to vidio_ioctl2 and remove V4L1 API. stradis - a saa7146 V4L1 only driver - I never understood this one well, since there is already another saa7146 driver running V4L2, used by mxb, hexium_gemini and hexium_orion. To make things worse, stradis, mxb and hexium_orion are registering for the same PCI device (the generic saa7146 PCI ID). If nobody volunteers to convert and test with V4L2, then maybe we can just remove it. The better conversion would probably be to use the V4L2 support at the saa7146 driver. arv - seems to be a VGA output driver - Only implements 3 ioctls: VIDIOCGCAP and VIDIOCGWIN/VIDIOCSWIN. It shouldn't be hard to convert it to V4L2. I'm not sure if this is still used in practice. bw-qcam, pms, c-qcam, cpia, w9966 - very old drivers that use direct io and/or parport; IMO, after having all USB ID's for se401, stv680, usbvideo and vicam devices supported by a V4L2 driver, we can just remove V4L1 ioctls from cpia2 and pwc, and the drivers that will still remain using only the legacy API can be dropped. Anything more converted will be a bonus So, the must do list seems to be: se401, stv680, usbvideo, vicam and w9968cf. 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: S_FMT vs. S_CROP
On Wed, 10 Jun 2009, Hans Verkuil wrote:
On Wednesday 10 June 2009 18:02:39 Guennadi Liakhovetski wrote:
{G,S,TRY}_FMT configure output geometry in user pixels
[GS]_CROP, CROPCAP configure input window in sensor pixels
Agreed.
Now one more related question: if the driver (stack) can only scale down,
and the user has requested either a crop smaller than current fmt, or fmt
larger than current crop. What should the driver do? I can think of at
least two reasonably logical behaviours:
1. adjust the last invalid request - either enlarge crop or reduce fmt
2. give fmt preference and adjust the source rectangle if needed
Which one is prererred?
Thanks
Guennadi
---
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: Convert cpia driver to v4l2, drop parallel port version support?
Em Wed, 17 Jun 2009 09:43:50 +0200 (CEST) Hans Verkuil hverk...@xs4all.nl escreveu: I recently have been bying second hand usb webcams left and right one of them (a creative unknown model) uses the cpia1 chipset, and works with the v4l1 driver currently in the kernel. One of these days I would like to convert it to a v4l2 driver using gspca as basis, this however will cause us to use parallel port support (that or we need to keep the old code around for the parallel port version). I personally think that loosing support for the parallel port version is ok given that the parallel port itslef is rapidly disappearing, what do you think ? I agree wholeheartedly. If we remove pp support, then we can also remove the bw-qcam and c-qcam drivers since they too use the parallel port. Maybe I'm too nostalgic, but those are the first V4L drivers. It would be fun to keep supporting them with V4L2 API ;) I have a pms ISA card and it is still on my list to convert that one to V4L2. Shouldn't be difficult. It is my understanding that that is the very first v4l driver, so that should satisfy any nostalgic feelings :-) That's said, while it is probably not that hard to develop a gspca-pp driver, I'm not against removing parallel port support or even removing those drivers due to technical reasons, like the end of V4L1 drivers. By looking at the remaining V4L1 drivers, we have: ov511 - already implemented with V4L2 on gspca. Can be easily removed; se401, stv680, usbvideo, vicam - USB V4L1 drivers. IMO, it is valuable to convert them to gspca; cpia2, pwc - supports both V4L1 and V4L2 API. It shouldn't be hard to convert them to vidio_ioctl2 and remove V4L1 API. stradis - a saa7146 V4L1 only driver - I never understood this one well, since there is already another saa7146 driver running V4L2, used by mxb, hexium_gemini and hexium_orion. To make things worse, stradis, mxb and hexium_orion are registering for the same PCI device (the generic saa7146 PCI ID). If nobody volunteers to convert and test with V4L2, then maybe we can just remove it. The better conversion would probably be to use the V4L2 support at the saa7146 driver. arv - seems to be a VGA output driver - Only implements 3 ioctls: VIDIOCGCAP and VIDIOCGWIN/VIDIOCSWIN. It shouldn't be hard to convert it to V4L2. I'm not sure if this is still used in practice. bw-qcam, pms, c-qcam, cpia, w9966 - very old drivers that use direct io and/or parport; IMO, after having all USB ID's for se401, stv680, usbvideo and vicam devices supported by a V4L2 driver, we can just remove V4L1 ioctls from cpia2 and pwc, and the drivers that will still remain using only the legacy API can be dropped. Anything more converted will be a bonus I have a cpia2 device as well that I can use to test. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] v4l: add cropping prototypes to struct v4l2_subdev_video_ops
Add g_crop, s_crop and cropcap methods to video v4l2-subdev operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Hans, is this all that's needed?
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Regards,
Hans
include/media/v4l2-subdev.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..673a4e1 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -215,6 +215,9 @@ struct v4l2_subdev_video_ops {
int (*g_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
int (*try_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
int (*s_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
+ int (*cropcap)(struct v4l2_subdev *sd, struct v4l2_cropcap *cc);
+ int (*g_crop)(struct v4l2_subdev *sd, struct v4l2_crop *crop);
+ int (*s_crop)(struct v4l2_subdev *sd, struct v4l2_crop *crop);
int (*g_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum
*fsize);
--
1.6.2.4
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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] v4l: add cropping prototypes to struct v4l2_subdev_video_ops
Add g_crop, s_crop and cropcap methods to video v4l2-subdev operations.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Hans, is this all that's needed?
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Regards,
Hans
include/media/v4l2-subdev.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..673a4e1 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -215,6 +215,9 @@ struct v4l2_subdev_video_ops {
int (*g_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
int (*try_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
int (*s_fmt)(struct v4l2_subdev *sd, struct v4l2_format *fmt);
+ int (*cropcap)(struct v4l2_subdev *sd, struct v4l2_cropcap *cc);
+ int (*g_crop)(struct v4l2_subdev *sd, struct v4l2_crop *crop);
+ int (*s_crop)(struct v4l2_subdev *sd, struct v4l2_crop *crop);
int (*g_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum
*fsize);
--
1.6.2.4
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: Convert cpia driver to v4l2, drop parallel port version support?
On Wed, 2009-06-17 at 09:43 +0200, Hans Verkuil wrote: I personally think that loosing support for the parallel port version is ok given that the parallel port itslef is rapidly disappearing, what do you think ? I agree wholeheartedly. If we remove pp support, then we can also remove the bw-qcam and c-qcam drivers since they too use the parallel port. Maybe I just like keeping old hardware up and running, but... I think it may be better to remove camera drivers when a majority of the actual camera hardware is likely to reach EOL, as existing parallel ports will likely outlive the cameras. My PC I got in Dec 2005 has a parellel port, as does the motherboard I purchased 2008. I have a 802.11g router (ASUS WL-500g) with a parallel port. It works nicely as a remote print server. From my perspective, that parallel port isn't going away anytime soon. irrelevant aside At least the custom firmware for the WL-500g ( http://oleg.wl500g.info/ ) has the ability to use webcams for snapping pictures and emailing away a notification. I'm pretty sure PP webcams are not actually supported though. The wireless router surveillance case is probably not relevant though, as routers are usually using (very) old kernels. /irrelevant aside -Andy -- 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: Convert cpia driver to v4l2, drop parallel port version support?
On 06/17/2009 11:56 AM, Mauro Carvalho Chehab wrote: Em Wed, 17 Jun 2009 09:43:50 +0200 (CEST) Hans Verkuilhverk...@xs4all.nl escreveu: I recently have been bying second hand usb webcams left and right one of them (a creative unknown model) uses the cpia1 chipset, and works with the v4l1 driver currently in the kernel. One of these days I would like to convert it to a v4l2 driver using gspca as basis, this however will cause us to use parallel port support (that or we need to keep the old code around for the parallel port version). I personally think that loosing support for the parallel port version is ok given that the parallel port itslef is rapidly disappearing, what do you think ? I agree wholeheartedly. If we remove pp support, then we can also remove the bw-qcam and c-qcam drivers since they too use the parallel port. Maybe I'm too nostalgic, but those are the first V4L drivers. It would be fun to keep supporting them with V4L2 API ;) That's said, while it is probably not that hard to develop a gspca-pp driver, I'm not against removing parallel port support or even removing those drivers due to technical reasons, like the end of V4L1 drivers. By looking at the remaining V4L1 drivers, we have: ov511 - already implemented with V4L2 on gspca. Can be easily removed; Yip, this one is a done deal :) se401, stv680, usbvideo, vicam - USB V4L1 drivers. IMO, it is valuable to convert them to gspca; I've recently bought a (second hand) stv680 cam, haven't seriously tested it yet, so I dunno if it works with the v4l1 driver. I agree it would be good to convert these, and I can work on this as time permits, but I won't be converting code I don't have HW to test for. As for usbvideo that supports (amongst others) the st6422 (from the out of tree qc-usb-messenger driver), but only one usb-id ??. I'm currently finishing up adding st6422 support to gspca (with all known usb-id's), I have 2 different cams to test this with. And indeed as mentioned in another mail we should also convert the w9968cf. cpia2, pwc - supports both V4L1 and V4L2 API. It shouldn't be hard to convert them to vidio_ioctl2 and remove V4L1 API. I have a pwc cam , so I can test changes for pwc. btw current pwc oopses rather badly (GPF) when unplugging the cam, I'll dig into this. stradis - a saa7146 V4L1 only driver - I never understood this one well, since there is already another saa7146 driver running V4L2, used by mxb, hexium_gemini and hexium_orion. To make things worse, stradis, mxb and hexium_orion are registering for the same PCI device (the generic saa7146 PCI ID). If nobody volunteers to convert and test with V4L2, then maybe we can just remove it. The better conversion would probably be to use the V4L2 support at the saa7146 driver. arv - seems to be a VGA output driver - Only implements 3 ioctls: VIDIOCGCAP and VIDIOCGWIN/VIDIOCSWIN. It shouldn't be hard to convert it to V4L2. I'm not sure if this is still used in practice. bw-qcam, pms, c-qcam, cpia, w9966 - very old drivers that use direct io and/or parport; IMO, after having all USB ID's for se401, stv680, usbvideo and vicam devices supported by a V4L2 driver, we can just remove V4L1 ioctls from cpia2 and pwc, and the drivers that will still remain using only the legacy API can be dropped. Anything more converted will be a bonus Big +1, having digged through many of these old drivers to convert them, they all seem rather crufty and ugly and having them gone would be good. While cleaning cruft, I would also like to see the following v4l2 drivers go away in time, they are all from the same author (who mostly borrowed the reverse engineering work from the original out of tree gspca) and he does not maintain them, and they all support cams also supported by the new gspca: zc0301 only supports one usb-id which has not yet been tested with gspca, used to claim a lot more usb-id's but didn't actually work with those as it only supported the bridge, not the sensor - remove it now ? et61x251 Only supports using this bridge in combination with one type of sensor where as gspca supports 2 type of sensors. gspca support is untested AFAIK. - ? sn9c102 Supports a large number of cams also supported by gspca's sonixb / sonixj driver, we're using #ifdef macros to detect if both are being build at the same time to include usb-id's only in one of the 2. As seems normal for drivers from this author the driver used to claim a lot of usb-id's it couldn't actually work with as it only supported the bridge, not the sensor. We've removed all those and are now slowly moving over the remaining usb-ids to gspca as things get tested with gspca. - Keep on moving over usb-id's then when only a few are left, drop it Regards, Hans -- To
Re: [PATCH] adding support for setting bus parameters in sub device
On Wed, 17 Jun 2009, Hans Verkuil wrote: It is my strong opinion that while autonegotiation is easy to use, it is not a wise choice to make. Filling in a single struct with the bus settings to use for each board-subdev combination (usually there is only one) is simple, straight-forward and unambiguous. And I really don't see why that should take much time at all. And I consider it a very good point that the programmer is forced to think about this for a bit. Ok, my opinion is, that we should keep autonegotiation, but if you like, we can print a BIG-FAT-WARNING if both polarities are supported and no platform preference is set. I'd rather see a message stating which bus settings were chosen. That way if something fails in the future you can compare which bus settings were chosen in the past with the new bus settings and see if something changed there. I think, we've heard all opinions, unless someone would like to add something? Would it be fair to ask Mauro to make a decision? Or we can just count votes (which I would obviously prefer), Obviously :-) Since the only non-soc driver that needs this right now is tvp514x I'm pretty sure you'll get the most votes :-) But this is something that should be decided on technical merits, and not on what is easier for converting soc-camera. I'm not saying that is your only or main reason for wanting to keep autonegotiation, but it no doubt plays a role (perfectly understandable, BTW). Just note that it is exactly my experiences with dm646x and with closely working with the hardware team that made me realize the dangers of autonegotiation. A year ago I would have agreed with you, but now I feel very strongly that it is the wrong approach. Usually I would accept this code, even if I thought it was not the optimal solution, in the interest of finishing the conversion quickly. But I fear that if this goes in, then it will be next to impossible to change in the future. It simply boils down to this for me: I want to see unambiguous and explicit bus settings in the code so the reader can safely assume that the hardware was verified and/or certified for those settings. Even if you just picked some settings because you didn't have access to the preferred bus settings that the hardware manufacturer did his verification or certification with, then that will still show which settings you used to do your own testing. That's very important information to have in the code. Assuming that any autonegotiation code will always return the same result is in my opinion wishful thinking. Look at the problems we have in removing autoprobing from i2c: I'm pretty sure someone at the time also thought that autoprobing would never cause a problem. but I'll accept Mauro's decision too. That's fine by me as well. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Convert cpia driver to v4l2, drop parallel port version support?
On Wed, 2009-06-17 at 09:43 +0200, Hans Verkuil wrote: I personally think that loosing support for the parallel port version is ok given that the parallel port itslef is rapidly disappearing, what do you think ? I agree wholeheartedly. If we remove pp support, then we can also remove the bw-qcam and c-qcam drivers since they too use the parallel port. Maybe I just like keeping old hardware up and running, but... I think it may be better to remove camera drivers when a majority of the actual camera hardware is likely to reach EOL, as existing parallel ports will likely outlive the cameras. For sure. But these are really old webcams with correspondingly very poor resolutions. I haven't been able to track one down on ebay and as far as I know nobody has one of these beasts to test with. I can't see anyone using parallel port webcams. I actually wonder whether these drivers still work. And converting to v4l2 without having the hardware is very hard indeed. Regards, Hans My PC I got in Dec 2005 has a parellel port, as does the motherboard I purchased 2008. I have a 802.11g router (ASUS WL-500g) with a parallel port. It works nicely as a remote print server. From my perspective, that parallel port isn't going away anytime soon. irrelevant aside At least the custom firmware for the WL-500g ( http://oleg.wl500g.info/ ) has the ability to use webcams for snapping pictures and emailing away a notification. I'm pretty sure PP webcams are not actually supported though. The wireless router surveillance case is probably not relevant though, as routers are usually using (very) old kernels. /irrelevant aside -Andy -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] zl10353 and qt1010: fix stack corruption bug
Mauro Carvalho Chehab wrote:
Em Wed, 10 Jun 2009 08:21:20 +0200
Jan Nikitenko jan.nikite...@gmail.com escreveu:
This patch fixes stack corruption bug present in dump_regs function of zl10353
and qt1010 drivers:
the buffer buf is one byte smaller than required - there is 4 chars
for address prefix, 16*3 chars for dump of 16 eeprom bytes per line
and 1 byte for zero ending the string required, i.e. 53 bytes, but
only 52 were provided.
The one byte missing in stack based buffer buf can cause stack corruption
possibly leading to kernel oops, as discovered originally with af9015 driver.
Signed-off-by: Jan Nikitenko jan.nikite...@gmail.com
---
Antti Palosaari wrote:
On 06/10/2009 01:39 AM, Jan Nikitenko wrote:
Solved with [PATCH] af9015: fix stack corruption bug.
This error leads to the zl10353.c and there it was copied to qt1010.c
and af9015.c.
Antti, thanks for pointing out that the same problem was also in zl10353.c and
qt1010.c. Include your Sign-off-by, please.
Best regards,
Jan
linux/drivers/media/common/tuners/qt1010.c |2 +-
linux/drivers/media/dvb/frontends/zl10353.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff -r cff06234b725 linux/drivers/media/common/tuners/qt1010.c
--- a/linux/drivers/media/common/tuners/qt1010.cSun May 31 23:07:01
2009 +0300
+++ b/linux/drivers/media/common/tuners/qt1010.cWed Jun 10 07:37:51
2009 +0200
@@ -65,7 +65,7 @@
/* dump all registers */
static void qt1010_dump_regs(struct qt1010_priv *priv)
{
- char buf[52], buf2[4];
+ char buf[4+3*16+1], buf2[4];
CodingStyle is incorrect. It should be buf[4 + 3 * 16 + 1].
right.
u8 reg, val;
for (reg = 0; ; reg++) {
diff -r cff06234b725 linux/drivers/media/dvb/frontends/zl10353.c
--- a/linux/drivers/media/dvb/frontends/zl10353.c Sun May 31 23:07:01
2009 +0300
+++ b/linux/drivers/media/dvb/frontends/zl10353.c Wed Jun 10 07:37:51
2009 +0200
@@ -102,7 +102,7 @@
static void zl10353_dump_regs(struct dvb_frontend *fe)
{
struct zl10353_state *state = fe-demodulator_priv;
- char buf[52], buf2[4];
+ char buf[4+3*16+1], buf2[4];
Same CodingStyle issue here.
agreed.
int ret;
u8 reg;
Without having actually looking at the source code, would it be possible to
change the logic in order to use something else instead of a magic number for
buf size - e. g. using sizeof(something) ?
I am not sure if that's possible - the buffer is used for sprintf in a loop to
store text representation of registers dump, before printk-ing it.
We could put there a comment, suggesting that 4 bytes are required for address
prefix of form 00: , then 16 strings of form 00 (3 bytes each) and one byte
for zero to terminate the string.
Or we could use sizeof, like this:
char buf[sizeof(00: ) - 1 + 16 * (sizeof(00 ) - 1) + 1]
or
char buf[sizeof(00: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f )]
but it is not very readable in my opinion either.
Maybe the best way would be to avoid the need for temporal buffer completely by
directly using printk in a loop, that is only the first printk with KERN_DEBUG,
followed by sequence of printk with registers dump and final printk with end of
line (but isn't a printk without KERN_ facility coding style problem as well?).
I am not sure, what approach is the best - I just wanted to fix a bug, which did
not allow to use my af9015 based tuner on mips platform. After that, Antti
pointed out, that the same code with the same bug is also in other two sources,
so I send the same fix for them as well...
Best regards,
Jan
--
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] zl10353 and qt1010: fix stack corruption bug
On Mittwoch, 17. Juni 2009, Jan Nikitenko wrote: Or we could use sizeof, like this: char buf[sizeof(00: ) - 1 + 16 * (sizeof(00 ) - 1) + 1] or char buf[sizeof(00: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f )] but it is not very readable in my opinion either. Maybe the best way would be to avoid the need for temporal buffer completely by directly using printk in a loop, that is only the first printk with KERN_DEBUG, followed by sequence of printk with registers dump and final printk with end of line (but isn't a printk without KERN_ facility coding style problem as well?). Exactly for this case, line continuation, there is KERN_CONT defined. Regards Matthias -- 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: soc-camera: status, roadmap
On Wed, 10 Jun 2009, Guennadi Liakhovetski wrote: 2. The above means, I'll have to maintain and update my patches for a whole 2.6.31 development cycle. In this time I'll try to update and upload them as a quilt patch series and announce it on the list a couple of times. As promised, I just uploaded my current tree snapshot at http://download.open-technology.de/soc-camera/20090617/ This is nothing remarkable, just my current patch-stack for those working with the soc-camera framework. It is still based on a linux-next snapshot of 07.05.2009 history branch. The exact commit on which the stack is based is, as usual, in -base. This is still based off 2.6.30-rc4, and I expect to upgrade next time after 2.6.31-rc1. Thanks Guennadi --- 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] zl10353 and qt1010: fix stack corruption bug
Em Wed, 17 Jun 2009 14:26:28 +0200 Matthias Schwarzott z...@gentoo.org escreveu: On Mittwoch, 17. Juni 2009, Jan Nikitenko wrote: Or we could use sizeof, like this: char buf[sizeof(00: ) - 1 + 16 * (sizeof(00 ) - 1) + 1] or char buf[sizeof(00: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f )] but it is not very readable in my opinion either. Maybe the best way would be to avoid the need for temporal buffer completely by directly using printk in a loop, that is only the first printk with KERN_DEBUG, followed by sequence of printk with registers dump and final printk with end of line (but isn't a printk without KERN_ facility coding style problem as well?). Exactly for this case, line continuation, there is KERN_CONT defined. There are some functions meant for printing hex dumps at kernel.h: extern void hex_dump_to_buffer(const void *buf, size_t len, int rowsize, int groupsize, char *linebuf, size_t linebuflen, bool ascii); extern void print_hex_dump(const char *level, const char *prefix_str, int prefix_type, int rowsize, int groupsize, const void *buf, size_t len, bool ascii); extern void print_hex_dump_bytes(const char *prefix_str, int prefix_type, const void *buf, size_t len); Also, it is possible to use kasprintf() to dynamically allocate a temporary buffer. If you use it, you'll need to do a kfree after its usage. 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: Convert cpia driver to v4l2, drop parallel port version support?
Em Wed, 17 Jun 2009 13:26:58 +0200 (CEST) Hans Verkuil hverk...@xs4all.nl escreveu: On Wed, 2009-06-17 at 09:43 +0200, Hans Verkuil wrote: I personally think that loosing support for the parallel port version is ok given that the parallel port itslef is rapidly disappearing, what do you think ? I agree wholeheartedly. If we remove pp support, then we can also remove the bw-qcam and c-qcam drivers since they too use the parallel port. Maybe I just like keeping old hardware up and running, but... I think it may be better to remove camera drivers when a majority of the actual camera hardware is likely to reach EOL, as existing parallel ports will likely outlive the cameras. Parallel port will still be there for some time. However, Parallel port webcams are less common. For sure. But these are really old webcams with correspondingly very poor resolutions. I haven't been able to track one down on ebay and as far as I know nobody has one of these beasts to test with. I can't see anyone using parallel port webcams. I actually wonder whether these drivers still work. And converting to v4l2 without having the hardware is very hard indeed. Maybe Alan Cox might still have some of those cams. Some of those old cameras were used on specialized hardware, like microscopes. Maybe it still could make sense to support them, but somebody with the hardware should convert to V4L2 and test with the real hardware. Otherwise, I agree that the better is just to remove the parallel port camera drivers from newer kernels. 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] adding support for setting bus parameters in sub device
On Wed, 17 Jun 2009, Guennadi Liakhovetski wrote: On Wed, 17 Jun 2009, Hans Verkuil wrote: It is my strong opinion that while autonegotiation is easy to use, it is not a wise choice to make. Filling in a single struct with the bus settings to use for each board-subdev combination (usually there is only one) is simple, straight-forward and unambiguous. And I really don't see why that should take much time at all. And I consider it a very good point that the programmer is forced to think about this for a bit. Ok, my opinion is, that we should keep autonegotiation, but if you like, we can print a BIG-FAT-WARNING if both polarities are supported and no platform preference is set. I think, we've heard all opinions, unless someone would like to add something? Would it be fair to ask Mauro to make a decision? Or we can just count votes (which I would obviously prefer), but I'll accept Mauro's decision too. There is a similar situation in the networking code, where there is a driver for a PHY and another driver for a MAC, much like a sensor and bridge. phylib will find the common subset of the supported modes between the MAC and the detected PHY and use that to configure aneg advertisement settings. -- 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
Elgato EyeTV Diversity Support in dib0700
Hi everybody, I few days ago I bought an Elgato EyeTV Diversity. After some googling, I found patches for it at http://www.linuxtv.org/pipermail/linux-dvb/2008-September/028813.html. Applying the patches succeeded (I only hat to adjust the index into dib0700_usb_id_table) and after rebooting the card worked without problems. Even the remote control worked properly with the Xorg evdev driver after setting dvb_usb_dib0700_ir_proto to NEC. So I wondered if there is a reason why the patches have not been merged, yet. I searched the hg drivers as well as the developer repositories at http://linuxtv.org/hg/ and the mailing list archives but found little to no references referring to the EyeTV Diversity. I just wanted to mention it in case that the patches have been forgotten or something similar. Best Regards, Andreas Huesgen -- 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
typo: v4l2_bound_align_image name mismatch.
Just came across a build error with pxa_camera with Mauro's linux-next tree. pxa-camera calls v4l2_bound_align_image whereas the function is called v4l_bound_align_image. Cheers, --- Jonathan Cameron -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/10 - v2] vpfe capture bridge driver for DM355 and DM6446
snip Can you post your latest proposal for the s_bus op? I propose a few changes: the name of the struct should be something like v4l2_bus_settings, the master/slave bit should be renamed to something like 'host_is_master', and we should have two widths: subdev_width and host_width. That way the same structure can be used for both host and subdev, unless some of the polarities are inverted. In that case you need to make two structs, one for host and one for the subdev. It is possible to add info on inverters to the struct, but unless inverters are used a lot more frequently than I expect I am inclined not to do that at this time. [MK]Today I am planning to send my v3 version of the vpfe capture patch and also tvp514x patch since Vaibhav is pre-occupied with some other activities. I have discussed the changes with Vaibhav for this driver. For s_bus, I will try if I can send a patch today. BTW, do you expect me to add one bool for active high, one for active low etc as done in SoC camera ? Murali -- 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: Convert cpia driver to v4l2, drop parallel port version support?
Em Wed, 17 Jun 2009 16:41:23 +0200 Hans de Goede hdego...@redhat.com escreveu: Hi all, On 06/17/2009 04:28 PM, Mauro Carvalho Chehab wrote: Em Wed, 17 Jun 2009 12:59:59 +0200 Hans de Goedehdego...@redhat.com escreveu: snip As for usbvideo that supports (amongst others) the st6422 (from the out of tree qc-usb-messenger driver), but only one usb-id ??. I'm currently finishing up adding st6422 support to gspca (with all known usb-id's), I have 2 different cams to test this with. I have here one Logitech quickcam. There are several variants, and the in-tree and out-tree drivers support different models. I can test it here and give you a feedback. However, I don't have the original driver for it. Ok, what is its usb id (they tend to be unique for Logitech cams) ? The one I have is this one: Bus 005 Device 003: ID 046d:08f6 Logitech, Inc. QuickCam Messenger Plus This is supported by one quickcam driver. zc0301 only supports one usb-id which has not yet been tested with gspca, used to claim a lot more usb-id's but didn't actually work with those as it only supported the bridge, not the sensor - remove it now ? I have one zc0301 cam that works with this driver. The last time I checked, it didn't work with gspca. I'll double check. Ok, let me know how it goes. The zc0301 camera is this one: Bus 005 Device 002: ID 046d:08ae Logitech, Inc. QuickCam for Notebooks zc0301 driver says this: [98174.672464] zc0301: V4L2 driver for ZC0301[P] Image Processor and Control Chip v1:1.10 [98174.672517] usb 5-2: ZC0301[P] Image Processor and Control Chip detected (vid/pid 0x046D:0x08AE) [98174.713717] usb 5-2: PAS202BCB image sensor detected The cam works as expected. If it does not work, guess what I want you to bring along to plumbers ? (you are coming to plumbers, or .. ? ) I probably won't go to LPC this year, since I'm programming to be at Japan Linux Symposium in October, and it seems too much jet leg for me to be in Portland in Sept and in Japan in Oct ;) 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
[RFC PATCH] adding support for setting bus parameters in sub device
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
This patch adds support for setting bus parameters such as bus type
(Raw Bayer or Raw YUV image data bus), bus width (example 10 bit raw
image data bus, 10 bit BT.656 etc.), and polarities (vsync, hsync, field
etc) in sub device. This allows bridge driver to configure the sub device
bus for a specific set of bus parameters through s_bus() function call.
This also can be used to define platform specific bus parameters for
host and sub-devices.
Reviewed by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
include/media/v4l2-subdev.h | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..2f5ec98 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -37,6 +37,43 @@ struct v4l2_decode_vbi_line {
u32 type; /* VBI service type (V4L2_SLICED_*). 0 if no
service found */
};
+/*
+ * Some sub-devices are connected to the host/bridge device through a bus that
+ * carries the clock, vsync, hsync and data. Some interfaces such as BT.656
+ * carries the sync embedded in the data where as others have separate line
+ * carrying the sync signals. The structure below is used to define bus
+ * configuration parameters for host as well as sub-device
+ */
+enum v4l2_subdev_bus_type {
+ /* Raw YUV image data bus */
+ V4L2_SUBDEV_BUS_RAW_YUV,
+ /* Raw Bayer image data bus */
+ V4L2_SUBDEV_BUS_RAW_BAYER
+};
+
+struct v4l2_bus_settings {
+ /* yuv or bayer image data bus */
+ enum v4l2_subdev_bus_type type;
+ /* subdev bus width */
+ u8 subdev_width;
+ /* host bus width */
+ u8 host_width;
+ /* embedded sync, set this when sync is embedded in the data stream */
+ unsigned embedded_sync:1;
+ /* master or slave */
+ unsigned host_is_master:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_vsync:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_hsync:1;
+ /* 0 - low to high , 1 - high to low */
+ unsigned pol_field:1;
+ /* 0 - sample at falling edge , 1 - sample at rising edge */
+ unsigned pol_pclock:1;
+ /* 0 - active low , 1 - active high */
+ unsigned pol_data:1;
+};
+
/* Sub-devices are devices that are connected somehow to the main bridge
device. These devices are usually audio/video muxers/encoders/decoders or
sensors and webcam controllers.
@@ -199,6 +236,8 @@ struct v4l2_subdev_audio_ops {
s_routing: see s_routing in audio_ops, except this version is for video
devices.
+
+ s_bus: set bus parameters in sub device to configure the bus
*/
struct v4l2_subdev_video_ops {
int (*s_routing)(struct v4l2_subdev *sd, u32 input, u32 output, u32
config);
@@ -219,6 +258,7 @@ struct v4l2_subdev_video_ops {
int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum
*fsize);
int (*enum_frameintervals)(struct v4l2_subdev *sd, struct
v4l2_frmivalenum *fival);
+ int (*s_bus)(struct v4l2_subdev *sd, const struct v4l2_bus_settings
*bus);
};
struct v4l2_subdev_ops {
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC PATCH] adding support for setting bus parameters in sub device
Hans,
Let me know if this has all changes that you are expecting. This is just for
review. I will send the final one against the latest v4l-dvb kernel tree.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, June 17, 2009 11:44 AM
To: linux-media@vger.kernel.org
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Muralidharan Karicheri;
Karicheri, Muralidharan
Subject: [RFC PATCH] adding support for setting bus parameters in sub
device
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
This patch adds support for setting bus parameters such as bus type
(Raw Bayer or Raw YUV image data bus), bus width (example 10 bit raw
image data bus, 10 bit BT.656 etc.), and polarities (vsync, hsync, field
etc) in sub device. This allows bridge driver to configure the sub device
bus for a specific set of bus parameters through s_bus() function call.
This also can be used to define platform specific bus parameters for
host and sub-devices.
Reviewed by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
include/media/v4l2-subdev.h | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..2f5ec98 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -37,6 +37,43 @@ struct v4l2_decode_vbi_line {
u32 type; /* VBI service type (V4L2_SLICED_*). 0 if no
service found */
};
+/*
+ * Some sub-devices are connected to the host/bridge device through a bus
that
+ * carries the clock, vsync, hsync and data. Some interfaces such as
BT.656
+ * carries the sync embedded in the data where as others have separate
line
+ * carrying the sync signals. The structure below is used to define bus
+ * configuration parameters for host as well as sub-device
+ */
+enum v4l2_subdev_bus_type {
+ /* Raw YUV image data bus */
+ V4L2_SUBDEV_BUS_RAW_YUV,
+ /* Raw Bayer image data bus */
+ V4L2_SUBDEV_BUS_RAW_BAYER
+};
+
+struct v4l2_bus_settings {
+ /* yuv or bayer image data bus */
+ enum v4l2_subdev_bus_type type;
+ /* subdev bus width */
+ u8 subdev_width;
+ /* host bus width */
+ u8 host_width;
+ /* embedded sync, set this when sync is embedded in the data stream
*/
+ unsigned embedded_sync:1;
+ /* master or slave */
+ unsigned host_is_master:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_vsync:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_hsync:1;
+ /* 0 - low to high , 1 - high to low */
+ unsigned pol_field:1;
+ /* 0 - sample at falling edge , 1 - sample at rising edge */
+ unsigned pol_pclock:1;
+ /* 0 - active low , 1 - active high */
+ unsigned pol_data:1;
+};
+
/* Sub-devices are devices that are connected somehow to the main bridge
device. These devices are usually audio/video muxers/encoders/decoders
or
sensors and webcam controllers.
@@ -199,6 +236,8 @@ struct v4l2_subdev_audio_ops {
s_routing: see s_routing in audio_ops, except this version is for video
devices.
+
+ s_bus: set bus parameters in sub device to configure the bus
*/
struct v4l2_subdev_video_ops {
int (*s_routing)(struct v4l2_subdev *sd, u32 input, u32 output, u32
config);
@@ -219,6 +258,7 @@ struct v4l2_subdev_video_ops {
int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
int (*enum_framesizes)(struct v4l2_subdev *sd, struct
v4l2_frmsizeenum *fsize);
int (*enum_frameintervals)(struct v4l2_subdev *sd, struct
v4l2_frmivalenum *fival);
+ int (*s_bus)(struct v4l2_subdev *sd, const struct v4l2_bus_settings
*bus);
};
struct v4l2_subdev_ops {
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
bttv problem loading takes about several minutes
Hi, In the past I could use this card by typing modprobe bttv card=34 tuner=24 gbuffers=16 Giving this command with current drivers has some problems: 1. it takes several minutes to load bttv module. 2. capturing doesn't work any more (dropped frames etc). Tested with current v4l-dvb from hg, ubuntu 9.04, debian lenny. I have a bt878 based card from leadtek. Here is my output after loading the driver: [ 3013.735459] bttv: driver version 0.9.17 loaded [ 3013.735470] bttv: using 32 buffers with 16k (4 pages) each for capture [ 3013.735542] bttv: Bt8xx card found (0). [ 3013.735562] bttv0: Bt878 (rev 17) at :00:0b.0, irq: 19, latency: 32, mmio : 0xf780 [ 3013.737762] bttv0: using: Leadtek WinFast 2000/ WinFast 2000 XP [card=34,insm od option] [ 3013.737825] bttv0: gpio: en=, out= in=003ff502 [init] [ 3148.136017] bttv0: tuner type=24 [ 3148.136029] bttv0: i2c: checking for MSP34xx @ 0x80... not found [ 3154.536019] bttv0: i2c: checking for TDA9875 @ 0xb0... not found [ 3160.936018] bttv0: i2c: checking for TDA7432 @ 0x8a... not found [ 3167.351398] bttv0: registered device video0 [ 3167.351434] bttv0: registered device vbi0 [ 3167.351463] bttv0: registered device radio0 [ 3167.351485] bttv0: PLL: 28636363 = 35468950 . ok [ 3167.364182] input: bttv IR (card=34) as /class/input/input6 Please help! Regards Halim -- Halim Sahin E-Mail: halim.sahin (at) t-online.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: [PULL] generic image bounds setting and alignment function
On Wed, 17 Jun 2009, Guennadi Liakhovetski wrote:
On Tue, 16 Jun 2009, Trent Piepho wrote:
/* up the smaller alignment until we have enough */
do {
- if (walign = halign walign wmaxa) {
+ if (halign = hmaxa ||
+ (walign = halign walign wmaxa)) {
Do I understand it right now, that as soon as your halign now reaches
hmaxa, you'll stop incrementing halign and then keep incrementing walign
even beyond wmaxa?...
Yes.
It's clearly documented that the function isn't designed to handle
impossible constraints. If both walign and halign are at max and there
still needs to be more alignment then there is no possible resolution, no
matter what width height started at.
This is just one of many ways the constraints could be impossible. Max
width being less than min width is another obvious example. I decided it
wasn't worth complicating the code to check for all of these things. And
if the function did return failure the callers would need to check that.
None of the code v4l_bound_align_image() replaces has a failure path for
impossible image size constraints, because the constraints aren't
impossible.
--
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: bttv problem loading takes about several minutes
On Wed, 17 Jun 2009, Halim Sahin wrote: Hi, In the past I could use this card by typing modprobe bttv card=34 tuner=24 gbuffers=16 What card do you actually have? What is the PCI subsystem vendor/device and what tuner does it actually have? Hans, the problem might be with bttv audio probing. This card has needs_tvaudio set to 0, which used to mean that tvaudio would not be probed or loaded. But with your changes to bttv audio probing this behavior has changed. Now tvaudio is always loaded and probed if another audio chip hasn't been detected. The needs_tvaudio field is totally ignored. Giving this command with current drivers has some problems: 1. it takes several minutes to load bttv module. 2. capturing doesn't work any more (dropped frames etc). Tested with current v4l-dvb from hg, ubuntu 9.04, debian lenny. I have a bt878 based card from leadtek. Here is my output after loading the driver: [ 3013.735459] bttv: driver version 0.9.17 loaded [ 3013.735470] bttv: using 32 buffers with 16k (4 pages) each for capture [ 3013.735542] bttv: Bt8xx card found (0). [ 3013.735562] bttv0: Bt878 (rev 17) at :00:0b.0, irq: 19, latency: 32, mmio : 0xf780 [ 3013.737762] bttv0: using: Leadtek WinFast 2000/ WinFast 2000 XP [card=34,insm od option] [ 3013.737825] bttv0: gpio: en=, out= in=003ff502 [init] [ 3148.136017] bttv0: tuner type=24 [ 3148.136029] bttv0: i2c: checking for MSP34xx @ 0x80... not found [ 3154.536019] bttv0: i2c: checking for TDA9875 @ 0xb0... not found [ 3160.936018] bttv0: i2c: checking for TDA7432 @ 0x8a... not found [ 3167.351398] bttv0: registered device video0 [ 3167.351434] bttv0: registered device vbi0 [ 3167.351463] bttv0: registered device radio0 [ 3167.351485] bttv0: PLL: 28636363 = 35468950 . ok [ 3167.364182] input: bttv IR (card=34) as /class/input/input6 Please help! Regards Halim -- Halim Sahin E-Mail: halim.sahin (at) t-online.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 -- 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: Convert cpia driver to v4l2, drop parallel port version support?
Hi, On 06/17/2009 05:23 PM, Mauro Carvalho Chehab wrote: Em Wed, 17 Jun 2009 16:41:23 +0200 Hans de Goedehdego...@redhat.com escreveu: Hi all, On 06/17/2009 04:28 PM, Mauro Carvalho Chehab wrote: Em Wed, 17 Jun 2009 12:59:59 +0200 Hans de Goedehdego...@redhat.com escreveu: snip As for usbvideo that supports (amongst others) the st6422 (from the out of tree qc-usb-messenger driver), but only one usb-id ??. I'm currently finishing up adding st6422 support to gspca (with all known usb-id's), I have 2 different cams to test this with. I have here one Logitech quickcam. There are several variants, and the in-tree and out-tree drivers support different models. I can test it here and give you a feedback. However, I don't have the original driver for it. Ok, what is its usb id (they tend to be unique for Logitech cams) ? The one I have is this one: Bus 005 Device 003: ID 046d:08f6 Logitech, Inc. QuickCam Messenger Plus This is supported by one quickcam driver. Ah, that is one of the 2 models I have access to, so I can promise you that one will work fine with the new st6422 support I'm doing. zc0301 only supports one usb-id which has not yet been tested with gspca, used to claim a lot more usb-id's but didn't actually work with those as it only supported the bridge, not the sensor - remove it now ? I have one zc0301 cam that works with this driver. The last time I checked, it didn't work with gspca. I'll double check. Ok, let me know how it goes. The zc0301 camera is this one: Bus 005 Device 002: ID 046d:08ae Logitech, Inc. QuickCam for Notebooks zc0301 driver says this: [98174.672464] zc0301: V4L2 driver for ZC0301[P] Image Processor and Control Chip v1:1.10 [98174.672517] usb 5-2: ZC0301[P] Image Processor and Control Chip detected (vid/pid 0x046D:0x08AE) [98174.713717] usb 5-2: PAS202BCB image sensor detected The cam works as expected. Hmm, bummer I don't have any zc3xx test cams with a pas202b sensor, guess I need to find one :) I probably won't go to LPC this year, since I'm programming to be at Japan Linux Symposium in October, and it seems too much jet leg for me to be in Portland in Sept and in Japan in Oct ;) Ah too bad, but understandable. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH / resubmit] USB interrupt support for radio-si470x FM radio driver
All,
Following up on your comments, here is the patch against the
current mercurial tree, still works fine, and indeed, the stereo/mono
and strength indicators work better on this newer version. RDS
reception remains better with my patch :-) Now I just need to bundle
this with icecast to get mp3 streaming with embedded RDS info, but
that's outside of the scope of this list.
Thanks for all your help, now on to Tobias, I guess!
Best regards,
Signed-off-by: Edouard Lafargue edou...@lafargue.name
diff -r b385a43af222 linux/drivers/media/radio/radio-si470x.c
--- a/linux/drivers/media/radio/radio-si470x.c Tue Jun 16 23:55:44 2009 -0300
+++ b/linux/drivers/media/radio/radio-si470x.c Wed Jun 17 19:04:25 2009 +0200
@@ -106,20 +106,24 @@
* Tobias Lorenz tobias.lor...@gmx.net
* - add LED status output
* - get HW/SW version from scratchpad
+ * 2009-06-16 Edouard Lafargue edou...@lafargue.name
+ * Version 1.0.10
+ * - add support for interrupt mode for RDS endpoint,
+ *instead of polling.
+ *Improves RDS reception significantly
*
* ToDo:
* - add firmware download/update support
- * - RDS support: interrupt mode, instead of polling
*/
/* driver definitions */
#define DRIVER_AUTHOR Tobias Lorenz tobias.lor...@gmx.net
#define DRIVER_NAME radio-si470x
-#define DRIVER_KERNEL_VERSION KERNEL_VERSION(1, 0, 9)
+#define DRIVER_KERNEL_VERSION KERNEL_VERSION(1, 0, 10)
#define DRIVER_CARD Silicon Labs Si470x FM Radio Receiver
#define DRIVER_DESC USB radio driver for Si470x FM Radio Receivers
-#define DRIVER_VERSION 1.0.9
+#define DRIVER_VERSION 1.0.10
/* kernel includes */
@@ -218,16 +222,6 @@
module_param(max_rds_errors, ushort, 0644);
MODULE_PARM_DESC(max_rds_errors, RDS maximum block errors: *1*);
-/* RDS poll frequency */
-static unsigned int rds_poll_time = 40;
-/* 40 is used by the original USBRadio.exe */
-/* 50 is used by radio-cadet */
-/* 75 should be okay */
-/* 80 is the usual RDS receive interval */
-module_param(rds_poll_time, uint, 0644);
-MODULE_PARM_DESC(rds_poll_time, RDS poll time (ms): *40*);
-
-
/**
* Register Definitions
@@ -450,6 +444,12 @@
struct usb_interface *intf;
struct video_device *videodev;
+ /* Interrupt endpoint handling */
+ char *int_in_buffer;
+ struct usb_endpoint_descriptor *int_in_endpoint;
+ struct urb *int_in_urb;
+ int int_in_running;
+
/* driver management */
unsigned int users;
unsigned char disconnected;
@@ -459,7 +459,6 @@
unsigned short registers[RADIO_REGISTER_NUM];
/* RDS receive buffer */
- struct delayed_work work;
wait_queue_head_t read_queue;
struct mutex lock; /* buffer locking */
unsigned char *buffer; /* size is always multiple of three */
@@ -865,43 +864,6 @@
/**
- * General Driver Functions - RDS_REPORT
- **/
-
-/*
- * si470x_get_rds_registers - read rds registers
- */
-static int si470x_get_rds_registers(struct si470x_device *radio)
-{
- unsigned char buf[RDS_REPORT_SIZE];
- int retval;
- int size;
- unsigned char regnr;
-
- buf[0] = RDS_REPORT;
-
- retval = usb_interrupt_msg(radio-usbdev,
- usb_rcvintpipe(radio-usbdev, 1),
- (void *) buf, sizeof(buf), size, usb_timeout);
- if (size != sizeof(buf))
- printk(KERN_WARNING DRIVER_NAME : si470x_get_rds_registers:
- return size differs: %d != %zu\n, size, sizeof(buf));
- if (retval 0)
- printk(KERN_WARNING DRIVER_NAME : si470x_get_rds_registers:
- usb_interrupt_msg returned %d\n, retval);
-
- if (retval = 0)
- for (regnr = 0; regnr RDS_REGISTER_NUM; regnr++)
- radio-registers[STATUSRSSI + regnr] =
- get_unaligned_be16(
- buf[regnr * RADIO_REGISTER_SIZE + 1]);
-
- return (retval 0) ? -EINVAL : 0;
-}
-
-
-
-/**
* General Driver Functions - LED_REPORT
**/
@@ -959,102 +921,118 @@
**/
/*
- * si470x_rds - rds processing function
+ * si470x_int_in_callback - rds callback and processing function
+ *
+ * TODO: do we need to use mutex locks in some sections?
*/
-static void si470x_rds(struct si470x_device *radio)
+static void si470x_int_in_callback(struct urb *urb)
{
+ struct si470x_device *radio = urb-context;
+ unsigned char buf[RDS_REPORT_SIZE];
+
Re: [PULL] generic image bounds setting and alignment function
On Wed, 17 Jun 2009, Guennadi Liakhovetski wrote: On Tue, 16 Jun 2009, Trent Piepho wrote: On Tue, 16 Jun 2009, Guennadi Liakhovetski wrote: 01/14: compat: handle __fls http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=c4b55ce6c273 02/14: v4l2: Create helper function for bounding and aligning images http://linuxtv.org/hg/~tap/v4l-dvb?cmd=changeset;node=b4d3ec8d363d I am sorry, I will not bother with saving, reformatting, pasting... Just wanted to ask about this place: I guess you do not use Mercurial like all other v4l-dvb developers? I do use hg, though not for development, but for interacting with all other v4l-dvb developers Because you are making a big deal about a simple operation than can be done with a few keystrokes. If I wanted this patch quoted in my editor, I can simply type: !!cd ~/v4l-dvb ; hg export b4d3ec8d363d | sed 's/^/ /' No, typing this is not a big deal, as you say. But I do not understand _wny_ everyone, wishing to review / comment on your patches has to do that. And another problem of your approach you confirm yourself in this post: Using pull requests is something all v4l developers, besides you, do as well. No one, besides you, seems to find it a problem. It's been this way for years. I'm not the one who came up with this system. Sometimes one needs to go the mountain instead of expecting the mountain to come to oneself. See? Now hg will have two patches, which Mauro will then have to merge into one when exporting to git, and which then will be very difficult to Oh well. It's happened plenty of times before. I try not to make a habit of it. One can find many many patches in the linux git tree that have bugs in them. Often there are patches that fix these bugs included in the same upstream merge. IOW, the bug was found and fixed before the patch was merged upstream but the fix wasn't folded into the original patch, because the original patch was already in git and someone didn't want to do a git-rebase. One advantage of the hg tree is we get an extra opportunity to fix these things before sending them to git. everyone gets to see and review your patches only when they are already in your external repository ready to be pulled by the maintainer. s/in your/posted in the/; s/repository/mailing list/; s/pulled/applied/; everyone gets to see and review your patches only when they are already posted in the external mailing list ready to be applied by the maintainer. Is that really any different? -- 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] [09061_01] Siano: Update KConfig and Makefile
Em Wed, 17 Jun 2009 17:36:21 +0300 Udi Atar udi.linu...@gmail.com escreveu: # HG changeset patch # User Udi Atar u...@siano-ms.com # Date 1245248482 -10800 # Node ID 46081b3e60046b900c9c8110513224911df8e106 # Parent b385a43af222b6c8d2d93937644eb936f63d81e3 Update Siano KConfig file From: Udi Atar u...@siano-ms.com Priority: normal Signed-off-by: Udi Atar u...@siano-ms.com diff -r b385a43af222 -r 46081b3e6004 linux/drivers/media/dvb/siano/Kconfig --- a/linux/drivers/media/dvb/siano/Kconfig Tue Jun 16 23:55:44 2009 -0300 +++ b/linux/drivers/media/dvb/siano/Kconfig Wed Jun 17 17:21:22 2009 +0300 @@ -2,25 +2,32 @@ # Siano Mobile Silicon Digital TV device configuration # -config DVB_SIANO_SMS1XXX - tristate Siano SMS1XXX USB dongle support - depends on DVB_CORE USB +config SMS_SIANO_MDTV All DVB devices should start with DVB_. + tristate Siano SMS1xxx based MDTV receiver + default m Don't use default. You shouldn't assume that most of the kernel users are interested on this module. ---help--- - Choose Y here if you have a USB dongle with a SMS1XXX chipset. + Choose Y or M here if you have MDTV receiver with a Siano chipset. - To compile this driver as a module, choose M here: the - module will be called sms1xxx. + To compile this driver as a module, choose M here + (The modules will be called smsmdtv). -config DVB_SIANO_SMS1XXX_SMS_IDS - bool Enable support for Siano Mobile Silicon default USB IDs - depends on DVB_SIANO_SMS1XXX - default y + Note: All dependents, if selected, will be part of this module. As already discussed, the driver should be kept modular. So, the note above doesn't apply. + + Further documentation on this driver can be found on the WWW + at http://www.siano-ms.com/ + +if SMS_SIANO_MDTV +menu Siano module components + +# Hardware interfaces support + +config SMS_USB_DRV + tristate USB interface support + depends on USB + default m if USB ---help--- - Choose Y here if you have a USB dongle with a SMS1XXX chipset - that uses Siano Mobile Silicon's default usb vid:pid. + Choose if you would like to have Siano's support for USB interface - Choose N here if you would prefer to use Siano's external driver. - Further documentation on this driver can be found on the WWW at - http://www.siano-ms.com/. - +endmenu +endif # SMS_SIANO_MDTV What kind of support the driver will provide without USB ? I suspect that you are wanting to have several bus options like for example USB and MMC. Since, without a bus, the core module makes no sense to be compiled, you should, instead, use a different Kbuild struct. Something something like: comment Siano devices config DVB_SIANO_MDTV tristate default n config DVB_SIANO_USB tristate USB bus support for Siano devices depends on DVB_CORE USB select DVB_SIANO_MDTV ---help--- Choose if you would like to have Siano's support for USB interface config DVB_SIANO_MMC tristate MMC bus support for Siano devices depends on DVB_CORE USB select DVB_SIANO_MDTV ---help--- Choose if you would like to have Siano's support for MMC interface other bus options here With the above syntax, the core module will be built only if at least one of the supported bus is selected. 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: OMAP patches for linux-media
Mauro Carvalho Chehab wrote: Hi Sakari and others, Hi, Mauro! I'm seeing lots of patches and discussions for OMAP and DaVinci being handled at the linux-media Mailing List, as part of the development process of the open source drivers. However, it is hard to track all those discussions and be sure what patches are ready for merging and what patches are just RFC. On the development model we use here, we have driver maintainers that are responsible to discuss about improvements on their drivers. They are generally the driver authors or the one that first started submitting the patches for that driver(s). One of the roles of the driver maintainers is to collect the patches for the drivers they maintain, merge on their trees, and periodically ask the patch merge. One fundamental concept on Kernel development is the concept of Commit earlier and commit often, meaning that the better is to send small, incremental, and periodic patches, than wait until having everything done, then submit a big patch. Every time I receive a big patch I need to postpone its analysis and open a big window on my schedule to analyze it. Of course, this means to postpone it, and generally results on lots of comments going back to developer, that, in turn, will need to do lots of changes and return me back with another big patch for me to analyze again, resulting on a long period of time for merging it. As you, Sakari, was the first one that started merging the OMAP drivers, I was expecting that you would be the one that will handle the figure of the driver maintainer for OMAP. I even created you an account at linuxtv for you to create your trees there and ask me to merge from it. Unfortunately, you haven't sent me any pull requests yet along this year. This is concerning me a lot, since, at the end, I'll need to review big piles of patches and/or drivers when you decide to submit the final version. So, I decided to send you this email, c/c a random list of people that I believe are involved on the submit and/or review process of those patches, in the hope to better understand and to discuss what's happening and how can we speedup the merge process of those patches. There are a few reasons for apparent stalling of the development process. I should have sent a status update earlier. The code quality of the ISP driver was originally quite low and from that part it wouldn't have made much sense to repeatedly post that for reviewing. It's been improving since many of the subdrivers have been refactored or rewritten since I last posted the patchset. The end result should be (more?) easily understood by human beings... Another reason for no upstream patches is that we are still depending on the obsolete v4l2-int-device in the camera / sensor / lens / flash driver interface. Hans' opinion was that we must switch to v4l2_subdev instead with which I fully agree. However, due to our internal reasons we have not been able to even start that transition process yet. There is no definite deadline for the v4l2_subdev transition (or even its start) at the moment. I'm planning to update the patchset in Gitorious, however. Best regards, -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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
OV7670: getting it working with soc-camera.
This is purely for info of anyone else wanting to use the ov7670
with Guennadi's recent work on converted soc-camera to v4l2-subdevs.
It may not be completely minimal, but it's letting me take pictures ;)
Couple of minor queries:
Currently it is assumed that there is a means of telling the chip to
use particular bus params. In the case of this one it doesn't support
anything other than 8 bit. Stuff may get added down the line, but
in meantime does anyone mind if we make icd-ops-set_bus_param
optional in soc-camera?
Is there any reason (or advantage) in not specifying the i2c address
in the driver? Or for that matter why the address is right shifted by
1 in:
v4l_info(client, chip found @ 0x%02x (%s)\n,
client-addr 1, client-adapter-name);
Admittedly the data sheet uses an 'unusual' convention for the
address (separate write and read address which correspond to
a single address of 0x21 with the relevant write bit set as
appropriate).
As ever any comments welcome. Thanks to Guennadi Liakhovetski
for his soc-camera work and Hans Verkuil for conversion of the
ov7670 to soc-dev.
Tested against a merge of todays v4l-next tree and Linus' current
with the minor pxa-camera bug I posted earlier fixed and Guennadi's
extensive patch set applied (this requires a few hand merges, but
nothing too nasty).
---
diff --git a/include/media/ov7670_soc.h b/include/media/ov7670_soc.h
new file mode 100644
index 000..2f264b2
--- /dev/null
+++ b/include/media/ov7670_soc.h
@@ -0,0 +1,21 @@
+/* ov7670_soc Camera
+ *
+ * Copyright (C) 2009 Jonathan Cameron ji...@cam.ac.uk
+ *
+ * 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.
+ */
+
+#ifndef __OV7670_SOC_H__
+#define __OV7670_SOC_H__
+
+#include media/soc_camera.h
+
+struct ov7670_soc_camera_info {
+ int gpio_pwr;
+ int gpio_reset;
+ struct soc_camera_link link;
+};
+
+#endif
diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
index 0e2184e..51d432e 100644
--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -19,7 +19,14 @@
#include media/v4l2-chip-ident.h
#include media/v4l2-i2c-drv.h
+#define OV7670_SOC
+
+#ifdef OV7670_SOC
+#include media/ov7670_soc.h
+#include media/soc_camera.h
+#include linux/gpio.h
+#endif /* OV7670_SOC */
MODULE_AUTHOR(Jonathan Corbet cor...@lwn.net);
MODULE_DESCRIPTION(A low-level driver for OmniVision ov7670 sensors);
MODULE_LICENSE(GPL);
@@ -1239,19 +1246,94 @@ static const struct v4l2_subdev_ops ov7670_ops = {
};
/* --- */
+#ifdef OV7670_SOC
+
+static unsigned long ov7670_soc_query_bus_param(struct soc_camera_device *icd)
+{
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
+ SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
+ SOCAM_DATAWIDTH_8 | SOCAM_DATA_ACTIVE_HIGH;
+
+ return soc_camera_apply_sensor_flags(icl, flags);
+}
+/* This device only supports one bus option */
+static int ov7670_soc_set_bus_param(struct soc_camera_device *icd,
+ unsigned long flags)
+{
+ return 0;
+}
+
+static struct soc_camera_ops ov7670_soc_ops = {
+ .set_bus_param = ov7670_soc_set_bus_param,
+ .query_bus_param = ov7670_soc_query_bus_param,
+};
+
+#define SETFOURCC(type) .name = (#type), .fourcc = (V4L2_PIX_FMT_ ## type)
+static const struct soc_camera_data_format ov7670_soc_fmt_lists[] = {
+ {
+ SETFOURCC(YUYV),
+ .depth = 16,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ }, {
+ SETFOURCC(RGB565),
+ .depth = 16,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ },
+};
+#endif
static int ov7670_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
+#ifdef OV7670_SOC
+ struct soc_camera_device *icd = client-dev.platform_data;
+ struct soc_camera_link *icl;
+ struct ov7670_soc_camera_info *board_info;
+#endif
struct v4l2_subdev *sd;
struct ov7670_info *info;
+
int ret;
+#ifdef OV7670_SOC
+ icl = to_soc_camera_link(icd);
+ if (!icl)
+ return -EINVAL;
+ board_info = container_of(icl, struct ov7670_soc_camera_info, link);
+
+ gpio_request(board_info-gpio_reset, ov7670 soc reset);
+ gpio_request(board_info-gpio_pwr, ov7670 soc power);
+
+ /* reset high for normal mode */
+ gpio_direction_output(board_info-gpio_reset, 1);
+ /* power down normal mode. */
+ gpio_direction_output(board_info-gpio_pwr, 0);
+ /* perform a hard reset as per tinyos code */
+ gpio_set_value(board_info-gpio_pwr, 1);
+ gpio_set_value(board_info-gpio_reset, 1);
+ mdelay(2);
+
Re: Convert cpia driver to v4l2, drop parallel port version support?
Hans de Goede wrote: sn9c102 Supports a large number of cams also supported by gspca's sonixb / sonixj driver, we're using #ifdef macros to detect if both are being build at the same time to include usb-id's only in one of the 2. Btw, it would be interesting to work with the out-of-tree microdia driver, since there are some models that are supported only by the alternative driver. Ack, only one small problem, which is another reason why Luca's drivers should slowly be phased out, Luca has gone closed source with his sn9cxxx driver. There is an out of tree driver for the new sn9c2xx models you talk about though, with active developers, I've pushing them to get it into the mainline, I'll give it another try soonish. Hello I'm one of the developers for the current out of tree sn9c20x driver. What needs to be done in order to get the sn9c20x code into the mainline? Am i right in assuming it would be preferred to move the code into a sn9c20x gspca subdriver rather then include the complete out of tree driver? If this is the case I can work on a set of patches to implement our code as a gspca subdriver. Also i have a few questions regarding submitting the patches. 1) In addition to sending them to linux-media should I CC them to anyone in particular? 2) The entire patch would likely be about 70k. Should I just send one patch or split the thing up into several? Thanks, Brian -- 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 -- 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: WARNINGS, 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:Wed Jun 17 19:00:05 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12010:b385a43af222 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-x86_64: WARNINGS sparse (linux-2.6.30): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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: Convert cpia driver to v4l2, drop parallel port version support?
On 06/17/2009 08:11 PM, Brian Johnson wrote: Hans de Goede wrote: sn9c102 Supports a large number of cams also supported by gspca's sonixb / sonixj driver, we're using #ifdef macros to detect if both are being build at the same time to include usb-id's only in one of the 2. Btw, it would be interesting to work with the out-of-tree microdia driver, since there are some models that are supported only by the alternative driver. Ack, only one small problem, which is another reason why Luca's drivers should slowly be phased out, Luca has gone closed source with his sn9cxxx driver. There is an out of tree driver for the new sn9c2xx models you talk about though, with active developers, I've pushing them to get it into the mainline, I'll give it another try soonish. Hello I'm one of the developers for the current out of tree sn9c20x driver. What needs to be done in order to get the sn9c20x code into the mainline? Am i right in assuming it would be preferred to move the code into a sn9c20x gspca subdriver rather then include the complete out of tree driver? Yes that would be very much prefered. Not that I believe that gspca is the best thing ever invented or anything like that. But usb webcam drivers all have a lot in common and gspca handles that good enough, and if we ever want to make improvements like moving usb webcams to use videobuf, having them all as gspca sub drivers means we only need to do it once, as for example all buffer management is done by gspca. Also after looking at the pwc driver oops at unplug, and being reminded at the ref counting with hotplug devices going away and locking nightmare stuff we discussed some time ago, I'm also really glad to only have all that tricky code only once. This will also make reviewing a lot easier as there will be no tricky buffer management and locking, etc. to review. If this is the case I can work on a set of patches to implement our code as a gspca subdriver. As explained above very much: Yes please Also i have a few questions regarding submitting the patches. 1) In addition to sending them to linux-media should I CC them to anyone in particular? I have such a cam and I'm one of the people actively working on gspca, so if you could CC me then I'm sure to notice it and review it, and it can get merged through my mercurial (git alike vcs) tree. 2) The entire patch would likely be about 70k. Should I just send one patch or split the thing up into several? I would hope gspca would shrink the size somewhat :) As for one patch versus incremental patches, as this is a whole new driver one patch will do I guess, I see little use in having non working increments in between. Thanks Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OV7670: getting it working with soc-camera.
On Wed, 17 Jun 2009, Jonathan Cameron wrote:
This is purely for info of anyone else wanting to use the ov7670
with Guennadi's recent work on converted soc-camera to v4l2-subdevs.
It may not be completely minimal, but it's letting me take pictures ;)
Cool, I like it! Not the pictures, but the fact that the required patch
turned out to be so small. Of course, you understand this is not what
we'll eventually commit, but, I think, this is a good start. In principle,
if a device has all parameters fixed, there's no merit in trying to set
them.
Couple of minor queries:
Currently it is assumed that there is a means of telling the chip to
use particular bus params. In the case of this one it doesn't support
anything other than 8 bit. Stuff may get added down the line, but
in meantime does anyone mind if we make icd-ops-set_bus_param
optional in soc-camera?
struct soc_camera_ops will disappear completely anyway, and we don't know
yet what the v4l2-subdev counterpart will look like.
Is there any reason (or advantage) in not specifying the i2c address
in the driver?
Some i2c devices can be configured to respond to one of several i2c
addresses.
Or for that matter why the address is right shifted by
1 in:
v4l_info(client, chip found @ 0x%02x (%s)\n,
client-addr 1, client-adapter-name);
Admittedly the data sheet uses an 'unusual' convention for the
address (separate write and read address which correspond to
a single address of 0x21 with the relevant write bit set as
appropriate).
That's exactly the reason, I think. Many (or most?) datasheets specify i2c
addresses which are a double of Linux i2c address. IIRC this is just a
Linux convention to use the shifted address.
As ever any comments welcome. Thanks to Guennadi Liakhovetski
for his soc-camera work and Hans Verkuil for conversion of the
ov7670 to soc-dev.
Tested against a merge of todays v4l-next tree and Linus' current
with the minor pxa-camera bug I posted earlier fixed and Guennadi's
extensive patch set applied (this requires a few hand merges, but
nothing too nasty).
Good to know.
A couple of comments:
diff --git a/include/media/ov7670_soc.h b/include/media/ov7670_soc.h
new file mode 100644
index 000..2f264b2
--- /dev/null
+++ b/include/media/ov7670_soc.h
@@ -0,0 +1,21 @@
+/* ov7670_soc Camera
+ *
+ * Copyright (C) 2009 Jonathan Cameron ji...@cam.ac.uk
+ *
+ * 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.
+ */
+
+#ifndef __OV7670_SOC_H__
+#define __OV7670_SOC_H__
+
+#include media/soc_camera.h
+
+struct ov7670_soc_camera_info {
+ int gpio_pwr;
+ int gpio_reset;
You should not need these GPIOs...
+ struct soc_camera_link link;
+};
+
+#endif
diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
index 0e2184e..51d432e 100644
--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -19,7 +19,14 @@
#include media/v4l2-chip-ident.h
#include media/v4l2-i2c-drv.h
+#define OV7670_SOC
+
+#ifdef OV7670_SOC
+#include media/ov7670_soc.h
+#include media/soc_camera.h
+#include linux/gpio.h
...this header...
+#endif /* OV7670_SOC */
MODULE_AUTHOR(Jonathan Corbet cor...@lwn.net);
MODULE_DESCRIPTION(A low-level driver for OmniVision ov7670 sensors);
MODULE_LICENSE(GPL);
@@ -1239,19 +1246,94 @@ static const struct v4l2_subdev_ops ov7670_ops = {
};
/* --- */
+#ifdef OV7670_SOC
+
+static unsigned long ov7670_soc_query_bus_param(struct soc_camera_device
*icd)
+{
+ struct soc_camera_link *icl = to_soc_camera_link(icd);
+
+ unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | SOCAM_MASTER |
+ SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_HIGH |
+ SOCAM_DATAWIDTH_8 | SOCAM_DATA_ACTIVE_HIGH;
+
+ return soc_camera_apply_sensor_flags(icl, flags);
+}
+/* This device only supports one bus option */
+static int ov7670_soc_set_bus_param(struct soc_camera_device *icd,
+ unsigned long flags)
+{
+ return 0;
+}
+
+static struct soc_camera_ops ov7670_soc_ops = {
+ .set_bus_param = ov7670_soc_set_bus_param,
+ .query_bus_param = ov7670_soc_query_bus_param,
+};
+
+#define SETFOURCC(type) .name = (#type), .fourcc = (V4L2_PIX_FMT_ ## type)
+static const struct soc_camera_data_format ov7670_soc_fmt_lists[] = {
+ {
+ SETFOURCC(YUYV),
+ .depth = 16,
+ .colorspace = V4L2_COLORSPACE_JPEG,
+ }, {
+ SETFOURCC(RGB565),
+ .depth = 16,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ },
+};
+#endif
static int ov7670_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
+#ifdef OV7670_SOC
+
Re: [PATCH 1/10 - v2] vpfe capture bridge driver for DM355 and DM6446
On Wednesday 17 June 2009 17:02:01 Karicheri, Muralidharan wrote: snip Can you post your latest proposal for the s_bus op? I propose a few changes: the name of the struct should be something like v4l2_bus_settings, the master/slave bit should be renamed to something like 'host_is_master', and we should have two widths: subdev_width and host_width. That way the same structure can be used for both host and subdev, unless some of the polarities are inverted. In that case you need to make two structs, one for host and one for the subdev. It is possible to add info on inverters to the struct, but unless inverters are used a lot more frequently than I expect I am inclined not to do that at this time. [MK]Today I am planning to send my v3 version of the vpfe capture patch and also tvp514x patch since Vaibhav is pre-occupied with some other activities. I have discussed the changes with Vaibhav for this driver. For s_bus, I will try if I can send a patch today. BTW, do you expect me to add one bool for active high, one for active low etc as done in SoC camera ? Since I remain opposed to autonegotiation, there is IMO no need for this. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] adding support for setting bus parameters in sub device
On Wednesday 17 June 2009 17:43:42 m-kariche...@ti.com wrote:
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
This patch adds support for setting bus parameters such as bus type
(Raw Bayer or Raw YUV image data bus), bus width (example 10 bit raw
image data bus, 10 bit BT.656 etc.), and polarities (vsync, hsync, field
etc) in sub device. This allows bridge driver to configure the sub device
bus for a specific set of bus parameters through s_bus() function call.
This also can be used to define platform specific bus parameters for
host and sub-devices.
Reviewed by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
include/media/v4l2-subdev.h | 40
1 files changed, 40
insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..2f5ec98 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -37,6 +37,43 @@ struct v4l2_decode_vbi_line {
u32 type; /* VBI service type (V4L2_SLICED_*). 0 if no
service found
*/ };
+/*
+ * Some sub-devices are connected to the host/bridge device through a
bus that + * carries the clock, vsync, hsync and data. Some interfaces
such as BT.656 + * carries the sync embedded in the data where as others
have separate line + * carrying the sync signals. The structure below is
used to define bus + * configuration parameters for host as well as
sub-device
+ */
+enum v4l2_subdev_bus_type {
+ /* Raw YUV image data bus */
+ V4L2_SUBDEV_BUS_RAW_YUV,
+ /* Raw Bayer image data bus */
+ V4L2_SUBDEV_BUS_RAW_BAYER
+};
Remove the _subdev prefix from the enum above.
+
+struct v4l2_bus_settings {
+ /* yuv or bayer image data bus */
+ enum v4l2_subdev_bus_type type;
+ /* subdev bus width */
+ u8 subdev_width;
+ /* host bus width */
+ u8 host_width;
+ /* embedded sync, set this when sync is embedded in the data stream */
+ unsigned embedded_sync:1;
+ /* master or slave */
+ unsigned host_is_master:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_vsync:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_hsync:1;
+ /* 0 - low to high , 1 - high to low */
+ unsigned pol_field:1;
+ /* 0 - sample at falling edge , 1 - sample at rising edge */
+ unsigned pol_pclock:1;
I'm not sure whether the pol_ prefix is correct here. Perhaps edge_pclock is
a more appropriate name.
Regards,
Hans
+ /* 0 - active low , 1 - active high */
+ unsigned pol_data:1;
+};
+
/* Sub-devices are devices that are connected somehow to the main bridge
device. These devices are usually audio/video
muxers/encoders/decoders or sensors and webcam controllers.
@@ -199,6 +236,8 @@ struct v4l2_subdev_audio_ops {
s_routing: see s_routing in audio_ops, except this version is for
video devices.
+
+ s_bus: set bus parameters in sub device to configure the bus
*/
struct v4l2_subdev_video_ops {
int (*s_routing)(struct v4l2_subdev *sd, u32 input, u32 output, u32
config); @@ -219,6 +258,7 @@ struct v4l2_subdev_video_ops {
int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum
*fsize); int (*enum_frameintervals)(struct v4l2_subdev *sd, struct
v4l2_frmivalenum *fival); + int (*s_bus)(struct v4l2_subdev *sd, const
struct v4l2_bus_settings *bus); };
struct v4l2_subdev_ops {
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
--
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: bttv problem loading takes about several minutes
Hi, The card is a winfast tv 2000 xp rm edition lspci -vvv says: 00:0b.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (4000ns min, 1ns max) Interrupt: pin A routed to IRQ 19 Region 0: Memory at f780 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: bttv Kernel modules: bttv 00:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (1000ns min, 63750ns max) Interrupt: pin A routed to IRQ 5 Region 0: Memory at f700 (32-bit, prefetchable) [size=4K] Capabilities: [44] Vital Product Data ? Capabilities: [4c] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- HTH. Halim -- Halim Sahin E-Mail: halim.sahin (at) t-online.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
[PATCH 5/11 - v3] ccdc types used across ccdc modules for vpfe capture driver
From: Muralidharan Karicheri m-kariche...@ti.com
common types used across CCDC modules
No change from last version
Reviewed by: Hans Verkuil hverk...@xs4all.nl
Reviewed by: Laurent Pinchart laurent.pinch...@skynet.be
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
include/media/davinci/ccdc_types.h | 43
1 files changed, 43 insertions(+), 0 deletions(-)
create mode 100644 include/media/davinci/ccdc_types.h
diff --git a/include/media/davinci/ccdc_types.h
b/include/media/davinci/ccdc_types.h
new file mode 100644
index 000..5773874
--- /dev/null
+++ b/include/media/davinci/ccdc_types.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ **/
+#ifndef _CCDC_TYPES_H
+#define _CCDC_TYPES_H
+enum ccdc_pixfmt {
+ CCDC_PIXFMT_RAW,
+ CCDC_PIXFMT_YCBCR_16BIT,
+ CCDC_PIXFMT_YCBCR_8BIT
+};
+
+enum ccdc_frmfmt {
+ CCDC_FRMFMT_PROGRESSIVE,
+ CCDC_FRMFMT_INTERLACED
+};
+
+/* PIXEL ORDER IN MEMORY from LSB to MSB */
+/* only applicable for 8-bit input mode */
+enum ccdc_pixorder {
+ CCDC_PIXORDER_YCBYCR,
+ CCDC_PIXORDER_CBYCRY,
+};
+
+enum ccdc_buftype {
+ CCDC_BUFTYPE_FLD_INTERLEAVED,
+ CCDC_BUFTYPE_FLD_SEPARATED
+};
+#endif
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/11 - v3] dm355 ccdc module for vpfe capture driver
From: Muralidharan Karicheri m-kariche...@ti.com
DM355 CCDC hw module
Adds ccdc hw module for DM355 CCDC. This registers with the bridge
driver a set of hw_ops for configuring the CCDC for a specific
decoder device connected to vpfe.
The module description and owner information added
Reviewed by: Hans Verkuil hverk...@xs4all.nl
Reviewed by: Laurent Pinchart laurent.pinch...@skynet.be
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/davinci/dm355_ccdc.c | 1163 +
drivers/media/video/davinci/dm355_ccdc_regs.h | 310 +++
include/media/davinci/dm355_ccdc.h| 336 +++
3 files changed, 1809 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/dm355_ccdc.c
create mode 100644 drivers/media/video/davinci/dm355_ccdc_regs.h
create mode 100644 include/media/davinci/dm355_ccdc.h
diff --git a/drivers/media/video/davinci/dm355_ccdc.c
b/drivers/media/video/davinci/dm355_ccdc.c
new file mode 100644
index 000..69e38d0
--- /dev/null
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -0,0 +1,1163 @@
+/*
+ * Copyright (C) 2005-2009 Texas Instruments Inc
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * CCDC hardware module for DM355
+ * --
+ *
+ * This module is for configuring DM355 CCD controller of VPFE to capture
+ * Raw yuv or Bayer RGB data from a decoder. CCDC has several modules
+ * such as Defect Pixel Correction, Color Space Conversion etc to
+ * pre-process the Bayer RGB data, before writing it to SDRAM. This
+ * module also allows application to configure individual
+ * module parameters through VPFE_CMD_S_CCDC_RAW_PARAMS IOCTL.
+ * To do so, application include dm355_ccdc.h and vpfe_capture.h header
+ * files. The setparams() API is called by vpfe_capture driver
+ * to configure module parameters
+ *
+ * TODO: 1) Raw bayer parameter settings and bayer capture
+ * 2) Split module parameter structure to module specific ioctl structs
+ * 3) add support for lense shading correction
+ * 4) investigate if enum used for user space type definition
+ * to be replaced by #defines or integer
+ */
+#include linux/platform_device.h
+#include linux/uaccess.h
+#include linux/videodev2.h
+#include media/davinci/dm355_ccdc.h
+#include media/davinci/vpss.h
+#include dm355_ccdc_regs.h
+#include ccdc_hw_device.h
+
+MODULE_LICENSE(GPL);
+MODULE_DESCRIPTION(CCDC Driver for DM355);
+MODULE_AUTHOR(Texas Instruments);
+
+static struct device *dev;
+
+/* Object for CCDC raw mode */
+static struct ccdc_params_raw ccdc_hw_params_raw = {
+ .pix_fmt = CCDC_PIXFMT_RAW,
+ .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+ .win = CCDC_WIN_VGA,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .gain = {
+ .r_ye = 256,
+ .gb_g = 256,
+ .gr_cy = 256,
+ .b_mg = 256
+ },
+ .config_params = {
+ .datasft = 2,
+ .data_sz = CCDC_DATA_10BITS,
+ .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
+ .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
+ .alaw = {
+ .gama_wd = 2,
+ },
+ .blk_clamp = {
+ .sample_pixel = 1,
+ .dc_sub = 25
+ },
+ .col_pat_field0 = {
+ .olop = CCDC_GREEN_BLUE,
+ .olep = CCDC_BLUE,
+ .elop = CCDC_RED,
+ .elep = CCDC_GREEN_RED
+ },
+ .col_pat_field1 = {
+ .olop = CCDC_GREEN_BLUE,
+ .olep = CCDC_BLUE,
+ .elop = CCDC_RED,
+ .elep = CCDC_GREEN_RED
+ },
+ },
+};
+
+
+/* Object for CCDC ycbcr mode */
+static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
+ .win = CCDC_WIN_PAL,
+ .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+ .frm_fmt = CCDC_FRMFMT_INTERLACED,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .bt656_enable = 1,
+ .pix_order =
[PATCH 7/11 - v3] DM355 platform changes for vpfe capture driver
From: Muralidharan Karicheri m-kariche...@ti.com
DM355 platform and board setup
This has platform and board setup changes to support vpfe capture
driver for DM355 EVMs.
summary of changes
1) replaced v4l2_routing structure with vpfe structure for route
2) ccdc bus parameter settings added
3) input name string changed to Composite and S-Video
Reviewed by: Hans Verkuil hverk...@xs4all.nl
Reviewed by: Laurent Pinchart laurent.pinch...@skynet.be
Reviewed by: Kevin Hilman khil...@deeprootsystems.com
Reviewed by: David Brownell davi...@pacbell.net
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to Davinci GIT Tree
arch/arm/mach-davinci/board-dm355-evm.c| 76 -
arch/arm/mach-davinci/dm355.c | 83
arch/arm/mach-davinci/include/mach/dm355.h |2 +
arch/arm/mach-davinci/include/mach/mux.h |9 +++
4 files changed, 167 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index 5ac2f56..513be53 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -20,6 +20,8 @@
#include linux/io.h
#include linux/gpio.h
#include linux/clk.h
+#include linux/videodev2.h
+#include media/tvp514x.h
#include linux/spi/spi.h
#include linux/spi/eeprom.h
@@ -134,12 +136,22 @@ static void dm355evm_mmcsd_gpios(unsigned gpio)
dm355evm_mmc_gpios = gpio;
}
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
+
static struct i2c_board_info dm355evm_i2c_info[] = {
- { I2C_BOARD_INFO(dm355evm_msp, 0x25),
+ { I2C_BOARD_INFO(dm355evm_msp, 0x25),
.platform_data = dm355evm_mmcsd_gpios,
- /* plus irq */ },
+ },
+ {
+ I2C_BOARD_INFO(tvp5146, 0x5d),
+ .platform_data = tvp5146_pdata,
+ },
+ /* { plus irq }, */
/* { I2C_BOARD_INFO(tlv320aic3x, 0x1b), }, */
- /* { I2C_BOARD_INFO(tvp5146, 0x5d), }, */
};
static void __init evm_init_i2c(void)
@@ -178,6 +190,62 @@ static struct platform_device dm355evm_dm9000 = {
.num_resources = ARRAY_SIZE(dm355evm_dm9000_rsrc),
};
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI2B,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ }
+};
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .sub_devs = vpfe_sub_devs,
+ .card_name = DM355 EVM,
+ .ccdc = DM355 CCDC,
+};
+
static struct platform_device *davinci_evm_devices[] __initdata = {
dm355evm_dm9000,
davinci_nand_device,
@@ -189,6 +257,8 @@ static struct davinci_uart_config uart_config __initdata = {
static void __init dm355_evm_map_io(void)
{
+ /* setup input configuration for VPFE input devices */
+ dm355_set_vpfe_config(vpfe_cfg);
dm355_init();
}
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index f0b10b4..7a7b020 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -481,6 +481,14 @@ INT_CFG(DM355, INT_EDMA_TC1_ERR, 4,1,1,
false)
EVT_CFG(DM355, EVT8_ASP1_TX,0,1,0, false)
EVT_CFG(DM355, EVT9_ASP1_RX,1,1,0, false)
EVT_CFG(DM355, EVT26_MMC0_RX, 2,1,0, false)
+
+MUX_CFG(DM355, VIN_PCLK, 0, 14,1,1, false)
+MUX_CFG(DM355, VIN_CAM_WEN,0, 13,1,1, false)
+MUX_CFG(DM355,
[PATCH 9/11 - v3] common vpss module for video drivers
From: Muralidharan Karicheri m-kariche...@ti.com
common voss module for video drivers
This is a new module added for vpss library functions that are
used for configuring vpss system module. All video drivers will
include vpss.h header file and call functions defined in this
module to configure vpss system module.
Following are the updates:-
1) added module owner, description and GPL macros
2) some error conditions addressed in the probe
Reviewed by: Hans Verkuil hverk...@xs4all.nl
Reviewed by: Laurent Pinchart laurent.pinch...@skynet.be
Reviewed by: Alexey Klimov klimov.li...@gmail.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/davinci/vpss.c | 301
include/media/davinci/vpss.h | 69
2 files changed, 370 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpss.c
create mode 100644 include/media/davinci/vpss.h
diff --git a/drivers/media/video/davinci/vpss.c
b/drivers/media/video/davinci/vpss.c
new file mode 100644
index 000..6d709ca
--- /dev/null
+++ b/drivers/media/video/davinci/vpss.c
@@ -0,0 +1,301 @@
+/*
+ * Copyright (C) 2009 Texas Instruments.
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ * common vpss driver for all video drivers.
+ */
+#include linux/kernel.h
+#include linux/sched.h
+#include linux/init.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/spinlock.h
+#include linux/compiler.h
+#include linux/io.h
+#include mach/hardware.h
+#include media/davinci/vpss.h
+
+MODULE_LICENSE(GPL);
+MODULE_DESCRIPTION(VPSS Driver);
+MODULE_AUTHOR(Texas Instruments);
+
+/* DM644x defines */
+#define DM644X_SBL_PCR_VPSS(4)
+
+/* vpss BL register offsets */
+#define DM355_VPSSBL_CCDCMUX 0x1c
+/* vpss CLK register offsets */
+#define DM355_VPSSCLK_CLKCTRL 0x04
+/* masks and shifts */
+#define VPSS_HSSISEL_SHIFT 4
+
+/*
+ * vpss operations. Depends on platform. Not all functions are available
+ * on all platforms. The api, first check if a functio is available before
+ * invoking it. In the probe, the function ptrs are intialized based on
+ * vpss name. vpss name can be dm355_vpss, dm644x_vpss etc.
+ */
+struct vpss_hw_ops {
+ /* enable clock */
+ int (*enable_clock)(enum vpss_clock_sel clock_sel, int en);
+ /* select input to ccdc */
+ void (*select_ccdc_source)(enum vpss_ccdc_source_sel src_sel);
+ /* clear wbl overlflow bit */
+ int (*clear_wbl_overflow)(enum vpss_wbl_sel wbl_sel);
+};
+
+/* vpss configuration */
+struct vpss_oper_config {
+ __iomem void *vpss_bl_regs_base;
+ __iomem void *vpss_regs_base;
+ struct resource *r1;
+ resource_size_t len1;
+ struct resource *r2;
+ resource_size_t len2;
+ char vpss_name[32];
+ spinlock_t vpss_lock;
+ struct vpss_hw_ops hw_ops;
+};
+
+static struct vpss_oper_config oper_cfg;
+
+/* register access routines */
+static inline u32 bl_regr(u32 offset)
+{
+ return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
+}
+
+static inline void bl_regw(u32 val, u32 offset)
+{
+ __raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
+}
+
+static inline u32 vpss_regr(u32 offset)
+{
+ return __raw_readl(oper_cfg.vpss_regs_base + offset);
+}
+
+static inline void vpss_regw(u32 val, u32 offset)
+{
+ __raw_writel(val, oper_cfg.vpss_regs_base + offset);
+}
+
+static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+ bl_regw(src_sel VPSS_HSSISEL_SHIFT, DM355_VPSSBL_CCDCMUX);
+}
+
+int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+ if (!oper_cfg.hw_ops.select_ccdc_source)
+ return -1;
+
+ dm355_select_ccdc_source(src_sel);
+ return 0;
+}
+EXPORT_SYMBOL(vpss_select_ccdc_source);
+
+static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel wbl_sel)
+{
+ u32 mask = 1, val;
+
+ if (wbl_sel VPSS_PCR_AEW_WBL_0 ||
+ wbl_sel VPSS_PCR_CCDC_WBL_O)
+ return -1;
+
+ /* writing a 0 clear the overflow */
+ mask = ~(mask wbl_sel);
+ val = bl_regr(DM644X_SBL_PCR_VPSS) mask;
+ bl_regw(val, DM644X_SBL_PCR_VPSS);
+
[PATCH 4/11 - v3] dm644x ccdc module for vpfe capture driver
From: Muralidharan Karicheri m-kariche...@ti.com
DM644x CCDC hw module
This is the hw module for DM644x CCDC. This registers with the
vpfe capture driver and provides a set of hw_ops to configure
CCDC for a specific decoder device connected to the VPFE
Module description, GPL and owner information MACROs added at the top
Reviewed by: Hans Verkuil hverk...@xs4all.nl
Reviewed by: Laurent Pinchart laurent.pinch...@skynet.be
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/davinci/dm644x_ccdc.c | 878
drivers/media/video/davinci/dm644x_ccdc_regs.h | 145
include/media/davinci/dm644x_ccdc.h| 184 +
3 files changed, 1207 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/dm644x_ccdc.c
create mode 100644 drivers/media/video/davinci/dm644x_ccdc_regs.h
create mode 100644 include/media/davinci/dm644x_ccdc.h
diff --git a/drivers/media/video/davinci/dm644x_ccdc.c
b/drivers/media/video/davinci/dm644x_ccdc.c
new file mode 100644
index 000..2f19a91
--- /dev/null
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -0,0 +1,878 @@
+/*
+ * Copyright (C) 2006-2009 Texas Instruments Inc
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * CCDC hardware module for DM6446
+ * --
+ *
+ * This module is for configuring CCD controller of DM6446 VPFE to capture
+ * Raw yuv or Bayer RGB data from a decoder. CCDC has several modules
+ * such as Defect Pixel Correction, Color Space Conversion etc to
+ * pre-process the Raw Bayer RGB data, before writing it to SDRAM. This
+ * module also allows application to configure individual
+ * module parameters through VPFE_CMD_S_CCDC_RAW_PARAMS IOCTL.
+ * To do so, application includes dm644x_ccdc.h and vpfe_capture.h header
+ * files. The setparams() API is called by vpfe_capture driver
+ * to configure module parameters. This file is named DM644x so that other
+ * variants such DM6443 may be supported using the same module.
+ *
+ * TODO: Test Raw bayer parameter settings and bayer capture
+ * Split module parameter structure to module specific ioctl structs
+ * investigate if enum used for user space type definition
+ * to be replaced by #defines or integer
+ */
+#include linux/platform_device.h
+#include linux/uaccess.h
+#include linux/videodev2.h
+#include media/davinci/dm644x_ccdc.h
+#include media/davinci/vpss.h
+#include dm644x_ccdc_regs.h
+#include ccdc_hw_device.h
+
+MODULE_LICENSE(GPL);
+MODULE_DESCRIPTION(CCDC Driver for DM6446);
+MODULE_AUTHOR(Texas Instruments);
+
+static struct device *dev;
+
+/* Object for CCDC raw mode */
+static struct ccdc_params_raw ccdc_hw_params_raw = {
+ .pix_fmt = CCDC_PIXFMT_RAW,
+ .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+ .win = CCDC_WIN_VGA,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .config_params = {
+ .data_sz = CCDC_DATA_10BITS,
+ },
+};
+
+/* Object for CCDC ycbcr mode */
+static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
+ .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+ .frm_fmt = CCDC_FRMFMT_INTERLACED,
+ .win = CCDC_WIN_PAL,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .bt656_enable = 1,
+ .pix_order = CCDC_PIXORDER_CBYCRY,
+ .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
+};
+
+#define CCDC_MAX_RAW_YUV_FORMATS 2
+
+/* Raw Bayer formats */
+static u32 ccdc_raw_bayer_pix_formats[] =
+ {V4L2_PIX_FMT_SBGGR8, V4L2_PIX_FMT_SBGGR16};
+
+/* Raw YUV formats */
+static u32 ccdc_raw_yuv_pix_formats[] =
+ {V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YUYV};
+
+static void *__iomem ccdc_base_addr;
+static int ccdc_addr_size;
+static enum vpfe_hw_if_type ccdc_if_type;
+
+/* register access routines */
+static inline u32 regr(u32 offset)
+{
+ return __raw_readl(ccdc_base_addr + offset);
+}
+
+static inline void regw(u32 val, u32 offset)
+{
+ __raw_writel(val, ccdc_base_addr + offset);
+}
+
+static void ccdc_set_ccdc_base(void *addr, int size)
+{
+ ccdc_base_addr = addr;
+ ccdc_addr_size = size;
+}
+
+static void ccdc_enable(int flag)
+{
+
[PATCH 6/11 - v3] Makefile and config files for vpfe capture driver
From: Muralidharan Karicheri m-kariche...@ti.com Makefile and config files for the driver This adds Makefile and Kconfig changes to build vpfe capture driver. No change in this version Reviewed by: Hans Verkuil hverk...@xs4all.nl Reviewed by: Laurent Pinchart laurent.pinch...@skynet.be Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- Applies to v4l-dvb repository drivers/media/video/Kconfig | 49 ++ drivers/media/video/Makefile |2 + drivers/media/video/davinci/Makefile |9 ++ 3 files changed, 60 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/davinci/Makefile diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 94f4405..8a1bd1c 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -497,6 +497,55 @@ config VIDEO_VIVI Say Y here if you want to test video apps or debug V4L devices. In doubt, say N. +config VIDEO_VPSS_SYSTEM + tristate VPSS System module driver + depends on ARCH_DAVINCI + help + Support for vpss system module for video driver + default y + +config VIDEO_VPFE_CAPTURE + tristate VPFE Video Capture Driver + depends on VIDEO_V4L2 ARCH_DAVINCI + select VIDEOBUF_DMA_CONTIG + help + Support for DM VPFE based frame grabber. This is the + common V4L2 module for following DMXXX SoCs from Texas + Instruments:- DM6446 DM355. + + To compile this driver as a module, choose M here: the + module will be called vpfe-capture. + +config VIDEO_DM6446_CCDC + tristate DM6446 CCDC HW module + depends on ARCH_DAVINCI_DM644x VIDEO_VPFE_CAPTURE + select VIDEO_VPSS_SYSTEM + default y + help + Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces + with decoder modules such as TVP5146 over BT656 or + sensor module such as MT9T001 over a raw interface. This + module configures the interface and CCDC/ISIF to do + video frame capture from slave decoders. + + To compile this driver as a module, choose M here: the + module will be called vpfe. + +config VIDEO_DM355_CCDC + tristate DM355 CCDC HW module + depends on ARCH_DAVINCI_DM355 VIDEO_VPFE_CAPTURE + select VIDEO_VPSS_SYSTEM + default y + help + Enables DM355 CCD hw module. DM355 CCDC hw interfaces + with decoder modules such as TVP5146 over BT656 or + sensor module such as MT9T001 over a raw interface. This + module configures the interface and CCDC/ISIF to do + video frame capture from a slave decoders + + To compile this driver as a module, choose M here: the + module will be called vpfe. + source drivers/media/video/bt8xx/Kconfig config VIDEO_PMS diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 7fb3add..1f28495 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -153,6 +153,8 @@ 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 +obj-$(CONFIG_ARCH_DAVINCI) += davinci/ + obj-$(CONFIG_VIDEO_AU0828) += au0828/ obj-$(CONFIG_USB_VIDEO_CLASS) += uvc/ diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile new file mode 100644 index 000..b84a405 --- /dev/null +++ b/drivers/media/video/davinci/Makefile @@ -0,0 +1,9 @@ +# +# Makefile for the davinci video device drivers. +# + +# Capture: DM6446 and DM355 +obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o +obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o +obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o +obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o -- 1.6.0.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/11 - v3] Makefile and config file changes for davinci git tree
From: Muralidharan Karicheri m-kariche...@ti.com Makefile and config files for vpfe capture driver that applies to DaVinci GIT tree only. This is added to help in applying this patch to DaVinci GIT tree since the tree has some obsolete davinci drivers that is being removed by this patch. These files are not available in upstream kernel. Please use this patch instead of Patch #6 of this series for DaVinci GIT tree. Reviewed by: Hans Verkuil hverk...@xs4all.nl Reviewed by: Laurent Pinchart laurent.pinch...@skynet.be Reviewed by: Kevin Hilman khil...@deeprootsystems.com Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- Applies to DaVinci GIT tree drivers/media/video/Kconfig | 57 + drivers/media/video/Makefile |6 +--- drivers/media/video/davinci/Makefile |9 + 3 files changed, 53 insertions(+), 19 deletions(-) create mode 100644 drivers/media/video/davinci/Makefile diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index e037e3f..ee6806c 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -479,25 +479,54 @@ config VIDEO_VIVI Say Y here if you want to test video apps or debug V4L devices. In doubt, say N. -config VIDEO_TVP5146 - tristate TVP5146 video decoder - depends on I2C ARCH_DAVINCI +config VIDEO_VPSS_SYSTEM + tristate VPSS System module driver + depends on ARCH_DAVINCI help - Support for I2C bus based TVP5146 configuration. - - To compile this driver as a module, choose M here: the - module will be called tvp5146. + Support for vpss system module for video driver + default y -config VIDEO_DAVINCI - tristate Davinci Video Capture - depends on VIDEO_DEV VIDEO_TVP5146 ARCH_DAVINCI - select VIDEOBUF_GEN - select VIDEOBUF_DMA_SG +config VIDEO_VPFE_CAPTURE + tristate VPFE Video Capture Driver + depends on VIDEO_V4L2 ARCH_DAVINCI + select VIDEOBUF_DMA_CONTIG help - Support for Davinci based frame grabber through CCDC. + Support for DM VPFE based frame grabber. This is the + common V4L2 module for following DMXXX SoCs from Texas + Instruments:- DM6446 DM355. To compile this driver as a module, choose M here: the - module will be called vpfe. + module will be called vpfe-capture. + +config VIDEO_DM6446_CCDC + tristate DM6446 CCDC HW module + depends on ARCH_DAVINCI_DM644x VIDEO_VPFE_CAPTURE + select VIDEO_VPSS_SYSTEM + default y + help + Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces + with decoder modules such as TVP5146 over BT656 or + sensor module such as MT9T001 over a raw interface. This + module configures the interface and CCDC/ISIF to do + video frame capture from slave decoders. + + To compile this driver as a module, choose M here: the + module will be called vpfe. + +config VIDEO_DM355_CCDC + tristate DM355 CCDC HW module + depends on ARCH_DAVINCI_DM355 VIDEO_VPFE_CAPTURE + select VIDEO_VPSS_SYSTEM + default y + help + Enables DM355 CCD hw module. DM355 CCDC hw interfaces + with decoder modules such as TVP5146 over BT656 or + sensor module such as MT9T001 over a raw interface. This + module configures the interface and CCDC/ISIF to do + video frame capture from a slave decoders + + To compile this driver as a module, choose M here: the + module will be called vpfe. source drivers/media/video/bt8xx/Kconfig diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 12ddb9a..76db635 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -10,8 +10,6 @@ stkwebcam-objs:= stk-webcam.o stk-sensor.o omap2cam-objs := omap24xxcam.o omap24xxcam-dma.o -davinci-vpfe-objs := ccdc_davinci.o davinci_vpfe.o - videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o obj-$(CONFIG_VIDEO_DEV) += videodev.o v4l2-int-device.o @@ -133,9 +131,6 @@ obj-$(CONFIG_USB_S2255) += s2255drv.o obj-$(CONFIG_VIDEO_IVTV) += ivtv/ obj-$(CONFIG_VIDEO_CX18) += cx18/ -obj-$(CONFIG_VIDEO_DAVINCI) += davinci-vpfe.o -obj-$(CONFIG_VIDEO_TVP5146) += tvp5146.o - obj-$(CONFIG_VIDEO_VIVI) += vivi.o obj-$(CONFIG_VIDEO_CX23885) += cx23885/ @@ -152,6 +147,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9V022)+= mt9v022.o obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o +obj-$(CONFIG_ARCH_DAVINCI) += davinci/ obj-$(CONFIG_VIDEO_AU0828) += au0828/ diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile new file mode 100644 index
[PATCH 0/11 - v3] ARM: DaVinci: Video: DM355/DM6446 VPFE Capture driver
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com Big Thanks to all reviewers who have contributed to this driver by reviewing and offering valuable comments. VPFE Capture driver for DaVinci Media SOCs :- DM355 and DM6446 This is the version v3 of the patch series. This is the reworked version of the driver based on comments received against the last version (v2) of the patch and is expected to be final version candidate for merge to upstream kernel +++ These patches add support for VPFE (Video Processing Front End) based video capture on DM355 and DM6446 EVMs. For more details on the hardware configuration and capabilities, please refer the vpfe_capture.c header. This patch set consists of following:- Patch 1: VPFE Capture bridge driver Patch 2: CCDC hw device header file Patch 3: DM355 CCDC hw module Patch 4: DM644x CCDC hw module Patch 5: ccdc types used across CCDC modules Patch 6: Makefile and config files for the driver Patch 7: DM355 platform and board setup Patch 8: DM644x platform and board setup Patch 9: common vpss hw module for video drivers Patch 10: Remove outdated driver files from davinci git tree Patch 11: Makefile and config files for the davinci git tree (New from v2) NOTE: 1. Patches 10-11 are only for DaVinci GIT tree. Others applies to DaVinci GIT and v4l-dvb 2. Dependent on the TVP514x decoder driver patch for migrating the driver to sub device model from Vaibhav Hiremath. I am sending the reworked version of this patch instead of Vaibhav. Following tests are performed. 1) Capture and display video (PAL NTSC) from tvp5146 decoder. Displayed using fbdev device driver available on davinci git tree 2) Tested with driver built statically and dynamically Muralidhara Karicheri Reviewed by: Hans Verkuil hverk...@xs4all.nl Reviewed by: Laurent Pinchart laurent.pinch...@skynet.be Reviewed by: Alexey Klimov klimov.li...@gmail.com Reviewed by: Kevin Hilman khil...@deeprootsystems.com Reviewed by: David Brownell davi...@pacbell.net Signed-off-by: Muralidharan Karicheri m-kariche...@ti.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 2/11 - v3] ccdc hw device header file for vpfe capture
From: Muralidharan Karicheri m-kariche...@ti.com
CCDC hw device header file
Adds ccdc hw device header for vpfe capture driver
No change from last version
Reviewed by: Hans Verkuil hverk...@xs4all.nl
Reviewed by: Laurent Pinchart laurent.pinch...@skynet.be
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/davinci/ccdc_hw_device.h | 110 ++
1 files changed, 110 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/ccdc_hw_device.h
diff --git a/drivers/media/video/davinci/ccdc_hw_device.h
b/drivers/media/video/davinci/ccdc_hw_device.h
new file mode 100644
index 000..86b9b35
--- /dev/null
+++ b/drivers/media/video/davinci/ccdc_hw_device.h
@@ -0,0 +1,110 @@
+/*
+ * Copyright (C) 2008-2009 Texas Instruments Inc
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * ccdc device API
+ */
+#ifndef _CCDC_HW_DEVICE_H
+#define _CCDC_HW_DEVICE_H
+
+#ifdef __KERNEL__
+#include linux/videodev2.h
+#include linux/device.h
+#include media/davinci/vpfe_types.h
+#include media/davinci/ccdc_types.h
+
+/*
+ * ccdc hw operations
+ */
+struct ccdc_hw_ops {
+ /* Pointer to initialize function to initialize ccdc device */
+ int (*open) (struct device *dev);
+ /* Pointer to deinitialize function */
+ int (*close) (struct device *dev);
+ /* set ccdc base address */
+ void (*set_ccdc_base)(void *base, int size);
+ /* Pointer to function to enable or disable ccdc */
+ void (*enable) (int en);
+ /* reset sbl. only for 6446 */
+ void (*reset) (void);
+ /* enable output to sdram */
+ void (*enable_out_to_sdram) (int en);
+ /* Pointer to function to set hw parameters */
+ int (*set_hw_if_params) (struct vpfe_hw_if_param *param);
+ /* get interface parameters */
+ int (*get_hw_if_params) (struct vpfe_hw_if_param *param);
+ /*
+* Pointer to function to set parameters. Used
+* for implementing VPFE_S_CCDC_PARAMS
+*/
+ int (*set_params) (void *params);
+ /*
+* Pointer to function to get parameter. Used
+* for implementing VPFE_G_CCDC_PARAMS
+*/
+ int (*get_params) (void *params);
+ /* Pointer to function to configure ccdc */
+ int (*configure) (void);
+
+ /* Pointer to function to set buffer type */
+ int (*set_buftype) (enum ccdc_buftype buf_type);
+ /* Pointer to function to get buffer type */
+ enum ccdc_buftype (*get_buftype) (void);
+ /* Pointer to function to set frame format */
+ int (*set_frame_format) (enum ccdc_frmfmt frm_fmt);
+ /* Pointer to function to get frame format */
+ enum ccdc_frmfmt (*get_frame_format) (void);
+ /* enumerate hw pix formats */
+ int (*enum_pix)(u32 *hw_pix, int i);
+ /* Pointer to function to set buffer type */
+ u32 (*get_pixel_format) (void);
+ /* Pointer to function to get pixel format. */
+ int (*set_pixel_format) (u32 pixfmt);
+ /* Pointer to function to set image window */
+ int (*set_image_window) (struct v4l2_rect *win);
+ /* Pointer to function to set image window */
+ void (*get_image_window) (struct v4l2_rect *win);
+ /* Pointer to function to get line length */
+ unsigned int (*get_line_length) (void);
+
+ /* Query CCDC control IDs */
+ int (*queryctrl)(struct v4l2_queryctrl *qctrl);
+ /* Set CCDC control */
+ int (*set_control)(struct v4l2_control *ctrl);
+ /* Get CCDC control */
+ int (*get_control)(struct v4l2_control *ctrl);
+
+ /* Pointer to function to set frame buffer address */
+ void (*setfbaddr) (unsigned long addr);
+ /* Pointer to function to get field id */
+ int (*getfid) (void);
+};
+
+struct ccdc_hw_device {
+ /* ccdc device name */
+ char name[32];
+ /* module owner */
+ struct module *owner;
+ /* hw ops */
+ struct ccdc_hw_ops hw_ops;
+};
+
+/* Used by CCDC module to register unregister with vpfe capture driver */
+int vpfe_register_ccdc_device(struct ccdc_hw_device *dev);
+void vpfe_unregister_ccdc_device(struct ccdc_hw_device *dev);
+
+#endif
+#endif
--
1.6.0.4
--
To unsubscribe from this
Re: bttv problem loading takes about several minutes
Hi, On Mi, Jun 17, 2009 at 10:06:26 +0200, Hans Verkuil wrote: The log is from bttv version 0.9.17. The new code is only present in version 0.9.18. So this is definitely not related to any of my changes. Yes it's from a debian lenny kernel 2.6.26. But I have tested latest v4l-dvb with the same result under 2.6.28 (ubuntu 9.04). The code in bttv_probe (bttv-driver.c) does this: if (bttv_verbose) bttv_gpio_tracking(btv,init); /* needs to be done before i2c is registered */ bttv_init_card1(btv); /* register i2c + gpio */ init_bttv_i2c(btv); /* some card-specific stuff (needs working i2c) */ bttv_init_card2(btv); So it looks like it can be either bttv_init_card1 or init_bttv_i2c that is causing the delay. Halim, can you try to put some printk() statements in between the calls above to see which call is taking so long? Actually, it would be nice if you are able to 'drill-down' as well in whatever function is causing the delay, since I truly don't see what might be delaying things for you. Yes I will test this tomorrow. Thanks a lot! Halim -- 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] TVP514x: Migration to sub-device framework
From: Muralidharan Karicheri m-kariche...@ti.com
This patch converts TVP514x driver to sub-device framework
from V4L2-int framework.
NOTE: Please note that this patch was tested on DM355 and DM6446
and not tested on OMAP platform
Changes from v2 based on review comments (Taken over this work from
Vaibhav)
- removed __exit for tvp514x_remove
- removed v4l2_i2c_driver_data and use new model similar to ths7303
- changed state to streaming
TODO:
- Add support for some basic video/core functionality like,
.g_chip_ident
.reset
.g_input_status
- Migration of OMAP master driver to validate this driver
- validate on OMAP boards
Reviewed by :Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Hardik Shah hardik.s...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/tvp514x.c | 875 ++--
drivers/media/video/tvp514x_regs.h | 10 -
include/media/tvp514x.h|4 -
3 files changed, 349 insertions(+), 540 deletions(-)
diff --git a/drivers/media/video/tvp514x.c b/drivers/media/video/tvp514x.c
index 3750f7f..6063b57 100644
--- a/drivers/media/video/tvp514x.c
+++ b/drivers/media/video/tvp514x.c
@@ -31,7 +31,10 @@
#include linux/i2c.h
#include linux/delay.h
#include linux/videodev2.h
-#include media/v4l2-int-device.h
+
+#include media/v4l2-device.h
+#include media/v4l2-common.h
+#include media/v4l2-chip-ident.h
#include media/tvp514x.h
#include tvp514x_regs.h
@@ -49,13 +52,11 @@ static int debug;
module_param(debug, bool, 0644);
MODULE_PARM_DESC(debug, Debug level (0-1));
-#define dump_reg(client, reg, val) \
- do {\
- val = tvp514x_read_reg(client, reg);\
- v4l_info(client, Reg(0x%.2X): 0x%.2X\n, reg, val); \
- } while (0)
+MODULE_AUTHOR(Texas Instruments);
+MODULE_DESCRIPTION(TVP514X linux decoder driver);
+MODULE_LICENSE(GPL);
-/**
+/*
* enum tvp514x_std - enum for supported standards
*/
enum tvp514x_std {
@@ -64,15 +65,7 @@ enum tvp514x_std {
STD_INVALID
};
-/**
- * enum tvp514x_state - enum for different decoder states
- */
-enum tvp514x_state {
- STATE_NOT_DETECTED,
- STATE_DETECTED
-};
-
-/**
+/*
* struct tvp514x_std_info - Structure to store standard informations
* @width: Line width in pixels
* @height:Number of active lines
@@ -87,35 +80,29 @@ struct tvp514x_std_info {
};
static struct tvp514x_reg tvp514x_reg_list_default[0x40];
-/**
+/*
* struct tvp514x_decoder - TVP5146/47 decoder object
- * @v4l2_int_device: Slave handle
- * @tvp514x_slave: Slave pointer which is used by @v4l2_int_device
+ * @sd: Subdevice Slave handle
* @tvp514x_regs: copy of hw's regs with preset values.
* @pdata: Board specific
- * @client: I2C client data
- * @id: Entry from I2C table
* @ver: Chip version
- * @state: TVP5146/47 decoder state - detected or not-detected
+ * @streaming: TVP5146/47 decoder streaming - enabled or disabled.
* @pix: Current pixel format
* @num_fmts: Number of formats
* @fmt_list: Format list
* @current_std: Current standard
* @num_stds: Number of standards
* @std_list: Standards list
- * @route: input and output routing at chip level
+ * @input: Input routing at chip level
+ * @output: Output routing at chip level
*/
struct tvp514x_decoder {
- struct v4l2_int_device v4l2_int_device;
- struct v4l2_int_slave tvp514x_slave;
+ struct v4l2_subdev sd;
struct tvp514x_reg tvp514x_regs[ARRAY_SIZE(tvp514x_reg_list_default)];
const struct tvp514x_platform_data *pdata;
- struct i2c_client *client;
-
- struct i2c_device_id *id;
int ver;
- enum tvp514x_state state;
+ int streaming;
struct v4l2_pix_format pix;
int num_fmts;
@@ -124,8 +111,11 @@ struct tvp514x_decoder {
enum tvp514x_std current_std;
int num_stds;
struct tvp514x_std_info *std_list;
-
- struct v4l2_routing route;
+ /*
+* Input and Output Routing parameters
+*/
+ u32 input;
+ u32 output;
};
/* TVP514x default register values */
@@ -191,7 +181,8 @@ static struct tvp514x_reg tvp514x_reg_list_default[] = {
{TOK_TERM, 0, 0},
};
-/* List of image formats supported by TVP5146/47 decoder
+/*
+ * List of image formats supported by TVP5146/47 decoder
* Currently we are using 8 bit mode only, but can be
* extended to 10/20 bit mode.
*/
@@ -240,35 +231,29 @@ static struct tvp514x_std_info tvp514x_std_list[] = {
},
/* Standard: need to add for additional standard */
};
-/*
- * Control structure for Auto Gain
- * This is temporary data, will get replaced once
- * v4l2_ctrl_query_fill supports it.
RE: [DaVinci] patches for linux-media
Hi Hans Mauro, The v3 version of the DaVici VPFE Capture driver and TVP514x driver has been sent to the list for review. I expect this to sail through with out any comments as I have addressed few minor comments from last review. I think Hans will send you the pull request for these patches. Once again, it will be great if this can be merged to 2.6.31. Murali Karicheri m-kariche...@ti.com I have proposed this before, but I'll do it again: I'm more than happy to be the official person who collects and organizes the omap and davinci patches for you and who does the initial reviews. This is effectively already the case since I've been reviewing both omap and davinci patches pretty much from the beginning. Both the omap2/3 display driver and the davinci drivers are now very close to be ready for inclusion in the kernel as my last reviews only found some minor things. Part of the reason for the delays for both omap and davinci was that they had to be modified for v4l2_subdev, which was an absolute necessity, and because they simply needed quite a bit of work to make them suitable for inclusion in the kernel. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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] adding support for setting bus parameters in sub device
From: Muralidharan Karicheri a0868...@gt516km11.gt.design.ti.com
This patch adds support for setting bus parameters such as bus type
(Raw Bayer or Raw YUV image data bus), bus width (example 10 bit raw
image data bus, 10 bit BT.656 etc.), and polarities (vsync, hsync, field
etc) in sub device. This allows bridge driver to configure the sub device
bus for a specific set of bus parameters through s_bus() function call.
This also can be used to define platform specific bus parameters for
host and sub-devices.
Reviewed by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Murali Karicheri m-kariche...@ti.com
---
Applies to v4l-dvb repository
include/media/v4l2-subdev.h | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 1785608..8532b91 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -37,6 +37,43 @@ struct v4l2_decode_vbi_line {
u32 type; /* VBI service type (V4L2_SLICED_*). 0 if no
service found */
};
+/*
+ * Some sub-devices are connected to the host/bridge device through a bus that
+ * carries the clock, vsync, hsync and data. Some interfaces such as BT.656
+ * carries the sync embedded in the data where as others have separate line
+ * carrying the sync signals. The structure below is used to define bus
+ * configuration parameters for host as well as sub-device
+ */
+enum v4l2_bus_type {
+ /* Raw YUV image data bus */
+ V4L2_BUS_RAW_YUV,
+ /* Raw Bayer image data bus */
+ V4L2_BUS_RAW_BAYER
+};
+
+struct v4l2_bus_settings {
+ /* yuv or bayer image data bus */
+ enum v4l2_bus_type type;
+ /* subdev bus width */
+ u8 subdev_width;
+ /* host bus width */
+ u8 host_width;
+ /* embedded sync, set this when sync is embedded in the data stream */
+ unsigned embedded_sync:1;
+ /* master or slave */
+ unsigned host_is_master:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_vsync:1;
+ /* 0 - active low, 1 - active high */
+ unsigned pol_hsync:1;
+ /* 0 - low to high , 1 - high to low */
+ unsigned pol_field:1;
+ /* 0 - active low , 1 - active high */
+ unsigned pol_data:1;
+ /* 0 - sample at falling edge , 1 - sample at rising edge */
+ unsigned edge_pclock:1;
+};
+
/* Sub-devices are devices that are connected somehow to the main bridge
device. These devices are usually audio/video muxers/encoders/decoders or
sensors and webcam controllers.
@@ -199,6 +236,8 @@ struct v4l2_subdev_audio_ops {
s_routing: see s_routing in audio_ops, except this version is for video
devices.
+
+ s_bus: set bus parameters in sub device to configure the bus
*/
struct v4l2_subdev_video_ops {
int (*s_routing)(struct v4l2_subdev *sd, u32 input, u32 output, u32
config);
@@ -219,6 +258,7 @@ struct v4l2_subdev_video_ops {
int (*s_parm)(struct v4l2_subdev *sd, struct v4l2_streamparm *param);
int (*enum_framesizes)(struct v4l2_subdev *sd, struct v4l2_frmsizeenum
*fsize);
int (*enum_frameintervals)(struct v4l2_subdev *sd, struct
v4l2_frmivalenum *fival);
+ int (*s_bus)(struct v4l2_subdev *sd, const struct v4l2_bus_settings
*bus);
};
struct v4l2_subdev_ops {
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/11 - v3] vpfe capture bridge driver for DM355 and DM6446
Hello,
very small comments, see below please
On Thu, Jun 18, 2009 at 12:11 AM, m-kariche...@ti.com wrote:
From: Muralidharan Karicheri m-kariche...@ti.com
snip
+static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
+{
+ struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
+ int ret = -ENOENT;
+
+ vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
+ if (NULL == vpfe_cfg-vpssclk) {
+ v4l2_err(vpfe_dev-pdev-driver, No clock defined for
+ vpss_master\n);
+ return ret;
+ }
+
+ if (clk_enable(vpfe_cfg-vpssclk)) {
+ v4l2_err(vpfe_dev-pdev-driver,
+ vpfe vpss master clock not enabled);
+ goto out;
+ }
+ v4l2_info(vpfe_dev-pdev-driver,
+ vpfe vpss master clock enabled\n);
+
+ vpfe_cfg-slaveclk = clk_get(vpfe_dev-pdev, vpss_slave);
+ if (NULL == vpfe_cfg-slaveclk) {
+ v4l2_err(vpfe_dev-pdev-driver,
+ No clock defined for vpss slave\n);
+ goto out;
+ }
+
+ if (clk_enable(vpfe_cfg-slaveclk)) {
+ v4l2_err(vpfe_dev-pdev-driver,
+ vpfe vpss slave clock not enabled);
+ goto out;
+ }
+ v4l2_info(vpfe_dev-pdev-driver,
+ vpfe vpss slave clock enabled\n);
+ return 0;
+out:
+ if (vpfe_cfg-vpssclk)
+ clk_put(vpfe_cfg-vpssclk);
+ if (vpfe_cfg-slaveclk)
+ clk_put(vpfe_cfg-slaveclk);
+
+ return -1;
+}
+
+/*
+ * vpfe_probe : This function creates device entries by register
+ * itself to the V4L2 driver and initializes fields of each
+ * device objects
+ */
+static __init int vpfe_probe(struct platform_device *pdev)
+{
+ struct vpfe_config *vpfe_cfg;
+ struct resource *res1;
+ struct vpfe_device *vpfe_dev;
+ struct i2c_adapter *i2c_adap;
+ struct i2c_client *client;
+ struct video_device *vfd;
+ int ret = -ENOMEM, i, j;
+ int num_subdevs = 0;
+
+ /* Get the pointer to the device object */
+ vpfe_dev = vpfe_initialize();
+
+ if (!vpfe_dev) {
+ v4l2_err(pdev-dev.driver,
+ Failed to allocate memory for vpfe_dev\n);
+ return ret;
+ }
+
+ vpfe_dev-pdev = pdev-dev;
+
+ if (NULL == pdev-dev.platform_data) {
+ v4l2_err(pdev-dev.driver, Unable to get vpfe config\n);
+ ret = -ENOENT;
+ goto probe_free_dev_mem;
+ }
+
+ vpfe_cfg = pdev-dev.platform_data;
+ vpfe_dev-cfg = vpfe_cfg;
+ if (NULL == vpfe_cfg-ccdc ||
+ NULL == vpfe_cfg-card_name ||
+ NULL == vpfe_cfg-sub_devs) {
+ v4l2_err(pdev-dev.driver, null ptr in vpfe_cfg\n);
+ ret = -ENOENT;
+ goto probe_free_dev_mem;
+ }
+
+ /* enable vpss clocks */
+ ret = vpfe_enable_clock(vpfe_dev);
+ if (ret)
+ goto probe_free_dev_mem;
+
+ mutex_lock(ccdc_lock);
+ /* Allocate memory for ccdc configuration */
+ ccdc_cfg = kmalloc(sizeof(struct ccdc_config), GFP_KERNEL);
+ if (NULL == ccdc_cfg) {
+ v4l2_err(pdev-dev.driver, Memory allocation failed for
+ ccdc_cfg);
+ goto probe_disable_clock;
+ }
+
+ strncpy(ccdc_cfg-name, vpfe_cfg-ccdc, 32);
+ /* Get VINT0 irq resource */
+ res1 = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (!res1) {
+ v4l2_err(pdev-dev.driver, Unable to get interrupt for
VINT0);
Do you want to add \n to the end of this message? If i'm now wrong
it's better to check other messages in this patch for \n. Please,
check.
+ ret = -ENOENT;
+ goto probe_disable_clock;
+ }
+ vpfe_dev-ccdc_irq0 = res1-start;
+
+ /* Get VINT1 irq resource */
+ res1 = platform_get_resource(pdev,
+ IORESOURCE_IRQ, 1);
+ if (!res1) {
+ v4l2_err(pdev-dev.driver, Unable to get interrupt for
VINT1);
\n ?
+ ret = -ENOENT;
+ goto probe_disable_clock;
+ }
+ vpfe_dev-ccdc_irq1 = res1-start;
+
+ /* Get address base of CCDC */
+ res1 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res1) {
+ v4l2_err(pdev-dev.driver,
+ Unable to get register address map\n);
+ ret = -ENOENT;
+ goto probe_disable_clock;
+ }
+
+ ccdc_cfg-ccdc_addr_size = res1-end - res1-start + 1;
+ if (!request_mem_region(res1-start, ccdc_cfg-ccdc_addr_size,
+ pdev-dev.driver-name)) {
+ v4l2_err(pdev-dev.driver,
+ Failed
Re: [PATCH 3/11 - v3] dm355 ccdc module for vpfe capture driver
Hello,
one more small comment
On Thu, Jun 18, 2009 at 12:11 AM, m-kariche...@ti.com wrote:
From: Muralidharan Karicheri m-kariche...@ti.com
DM355 CCDC hw module
Adds ccdc hw module for DM355 CCDC. This registers with the bridge
driver a set of hw_ops for configuring the CCDC for a specific
decoder device connected to vpfe.
The module description and owner information added
snip
+static int dm355_ccdc_init(void)
+{
+ printk(KERN_NOTICE dm355_ccdc_init\n);
+ if (vpfe_register_ccdc_device(ccdc_hw_dev) 0)
+ return -1;
Don't you want to rewrite this to return good error code?
int ret;
printk();
ret = vpfe_register_ccdc_device();
if (ret 0)
return ret;
I know you have tight/fast track/hard schedule, so you can do this
improvement later, after merging this patch.
+ printk(KERN_NOTICE %s is registered with vpfe.\n,
+ ccdc_hw_dev.name);
+ return 0;
+}
+
+static void dm355_ccdc_exit(void)
+{
+ vpfe_unregister_ccdc_device(ccdc_hw_dev);
+}
--
Best regards, Klimov Alexey
--
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
PULL request - http://linuxtv.org/hg/~hgoede/gspca
Hi Mauro, Can you please pull from: http://linuxtv.org/hg/~hgoede/gspca I know you haven't even had the chance to do my previous pull request :) New this time: * mark the ov511 driver as deprecated, note: we should really also keep track of this in Documentation/feature-removal-schedule.txt, but that is not part of the v4l-dvb tree. * Support for the st6422 bridge + sensor ! Give it a try, I know now you have a cam which uses this bridge :) When you try it be sure to use the latest (just updated my libv4l tree) libv4l, this enables (software) automatic control of the gain and exposure, for a decent image in most lighting conditions. BTW, the latest libv4l also does this (auto expo / gain) for the spca561 based logitech cam I borrowed to you at plumbers last year, works really nice :) Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/11 - v3] dm644x ccdc module for vpfe capture driver
On Thu, Jun 18, 2009 at 12:11 AM, m-kariche...@ti.com wrote:
From: Muralidharan Karicheri m-kariche...@ti.com
DM644x CCDC hw module
This is the hw module for DM644x CCDC. This registers with the
vpfe capture driver and provides a set of hw_ops to configure
CCDC for a specific decoder device connected to the VPFE
Module description, GPL and owner information MACROs added at the top
snip
+static int dm644x_ccdc_init(void)
+{
+ printk(KERN_NOTICE dm644x_ccdc_init\n);
+ if (vpfe_register_ccdc_device(ccdc_hw_dev) 0)
+ return -1;
The same small idea like in [PATCH 3/11 - v3] dm355 ccdc module for
vpfe capture driver about this function. What do you think about
introducing ret variable and returning good error code?
+ printk(KERN_NOTICE %s is registered with vpfe.\n,
+ ccdc_hw_dev.name);
+ return 0;
+}
+
+static void dm644x_ccdc_exit(void)
+{
+ vpfe_unregister_ccdc_device(ccdc_hw_dev);
+}
--
Best regards, Klimov Alexey
--
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
OMAP34XXCAM: Micron mt9d111 sensor support?
I am working on adding support for a micron 2 MP sensor: mt9d111 on a gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like to use the omap34xxcam driver to interface with this sensor. I am wondering if there are currently any distributions which already include support for this sensor through the omap34xxcam driver, or if anyone else is interested in this topic. Cheers, Zach LeRoy -- 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: OMAP34XXCAM: Micron mt9d111 sensor support?
-Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Zach LeRoy Sent: Wednesday, June 17, 2009 5:06 PM To: linux-omap; linux-media@vger.kernel.org Subject: OMAP34XXCAM: Micron mt9d111 sensor support? I am working on adding support for a micron 2 MP sensor: mt9d111 on a gumsitx overo. This is a i2c-controlled sensor. Ideally, I would like to use the omap34xxcam driver to interface with this sensor. I am wondering if there are currently any distributions which already include support for this sensor through the omap34xxcam driver, or if anyone else is interested in this topic. Hi Zach, I'm working along with Sakari Ailus and others in this omap34xxcam driver you're talking about, and we are in the process to provide a newer patchset to work on the latest l-o tree. Sakari is sharing the camera core here: http://gitorious.org/omap3camera And I have also this repository which contains a snapshot of Sakari's tree + support from some sensors I have available for the 3430SDP and LDP (the name could confuse with the above, but I'll change the name/location soon): http://gitorious.org/omap3-linux-camera-driver Testing the driver with as much sensors as we can is very interesting (at least for me), because that help us spot possible bugs that aren't seen with our current HW. So, I'll be looking forward if you add this sensor driver to the supported list :) Regards, Sergio Cheers, Zach LeRoy -- 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 -- 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: typo: v4l2_bound_align_image name mismatch.
Em Wed, 17 Jun 2009 09:17:21 -0700 (PDT) Trent Piepho xy...@speakeasy.org escreveu: On Wed, 17 Jun 2009, Mauro Carvalho Chehab wrote: It seems that there's a typo error at pxa-camera. One more fix for the align stuff. Sorry about that. I did the pxa patch first, then changed the name of function before finding other drivers to patch and didn't go back and fix the pxa patch. 01/02: v4l2: Fix flaw in alignment code http://linuxtv.org/hg/~tap/fix?cmd=changeset;node=4ef7fb102b6c 02/02: pxa-camera: fix typo http://linuxtv.org/hg/~tap/fix?cmd=changeset;node=1ca713eae3b4 Applied, thanks. I'll fold both patches on your original ones at -git. It is important to fold the second one to avoid bisect breakages. Forwarded message: Date: Wed, 17 Jun 2009 13:47:57 + From: Jonathan Cameron ji...@cam.ac.uk To: Linux Media Mailing List linux-media@vger.kernel.org, Mauro Carvalho Chehab mche...@infradead.org Subject: typo: v4l2_bound_align_image name mismatch. Just came across a build error with pxa_camera with Mauro's linux-next tree. pxa-camera calls v4l2_bound_align_image whereas the function is called v4l_bound_align_image. Cheers, --- Jonathan Cameron Cheers, Mauro 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] New utility program atsc_epg added to dvb-apps utility suite.
Am Mittwoch, den 17.06.2009, 18:18 -0500 schrieb Yufei Yuan: Hi, I am not sure if this is the correct mailing list to send this patch. From the LinuxTV website, it seems that currently dvb-apps project has no owner. A new utility atsc_epg is added into the dvb-apps utility suite. It parses PSIP information carried in OTA ATSC channels, and constructs a basic EPG in a terminal window. Changes were also made to files to please GCC4.4. The patch is against latest revision 1278 from the dvb-apps repository. Regards, Yufei Yuan -- 好学近乎智，力行近乎仁，知耻近乎勇。 Eagerness in learning is close to intelligence. Commitment in doing is close to nobleness. Realization of shamefulness is close to courageousness. Getting engaged into footers ... The above blindly assumes that there is a balance within that reduction to three cases ... (we know two are enough) You miss at least several hundred years of history on the other side of the planet. I totally disagree with that kind of stuff. Most explicitly with the third variant. That way you can still press any slave into any army ... -- 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] New utility program atsc_epg added to dvb-apps utility suite.
Hi, Am Mittwoch, den 17.06.2009, 19:20 -0500 schrieb Yufei Yuan: If you take such an intolerant attitude against what others opinion might be, your words might just be deemed worthless, or should I say *bullshit*, by others. It is really sad that this world is never in shortage of people like you. What a shame of humanity. Regards, yes, feel free to speak up. I do the same and do hate medieval age footers ;) Why that stuff is not filtered here ??? Cheers, Hermann On Wed, Jun 17, 2009 at 7:14 PM, hermann pittonhermann-pit...@arcor.de wrote: Hi, Am Mittwoch, den 17.06.2009, 19:06 -0500 schrieb Yufei Yuan: Sorry I guess this is about the way the patch was generated? Or about the utility itself? Regards, most likely. And that is what I exactly do mean. Obviously you don't have any control about the footers others provide for you, if you go shopping ;) -- 好学近乎智，力行近乎仁，知耻近乎勇。 Eagerness in learning is close to intelligence. Commitment in doing is close to nobleness. Realization of shamefulness is close to courageousness. :) what a bullshit. Cheers, Hermann On Wed, Jun 17, 2009 at 6:51 PM, hermann pittonhermann-pit...@arcor.de wrote: Am Mittwoch, den 17.06.2009, 18:18 -0500 schrieb Yufei Yuan: Hi, I am not sure if this is the correct mailing list to send this patch. From the LinuxTV website, it seems that currently dvb-apps project has no owner. A new utility atsc_epg is added into the dvb-apps utility suite. It parses PSIP information carried in OTA ATSC channels, and constructs a basic EPG in a terminal window. Changes were also made to files to please GCC4.4. The patch is against latest revision 1278 from the dvb-apps repository. Regards, Yufei Yuan -- 好学近乎智，力行近乎仁，知耻近乎勇。 Eagerness in learning is close to intelligence. Commitment in doing is close to nobleness. Realization of shamefulness is close to courageousness. Getting engaged into footers ... The above blindly assumes that there is a balance within that reduction to three cases ... (we know two are enough) You miss at least several hundred years of history on the other side of the planet. I totally disagree with that kind of stuff. Most explicitly with the third variant. That way you can still press any slave into any army ... -- 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] New utility program atsc_epg added to dvb-apps utility suite.
Am Mittwoch, den 17.06.2009, 19:46 -0500 schrieb Yufei Yuan: Age would cure neither naivety nor stupidity. I would imagine only a self-important white supremacist would utter such comments in public against a total stranger. If you can read the Chinese above, I *seriously* doubt that, it's what Confucious said around 500BC, to encourage learning and repentance. That was of course totally clear and exactly that is the annoyance ! I may not do a good job in translation, sorry about that. But blindly interpret other's intention based on one's own narrow personal experience, or cultural context, is the origin of the trouble between groups and nations, in this case, two individuals. OK, let's keep the footers uncensored ;) Regards, On Wed, Jun 17, 2009 at 7:30 PM, hermann pittonhermann-pit...@arcor.de wrote: Am Mittwoch, den 17.06.2009, 19:20 -0500 schrieb Yufei Yuan: If you take such an intolerant attitude against what others opinion might be, your words might just be deemed worthless, or should I say *bullshit*, by others. It is really sad that this world is never in shortage of people like you. What a shame of humanity. Regards, I'm a German born in 1957. If that could help you any further in the future not to claim to have the three golden rules ... Cheers, Hermann On Wed, Jun 17, 2009 at 7:14 PM, hermann pittonhermann-pit...@arcor.de wrote: Hi, Am Mittwoch, den 17.06.2009, 19:06 -0500 schrieb Yufei Yuan: Sorry I guess this is about the way the patch was generated? Or about the utility itself? Regards, most likely. And that is what I exactly do mean. Obviously you don't have any control about the footers others provide for you, if you go shopping ;) -- 好学近乎智，力行近乎仁，知耻近乎勇。 Eagerness in learning is close to intelligence. Commitment in doing is close to nobleness. Realization of shamefulness is close to courageousness. :) what a bullshit. Cheers, Hermann On Wed, Jun 17, 2009 at 6:51 PM, hermann pittonhermann-pit...@arcor.de wrote: Am Mittwoch, den 17.06.2009, 18:18 -0500 schrieb Yufei Yuan: Hi, I am not sure if this is the correct mailing list to send this patch. From the LinuxTV website, it seems that currently dvb-apps project has no owner. A new utility atsc_epg is added into the dvb-apps utility suite. It parses PSIP information carried in OTA ATSC channels, and constructs a basic EPG in a terminal window. Changes were also made to files to please GCC4.4. The patch is against latest revision 1278 from the dvb-apps repository. Regards, Yufei Yuan -- 好学近乎智，力行近乎仁，知耻近乎勇。 Eagerness in learning is close to intelligence. Commitment in doing is close to nobleness. Realization of shamefulness is close to courageousness. Getting engaged into footers ... The above blindly assumes that there is a balance within that reduction to three cases ... (we know two are enough) You miss at least several hundred years of history on the other side of the planet. I totally disagree with that kind of stuff. Most explicitly with the third variant. That way you can still press any slave into any army ... -- 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] New utility program atsc_epg added to dvb-apps utility suite.
Am Mittwoch, den 17.06.2009, 20:12 -0500 schrieb Yufei Yuan: Okay, you win. Apology to others in the list who have to endure the garbage talk. Regards, Yufei Yuan Sorry for abusing you for a ride out on mail footers. Best, Hermann On Wed, Jun 17, 2009 at 8:05 PM, hermann pittonhermann-pit...@arcor.de wrote: Am Mittwoch, den 17.06.2009, 19:46 -0500 schrieb Yufei Yuan: Age would cure neither naivety nor stupidity. I would imagine only a self-important white supremacist would utter such comments in public against a total stranger. If you can read the Chinese above, I *seriously* doubt that, it's what Confucious said around 500BC, to encourage learning and repentance. That was of course totally clear and exactly that is the annoyance ! I may not do a good job in translation, sorry about that. But blindly interpret other's intention based on one's own narrow personal experience, or cultural context, is the origin of the trouble between groups and nations, in this case, two individuals. OK, let's keep the footers uncensored ;) Regards, On Wed, Jun 17, 2009 at 7:30 PM, hermann pittonhermann-pit...@arcor.de wrote: Am Mittwoch, den 17.06.2009, 19:20 -0500 schrieb Yufei Yuan: If you take such an intolerant attitude against what others opinion might be, your words might just be deemed worthless, or should I say *bullshit*, by others. It is really sad that this world is never in shortage of people like you. What a shame of humanity. Regards, I'm a German born in 1957. If that could help you any further in the future not to claim to have the three golden rules ... Cheers, Hermann On Wed, Jun 17, 2009 at 7:14 PM, hermann pittonhermann-pit...@arcor.de wrote: Hi, Am Mittwoch, den 17.06.2009, 19:06 -0500 schrieb Yufei Yuan: Sorry I guess this is about the way the patch was generated? Or about the utility itself? Regards, most likely. And that is what I exactly do mean. Obviously you don't have any control about the footers others provide for you, if you go shopping ;) -- 好学近乎智，力行近乎仁，知耻近乎勇。 Eagerness in learning is close to intelligence. Commitment in doing is close to nobleness. Realization of shamefulness is close to courageousness. :) what a bullshit. Cheers, Hermann On Wed, Jun 17, 2009 at 6:51 PM, hermann pittonhermann-pit...@arcor.de wrote: Am Mittwoch, den 17.06.2009, 18:18 -0500 schrieb Yufei Yuan: Hi, I am not sure if this is the correct mailing list to send this patch. From the LinuxTV website, it seems that currently dvb-apps project has no owner. A new utility atsc_epg is added into the dvb-apps utility suite. It parses PSIP information carried in OTA ATSC channels, and constructs a basic EPG in a terminal window. Changes were also made to files to please GCC4.4. The patch is against latest revision 1278 from the dvb-apps repository. Regards, Yufei Yuan -- 好学近乎智，力行近乎仁，知耻近乎勇。 Eagerness in learning is close to intelligence. Commitment in doing is close to nobleness. Realization of shamefulness is close to courageousness. Getting engaged into footers ... The above blindly assumes that there is a balance within that reduction to three cases ... (we know two are enough) You miss at least several hundred years of history on the other side of the planet. I totally disagree with that kind of stuff. Most explicitly with the third variant. That way you can still press any slave into any army ... -- 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
