Re: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
VDR User wrote: On Thu, Mar 12, 2009 at 6:53 PM, Ang Way Chuang wrote: Hi all, I've looked through the mailing list and there seems to be no standard way to interpret to content of SNR, signal strength and BER returned from the DVB API. So, I wonder if someone knows how to interpret these values at least for HVR 4000 Lite? Thanks. I've seen talk about converting everything to report SNR/STR in dB which is a great idea if it ever happens. I know a lot of guys not on the mailing list who've been waiting for that. Yes, please :) -- 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: [stable] Fwd: [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
On Thu, Mar 12, 2009 at 11:00:11PM -0400, Jarod Wilson wrote: > Greg KH wrote: >> On Thu, Mar 12, 2009 at 04:24:38PM -0400, Michael Krufky wrote: >>> Can we have this merged into -stable? Jarod Wilson sent this last >>> month, but he left off the cc to sta...@kernel.org >> What is the git commit id of the patch in Linus's tree that matches up >> with this? >> thanks, >> greg k-h > > > Now that I look closer, seems there's an even more complete patch already > in linus' tree, commit id: > > cd8f894eacf13996d920fdd2aef1afc55156b191 > > Shoulda just forwarded that along, but I was under the impression that area > of code had changed significantly in 2.6.28 and the patch was no longer > applicable. Maybe that was the v4l/dvb hg tree though... So I'd just grab > that, and add: > > Signed-off-by: Jarod Wilson Ok, will do that. thanks, greg k-h -- 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: [linuxtv-commits] [hg:v4l-dvb] Add cx231xx USB driver
Hans, I've summarized your comments into a few answers, to avoid repeating myself. On Fri, 13 Mar 2009 01:53:42 +0100 Hans Verkuil wrote: > Hi Mauro, > > Just one last reply, and than we can close this discussion. Luckily the > conversion of this driver to v4l2_device/subdev is a lot simpler than I > feared initially. So no harm done in that respect. Good! > Please announce this in the future. I checked the linux-media list and there > is no mention of this whatsoever. Just putting it up in a tree is not > sufficient, you have to tell people about it as well. I always request the developers to submit their work at the public ML. Unfortunately, a few don't do it due to some random reasons. It is much better for the Linux users if I merge such drivers or patches than to just nack a driver due to that reason. Anyway, after the merge, the community can still review the driver and/or the patches, as announced by the hg mailbomb script. > It's not v4l2_device/v4l2_subdev that's at stake here. It's the removal of > the old i2c autoprobing behavior. v4l2_device/v4l2_subdev is just the > fastest way to do this for v4l drivers. As you can see here: > > http://i2c.wiki.kernel.org/index.php/Legacy_drivers_to_be_converted > > the conversion is almost done. This weekend I hope to finish cx88, cx23885 > and bttv. Hopefully Douglas Landgraf can convert em28xx and I know Mike > Isely only needs to do some final tweaks for pvrusb2. Good to know. We still need testing from the users for those drivers, since there are risks of regressions when converting from the automatic probe method, to a manual binding one. If a i2c bind for a needed driver is forgot (or bad coded), some board variants will break. Since nobody ever cared to document all those I2C driver alternatives, I suspect that we'll have some regressions, that will likely be identified only when the kernel reaches the distros. > I do not expect newly submitted drivers to use v4l2_device/subdev. I know it > is a very recent development. But it is very easy to implement and all I > need is a chance to review and help them with that to ensure that dropping > the old i2c API isn't blocked by a new driver. Not in the least because it > is likely that the i2c core maintainer will block such a new driver if it > is the only driver preventing the removal of the old i2c API. > > In addition, once a driver is in the v4l-dvb tree I cannot just drop the old > i2c API support in v4l-dvb since that will just break any driver that uses > it. So whether it goes to the git tree or not, that doesn't matter for me. This will just mean that those drivers won't compile against 2.6.30 during 2.6.30-rc cycle. You can always disable it via make menuconfig if needed, until it would be converted to the new i2c methods. Since just the core developers compile kernels against the latest -rc cycle, This is for sure a much minor problem that can be easily solved by a .config file, than letting a driver to grow out of the tree. -- 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: [stable] Fwd: [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
Greg KH wrote: On Thu, Mar 12, 2009 at 04:24:38PM -0400, Michael Krufky wrote: Can we have this merged into -stable? Jarod Wilson sent this last month, but he left off the cc to sta...@kernel.org What is the git commit id of the patch in Linus's tree that matches up with this? thanks, greg k-h Now that I look closer, seems there's an even more complete patch already in linus' tree, commit id: cd8f894eacf13996d920fdd2aef1afc55156b191 Shoulda just forwarded that along, but I was under the impression that area of code had changed significantly in 2.6.28 and the patch was no longer applicable. Maybe that was the v4l/dvb hg tree though... So I'd just grab that, and add: Signed-off-by: Jarod Wilson --jarod -- 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
kernel oops in dvb_net
Hi linux-tver, Not sure whether this is the right mailing list or not. I've encountered a kernel oops in dvb_net. My receiver card is HVR-4000 Lite. I'm running a rawhide kernel on Fedora 10. Attached is the syslog just before when nuts. I tested with rawhide kernel version 2.6.29-0.124.rc5.fc10.i586 and vanilla kernel 2.6.28.7. I'm using the receiver card for ULE decapsulation. Should you need more information, please drop me a mail. Attached are the kernel oops message of the 2 kernels just before the system freeze. Thanks. Regards, Ang Way Chuang Mar 9 16:18:44 localhost kernel: dvb0_0: no ts feed to stop Mar 9 16:18:44 localhost kernel: dvb_net: removed network interface dvb0_0 Mar 9 16:18:44 localhost kernel: 1802201963: Expected 1802201963 more SNDU bytes, but got PUSI (pf 0, ts_remain 183). Flushing incomplete payload. Mar 9 16:18:44 localhost kernel: BUG: unable to handle kernel paging request at 6b6b6c1f Mar 9 16:18:44 localhost kernel: IP: [] kfree_skb+0x9/0x32 Mar 9 16:18:44 localhost kernel: *pde = Mar 9 16:18:44 localhost kernel: Oops: [#1] SMP Mar 9 16:18:44 localhost kernel: last sysfs file: /sys/devices/virtual/net/dvb0_0/flags Mar 9 16:18:44 localhost kernel: Modules linked in: sco bridge stp llc bnep l2cap bluetooth ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath uinput isl6421 cx24116 snd_hda_codec_realtek cx88_dvb cx88_vp3054_i2c snd_hda_intel videobuf_dvb dvb_core tuner cx8802 cx8800 cx88_alsa snd_hda_codec snd_hwdep cx88xx snd_seq_dummy snd_seq_oss ir_common tveeprom snd_seq_midi_event v4l2_common snd_seq videodev snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm v4l1_compat videobuf_dma_sg videobuf_core iTCO_wdt btcx_risc iTCO_vendor_support ppdev floppy pcspkr snd_timer snd i2c_i801 r8169 soundcore parport_pc via_velocity parport snd_page_alloc mii crc_ccitt ata_generic pata_acpi i915 drm i2c_algo_bit i2c_core [last unloaded: microcode] Mar 9 16:18:44 localhost kernel: Mar 9 16:18:44 localhost kernel: Pid: 4024, comm: cx88[0] dvb Tainted: G W (2.6.29-0.124.rc5.fc10.i586 #1) Prime Series Mar 9 16:18:44 localhost kernel: EIP: 0060:[] EFLAGS: 00010002 CPU: 1 Mar 9 16:18:44 localhost kernel: EIP is at kfree_skb+0x9/0x32 Mar 9 16:18:44 localhost kernel: EAX: 6b6b6b6b EBX: fa4ca301 ECX: 6b6b6b6b EDX: 01a2c000 Mar 9 16:18:44 localhost kernel: ESI: f4d415e0 EDI: f4d41060 EBP: f4e09ec4 ESP: f4e09ec4 Mar 9 16:18:44 localhost kernel: DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Mar 9 16:18:44 localhost kernel: Process cx88[0] dvb (pid: 4024, ti=f4e09000 task=f4f029e0 task.ti=f4e09000) Mar 9 16:18:44 localhost kernel: Stack: Mar 9 16:18:44 localhost kernel: f4e09f40 f81939fd f81973d1 6b6b6b6b 6b6b6b6b 00b7 f4c0d3c0 Mar 9 16:18:44 localhost kernel: f4d415e0 fa4ca318 f4d41060 b7a5b100 fa4ca31d fa4ca3d4 f4d411c4 f4d4162c Mar 9 16:18:44 localhost kernel: b4b6ba84 0be6 f4e09f20 f4d022a4 f4d022a4 f4d02294 0293 Mar 9 16:18:44 localhost kernel: Call Trace: Mar 9 16:18:44 localhost kernel: [] ? dvb_net_ts_callback+0x340/0xa57 [dvb_core] Mar 9 16:18:44 localhost kernel: [] ? dvb_dmx_swfilter_packet+0x122/0x300 [dvb_core] Mar 9 16:18:44 localhost kernel: [] ? _spin_lock_irqsave+0x63/0x6d Mar 9 16:18:44 localhost kernel: [] ? dvb_dmx_swfilter+0xce/0x10d [dvb_core] Mar 9 16:18:44 localhost kernel: [] ? videobuf_dvb_thread+0xad/0x12f [videobuf_dvb] Mar 9 16:18:44 localhost kernel: [] ? videobuf_dvb_thread+0x0/0x12f [videobuf_dvb] Mar 9 16:18:44 localhost kernel: [] ? kthread+0x3b/0x61 Mar 9 16:18:44 localhost kernel: [] ? kthread+0x0/0x61 Mar 9 16:18:44 localhost kernel: [] ? kernel_thread_helper+0x7/0x10 Mar 9 16:18:44 localhost kernel: Code: 00 00 88 4b 65 f0 ff 0a 0f 94 c0 84 c0 74 10 8d 93 48 ff ff ff a1 34 37 8b c0 e8 1f 44 e4 ff 5b 5d c3 55 85 c0 89 e5 89 c1 74 27 <8b> 80 b4 00 00 00 48 75 07 0f ae e8 89 f6 eb 10 8d 81 b4 00 00 Mar 9 16:18:44 localhost kernel: EIP: [] kfree_skb+0x9/0x32 SS:ESP 0068:f4e09ec4 Mar 9 16:18:44 localhost kernel: ---[ end trace 265db78d6888b949 ]--- Mar 9 16:18:44 localhost kernel: = Mar 9 16:18:44 localhost kernel: BUG kmalloc-2048 (Tainted: G D W ): Poison overwritten Mar 9 16:18:44 localhost kernel: - Mar 9 16:18:44 localhost kernel: Mar 9 16:18:44 localhost kernel: INFO: 0xf4d410c0-0xf4d416bc. First byte 0x6c instead of 0x6b Mar 9 16:18:44 localhost kernel: INFO: Allocated in alloc_netdev_mq+0x3d/0x11c age=1499438 cpu=1 pid=3815 Mar 9 16:18:44 localhost kernel: INFO: Freed in netdev_release+0x2f/0x32 age=126 cpu=1 pid=4277 Mar 9 16:18:44 localhost kernel: INFO: Slab 0xc1f66b00 objects=15 used=0 fp=0xf4d4 flags=0x40002082 Mar 9 16:18:44 localhost kernel: INFO: Object 0xf4d41060 @offset=4192 fp=0xf4d451e0 Mar 9
Re: [stable] Fwd: [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
On Thu, Mar 12, 2009 at 04:24:38PM -0400, Michael Krufky wrote: > Can we have this merged into -stable? Jarod Wilson sent this last > month, but he left off the cc to sta...@kernel.org What is the git commit id of the patch in Linus's tree that matches up with this? thanks, greg k-h -- 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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
On Thu, Mar 12, 2009 at 6:53 PM, Ang Way Chuang wrote: > Hi all, > I've looked through the mailing list and there seems to be no > standard > way to interpret to content of SNR, signal strength and BER returned > from the DVB API. So, I wonder if someone knows how to interpret these > values at least for HVR 4000 Lite? Thanks. I've seen talk about converting everything to report SNR/STR in dB which is a great idea if it ever happens. I know a lot of guys not on the mailing list who've been waiting for that. -- 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
The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
Hi all, I've looked through the mailing list and there seems to be no standard way to interpret to content of SNR, signal strength and BER returned from the DVB API. So, I wonder if someone knows how to interpret these values at least for HVR 4000 Lite? Thanks. Regards, Ang Way Chuang -- 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://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Thu, 12 Mar 2009 11:26:15 -0400 Devin Heitmueller wrote: > On Thu, Mar 12, 2009 at 11:06 AM, Mauro Carvalho Chehab > wrote: > >> Yeah, printing "NULL" is bad and I can obviously fix that. The real > >> reason for the addition of the "UNDEFINED" entry is I use that to > >> detect if there are *any* analog inputs defined, which dictates > >> whether the analog subsystem is initialized. Because the .input > >> section is a member of the au0828_dev struct, and not a pointer, I > >> needed some way to tell if it was populated with anything. > > > > if you attribute it to -1, the userspace calls will never set it to > > undefined. > > You should take some care to avoid reading outside some array though. > > The problem is that I check for UNDEFINED so that the .input section > of the au0828 board definition can be left uninitialized. Otherwise, > I would have to add something like "num_inputs" to the board > definition and worry about the value matching the actual number of > inputs defined. num_inputs is a really bad thing. Maybe you can just test if input type is UNDEFINED and return -EINVAL. > >> I looked at the list and all of these issues are easy to fix, and I > >> will do that tonight. > > > > Ok. > > > >> Please let me know if you have any other concerns (and what you want > >> me to do regarding the VBI stuff), since I would like to avoid having > >> do redo the tree again. > > > > No, just the above. Please, instead of redo the tree, just add some patches > > fixing those issues. This allows me to review faster your series. > > Do you mean the checkpatch fixes should be done as a separate patch > too? I assumed you wanted me to fix the original patch to pass make > checkpatch. Is there a way to do the equivalent of "make checkpatch" > against particular hg revisions or source files? I'm just trying to > understand the best way to ensure that all of the issues actually get > fixed. There are two ways: 1) v4l/check.pl This accepts just one file each time; 2) hg diff -r file v4l/check.pl file The check.pl script is just a wrapper for the checkpatch.pl. Its output is equal to an standard C compiler. So, you can use it on a C error parser for some gui. Also, the wrapper removes some checks that are ok (the ones for the lines that adds kernel version checks - since this will be removed anyway by the submit script). 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: [linuxtv-commits] [hg:v4l-dvb] Add cx231xx USB driver
Hi Mauro, Just one last reply, and than we can close this discussion. Luckily the conversion of this driver to v4l2_device/subdev is a lot simpler than I feared initially. So no harm done in that respect. On Thursday 12 March 2009 14:20:11 Mauro Carvalho Chehab wrote: > On Thu, 12 Mar 2009 12:14:22 +0100 (CET) > > "Hans Verkuil" wrote: > > Mauro, you did not answer the question why this driver was just merged > > without going through a public review? If I'd seen it beforehand I'd > > have worked together with Sri to get it fixed first. I don't expect him > > to know about this, but I didn't even get a chance to discuss it and > > help with it. Everyone else has to go through the normal review > > channels, but apparently this was just fast-tracked and merged. That's > > not the way to do it. > > It were added one week ago on a temporary public tree, at linuxtv. Please announce this in the future. I checked the linux-media list and there is no mention of this whatsoever. Just putting it up in a tree is not sufficient, you have to tell people about it as well. > > Please back out this driver, put it in a separate tree and let me 1) > > review this driver first, and 2) help Sri implementing the > > v4l2_device/v4l2_subdev stuff. > > It is better to review it at the tree. I won't merge it upstream until > the remaining bugs would be fixed. Until then, it will wait on my staging > -git tree (the pending tree). > > > > First of all, except for ivtv drivers, the first conversion to the > > > new model > > > occurred just few weeks ago. The new model will bring some gains, but > > > this shouldn't stop the merge of the drivers whose development > > > started before we > > > port the drivers used as example by the developer. > > > > > > This is a new model, and we should give people some time to adapt to > > > it. This > > > is the way we worked in the past and it is the way we should keep > > > working. > > > > It's not a new model. > > It is. The first changeset were committed on Nov, 30, and the last > internal API changes, according with the docs, happened on Feb, 14. So, > if we don't touch on it, the first stable version of the framework will > be available upstream on 2.6.30. > > If we keep it stable during 2.6.30, convert the drivers merged on 2.6.30 > to the new framework, and mark the legacy approach as a feature to be > removed on a patch applied at 2.6.30, then we can remove the previous > support for 2.6.31. It's not v4l2_device/v4l2_subdev that's at stake here. It's the removal of the old i2c autoprobing behavior. v4l2_device/v4l2_subdev is just the fastest way to do this for v4l drivers. As you can see here: http://i2c.wiki.kernel.org/index.php/Legacy_drivers_to_be_converted the conversion is almost done. This weekend I hope to finish cx88, cx23885 and bttv. Hopefully Douglas Landgraf can convert em28xx and I know Mike Isely only needs to do some final tweaks for pvrusb2. I do not expect newly submitted drivers to use v4l2_device/subdev. I know it is a very recent development. But it is very easy to implement and all I need is a chance to review and help them with that to ensure that dropping the old i2c API isn't blocked by a new driver. Not in the least because it is likely that the i2c core maintainer will block such a new driver if it is the only driver preventing the removal of the old i2c API. In addition, once a driver is in the v4l-dvb tree I cannot just drop the old i2c API support in v4l-dvb since that will just break any driver that uses it. So whether it goes to the git tree or not, that doesn't matter for me. > $ hg log linux/Documentation/video4linux/v4l2-framework.txt > > changeset: 10648:e471b963bef6 > parent: 10640:4f6c3f9efa58 > parent: 10647:63256532f5a7 > user:Mauro Carvalho Chehab > date:Tue Feb 17 23:44:45 2009 -0300 > summary: merge: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb > > changeset: 10644:44b5df81ab02 > user:Hans Verkuil > date:Sat Feb 14 16:00:53 2009 +0100 > summary: v4l2-subdev: rename dev field to v4l2_dev > > changeset: 10643:9eb2f6220a18 > user:Hans Verkuil > date:Sat Feb 14 15:54:23 2009 +0100 > summary: v4l2-device: allow a NULL parent device when registering. > > changeset: 10573:b73e7bdad8c4 > user:Mauro Carvalho Chehab > date:Mon Feb 16 15:54:29 2009 -0300 > summary: v4l2-framework.txt: Whitespace clenups > > changeset: 10571:12a10f808bfd > user:Mauro Carvalho Chehab > date:Sat Feb 14 08:51:28 2009 -0200 > summary: v4l2-framework.txt: Fixes the videobuf init functions > > changeset: 10570:6f4cff0e7f16 > user:Mauro Carvalho Chehab > date:Sat Feb 14 08:29:07 2009 -0200 > summary: v4l2-framework: documments videobuf usage on drivers > > changeset: 10489:c84416787a43 > user:Mauro Carvalho Chehab > date:Sat Feb 07 11:07:04 2009 +0100 > summary: doc: use consistent nami
Re: [PATCH 1/1] siano: add high level SDIO interface driver for SMS based cards
Hi Alexey,
I numbered your comments and append all answers to the end of this email.
--- On Fri, 3/13/09, Alexey Klimov wrote:
> From: Alexey Klimov
> Subject: Re: [PATCH 1/1] siano: add high level SDIO interface driver for SMS
> based cards
> To: "Uri Shkolnik"
> Cc: "Mauro Carvalho Chehab" , "Michael Krufky"
> , linux-media@vger.kernel.org
> Date: Friday, March 13, 2009, 12:46 AM
> Hello, Uri
>
> On Thu, 2009-03-12 at 06:52 -0700, Uri Shkolnik wrote:
> > # HG changeset patch
> > # User Uri Shkolnik
> > # Date 1236865697 -7200
> > # Node ID 7352ee1288f651d19d58c7bb479a98f070ad98e6
> > # Parent
> 3392722cc5b687586c4d898b73050ab6e59bf401
> > siano: add high level SDIO interface driver for SMS
> based cards
> >
> > From: Uri Shkolnik
> >
> > This patch provides SDIO interface driver for
> > SMS (Siano Mobile Silicon) based devices.
> > The patch includes SMS high level SDIO driver and
> > requires patching the kernel SDIO stack,
> > those stack patches had been provided previously.
> >
> > I would like to thank Pierre Ossman, MMC maintainer,
> > who wrote this driver.
> >
> > Priority: normal
> >
> > Signed-off-by: Pierre Ossman
> > Signed-off-by: Uri Shkolnik
> >
> > diff -r 3392722cc5b6 -r 7352ee1288f6
> linux/drivers/media/dvb/siano/smssdio.c
> > --- /dev/null Thu Jan 01 00:00:00
> 1970 +
> > +++
> b/linux/drivers/media/dvb/siano/smssdio.c
> Thu Mar 12 15:48:17 2009 +0200
> > @@ -0,0 +1,356 @@
> > +/*
> > + * smssdio.c - Siano 1xxx SDIO interface
> driver
> > + *
> > + * Copyright 2008 Pierre Ossman
>
> I'm sorry, but may be 2009 ?
[ #1 ]
>
> > + *
> > + * Based on code by Siano Mobile Silicon, Inc.,
> > + * Copyright (C) 2006-2008, Uri Shkolnik
> > + *
> > + * 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 hardware is a bit odd in that all transfers
> should be done
> > + * to/from the SMSSDIO_DATA register, yet the
> "increase address" bit
> > + * always needs to be set.
> > + *
> > + * Also, buffers from the card are always aligned to
> 128 byte
> > + * boundaries.
> > + */
> > +
> > +/*
> > + * General cleanup notes:
> > + *
> > + * - only typedefs should be name *_t
> > + *
> > + * - use ERR_PTR and friends for
> smscore_register_device()
> > + *
> > + * - smscore_getbuffer should zero fields
> > + *
> > + * Fix stop command
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "smscoreapi.h"
> > +#include "sms-cards.h"
> > +
> > +/* Registers */
> > +
> > +#define SMSSDIO_DATA
> 0x00
> > +#define SMSSDIO_INT
> 0x04
> > +
> > +static const struct sdio_device_id smssdio_ids[] = {
> > + {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO,
> SDIO_DEVICE_ID_SIANO_STELLAR),
> > + .driver_data =
> SMS1XXX_BOARD_SIANO_STELLAR},
> > + {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO,
> SDIO_DEVICE_ID_SIANO_NOVA_A0),
> > + .driver_data =
> SMS1XXX_BOARD_SIANO_NOVA_A},
> > + {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO,
> SDIO_DEVICE_ID_SIANO_NOVA_B0),
> > + .driver_data =
> SMS1XXX_BOARD_SIANO_NOVA_B},
> > + {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO,
> SDIO_DEVICE_ID_SIANO_VEGA_A0),
> > + .driver_data =
> SMS1XXX_BOARD_SIANO_VEGA},
> > + {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO,
> SDIO_DEVICE_ID_SIANO_VENICE),
> > + .driver_data =
> SMS1XXX_BOARD_SIANO_VEGA},
> > + { /* end: all zeroes */ },
> > +};
> > +
> > +MODULE_DEVICE_TABLE(sdio, smssdio_ids);
> > +
> > +struct smssdio_device {
> > + struct sdio_func *func;
> > +
> > + struct smscore_device_t *coredev;
> > +
> > + struct smscore_buffer_t
> *split_cb;
> > +};
> > +
> >
> +/***/
> > +/* Siano core callbacks
>
>
> */
> >
> +/***/
> > +
> > +static int smssdio_sendrequest(void *context, void
> *buffer, size_t size)
> > +{
> > + int ret;
> > + struct smssdio_device *smsdev;
> > +
> > + smsdev = context;
> > +
> > + sdio_claim_host(smsdev->func);
> > +
> > + while (size >=
> smsdev->func->cur_blksize) {
> > + ret =
> sdio_write_blocks(smsdev->func, SMSSDIO_DATA, buffer,
> 1);
> > + if (ret)
> > +
> goto out;
> > +
> > + buffer +=
> smsdev->func->cur_blksize;
> > + size -=
> smsdev->func->cur_blksize;
> > + }
> > +
> > + if (size) {
> > + ret =
> sdio_write_bytes(smsdev->func, SMSSDIO_DATA,
> > +
>
> buffer, size);
> > + if (ret)
> > +
> goto out;
> > + }
>
> Do you really need this check and goto ?
> Without them, as i see, the algorithm will do the same.
>
[ #2 ]
> > +
> > +out:
> > +
> sdio_release_host(smsdev->func);
getting started
make in v4l-dvb worked without error, produced a lot of .ko files in v4l. sudo make install worked without errors, too. reconnecting the TechnoTrend CT 3650 CI, with dmesg I got --- usb 4-2: USB disconnect, address 3 usb 4-2: new high speed USB device using ehci_hcd and address 6 usb 4-2: configuration #1 chosen from 1 choice usb 4-2: New USB device found, idVendor=0b48, idProduct=300d usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 4-2: Product: TT-USB2.0 usb 4-2: Manufacturer: TechnoTrend usb 4-2: SerialNumber: LHKAMG --- and thought, dvb_usb_ttusb2 would be the driver to load. However, neither /dev/dvb0 nor /dev/video0 appeared following "sudo modprobe dvb_usb_ttusb2". Restart of linux did not help and did not reload dvb_usb_ttusb2. I know it worked once but forgot, how. And it seems that it works with some others: http://www.linuxtv.org/pipermail/linux-dvb/2008-August/027804.html How to determine what driver I need? Do I need firmware? Rolf -- 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] Add support for ProVideo PV-183 to bttv (take 2 - changed spaces to tabs)
Add support for ProVideo PV-183 to bttv
From: Alan McIvor
This patch adds support for the ProVideo PV-183 card to the bttv
device driver. The PV-183 is a PCI card with 8 BT878 devices plus a Hint
Corp HiNT HB4 PCI-PCI Bridge. Each BT878 has two composite input channels
available. There are no tuners on this card.
This patch was generated against the V4L-DVB mercurial tree as of 12
March 2009.
Priority: normal
Signed-off-by: Alan McIvor
--- linux/drivers/media/video/bt8xx/bttv.h.orig 2009-03-13 10:12:09.0
+1300
+++ linux/drivers/media/video/bt8xx/bttv.h 2009-03-13 10:18:46.0
+1300
@@ -184,6 +184,7 @@
#define BTTV_BOARD_IVCE8784 0x9c
#define BTTV_BOARD_GEOVISION_GV800S 0x9d
#define BTTV_BOARD_GEOVISION_GV800S_SL0x9e
+#define BTTV_BOARD_PV183 0x9f
/* more card-specific defines */
--- linux/drivers/media/video/bt8xx/bttv-cards.c.orig 2009-03-13
10:12:19.0 +1300
+++ linux/drivers/media/video/bt8xx/bttv-cards.c2009-03-13
13:19:50.0 +1300
@@ -321,6 +321,16 @@ static struct CARD {
{ 0x763d800b, BTTV_BOARD_GEOVISION_GV800S_SL, "GeoVision GV-800(S)
(slave)" },
{ 0x763d800c, BTTV_BOARD_GEOVISION_GV800S_SL, "GeoVision GV-800(S)
(slave)" },
{ 0x763d800d, BTTV_BOARD_GEOVISION_GV800S_SL, "GeoVision GV-800(S)
(slave)" },
+
+ { 0x15401830, BTTV_BOARD_PV183, "Provideo PV183-1" },
+ { 0x15401831, BTTV_BOARD_PV183, "Provideo PV183-2" },
+ { 0x15401832, BTTV_BOARD_PV183, "Provideo PV183-3" },
+ { 0x15401833, BTTV_BOARD_PV183, "Provideo PV183-4" },
+ { 0x15401834, BTTV_BOARD_PV183, "Provideo PV183-5" },
+ { 0x15401835, BTTV_BOARD_PV183, "Provideo PV183-6" },
+ { 0x15401836, BTTV_BOARD_PV183, "Provideo PV183-7" },
+ { 0x15401837, BTTV_BOARD_PV183, "Provideo PV183-8" },
+
{ 0, -1, NULL }
};
@@ -2910,6 +2920,20 @@ struct tvcard bttv_tvcards[] = {
.no_tda9875 = 1,
.muxsel_hook= gv800s_muxsel,
},
+ [BTTV_BOARD_PV183] = {
+ .name = "ProVideo PV183", /* 0x9f */
+ .video_inputs = 2,
+ /* .audio_inputs= 0, */
+ .svhs = NO_SVHS,
+ .gpiomask = 0,
+ .muxsel = MUXSEL(2, 3),
+ .gpiomux= { 0 },
+ .needs_tvaudio = 0,
+ .no_msp34xx = 1,
+ .pll= PLL_28,
+ .tuner_type = TUNER_ABSENT,
+ .tuner_addr = ADDR_UNSET,
+ },
};
static const unsigned int bttv_num_tvcards = ARRAY_SIZE(bttv_tvcards);
--- linux/Documentation/video4linux/CARDLIST.bttv.orig 2009-03-13
13:39:03.0 +1300
+++ linux/Documentation/video4linux/CARDLIST.bttv 2009-03-13
13:28:03.0 +1300
@@ -157,3 +157,4 @@
156 -> IVCE-8784
[:f050,0001:f050,0002:f050,0003:f050]
157 -> Geovision GV-800(S) (master)[800a:763d]
158 -> Geovision GV-800(S) (slave)
[800b:763d,800c:763d,800d:763d]
+159 -> ProVideo PV183
[1830:1540,1831:1540,1832:1540,1833:1540,1834:1540,1835:1540,1836:1540,1837:1540]
--
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] Add support for ProVideo PV-183 to bttv
On Fri, 13 Mar 2009, Alan McIvor wrote:
> +
> +{ 0x15401830, BTTV_BOARD_PV183, "Provideo PV183-1" },
> +{ 0x15401831, BTTV_BOARD_PV183, "Provideo PV183-2" },
> +{ 0x15401832, BTTV_BOARD_PV183, "Provideo PV183-3" },
> +{ 0x15401833, BTTV_BOARD_PV183, "Provideo PV183-4" },
> +{ 0x15401834, BTTV_BOARD_PV183, "Provideo PV183-5" },
> +{ 0x15401835, BTTV_BOARD_PV183, "Provideo PV183-6" },
> +{ 0x15401836, BTTV_BOARD_PV183, "Provideo PV183-7" },
> +{ 0x15401837, BTTV_BOARD_PV183, "Provideo PV183-8" },
> +
> { 0, -1, NULL }
> };
Looks like you used spaces here instead of tabs. If you run make commit
from the v4l-dvb tree it will fix these things.
--
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://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Thu, 12 Mar 2009 10:11:12 -0400 Devin Heitmueller wrote: > On Thu, Mar 12, 2009 at 4:54 AM, Mauro Carvalho Chehab > wrote: > > Hi Devin, > > > > There's a bug on your patch series: see this: > > > > Those are the locations of au8522 files at Kernel's tree: > > drivers/media/dvb/frontends/au8522.h > > drivers/media/dvb/frontends/au8522_dig.c > > drivers/media/dvb/frontends/au8522_priv.h > > drivers/media/video/au8522_decoder.c > > > > And those are the Makefile rules for au8522.h on > > drivers/media/dvb/frontends/Makefile: > > > > au8522-objs = au8522_dig.o au8522_decoder.o > > obj-$(CONFIG_DVB_AU8522) += au8522.o > > > > When you're compiling the out-of-tree version, everything works OK, but, for > > in-tree compilation, au8522_decoder won't be compiled, since the file will > > be > > in the wrong dir. > > > > If I'm understanding well, this chip has two functions: it is a dvb frontend > > and an analog video/audio demodulator, right? > > > > One solution would be to have all those files in the same directory. > > However, > > au8522_decoder doesn't fit well on dvb/frontends. It is also not a tuner, > > otherwise common/tuners would be another better place. > > > > Another alternative would be to create two kconfig rules (and two separate > > modules), being one for au8522_decoder and another for the frontend, since > > they > > are, in fact, two different things. > > > > I suspect,however, that compiling just one or another would break > > compilation. > > So, we need to create some sort of rules that will warrant that both modules > > will be compiled at the same time. This is not an easy task, since we cannot > > add "depends on", since frontends are compiled by using "select". So, we > > will > > need to re-design the Kconfig rules to use depends on instead of select > > (well, > > this is something good, anyway, since the usage of "select" is something > > that > > should be avoided, according with Kbuild docs). > > > > I'll keep reviewing the patch series. Maybe I'll merge it, but, in this > > case, > > I'll need to blacklist the module until we found a solution, or find a way > > to > > allow my -git trees to compile. > > > > Cheers, > > Mauro > > > > Hello Mauro, > > Both files are required, as they share certain functions (such as the > i2c transfer functions). Also, they share a common state mechanism, > which is why both files end up in the same .ko file. > > This case is a little unique since it is the first case where we have > a single chip that acts as a digital demod, an analog demod, and an > analog video/audio decoder. > > I can certainly put the au8522_decoder.c into dvb/frontends even > though this probably violates some rule about analog stuff being in > the DVB section of the tree. Would that resolve your concern? > > I really don't want to make redesigning the KConfig rules a > prerequisite to getting this rather large patch series merged. I > would suggest we do what is required to get the code in (such as > moving the _decoder.c to frontends), and then we can tune the solution > to be something more optimal in terms of how the tree is structured. I don't like much the idea of moving decoder to frontends, but we may do this as an intermediate step. To make things easier for future changes, IMO, it would be better to create a separate dir for this driver, inside dvb/frontends. This will help to move it elsewhere. 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: Fwd: [stable] [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
On Thu, 2009-03-12 at 19:18 -0400, Michael Krufky wrote: > Andy Walls wrote: > > On Thu, 2009-03-12 at 16:24 -0400, Michael Krufky wrote: > > > >> Can we have this merged into -stable? Jarod Wilson sent this last > >> month, but he left off the cc to sta...@kernel.org > >> > >> Signed-off-by: Michael Krufky > >> > > > > Mike, > > > > A version of this is already in the v4l-dvb hg development repository: > > > > hg log -vp --limit 1 linux/drivers/media/video/cx23885/cx23885-417.c > > hg log -vp --limit 2 linux/drivers/media/video/cx23885/cx23885-video.c > > > > I helped Mark work through the solution: I coded some of it, he coded > > some of it and he also tested it. > > > > Regards, > > Andy > > I'm aware of that, Andy -- That's why I am sending this off to the > -stable team for 2.6.27.y Ooops. Sorry for my cluelessness. :) Regards, Andy > Thanks & regards, > > Mike > -- > 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: disable v4l2-ctl logging --log-status in /var/log/messages
On Friday 13 March 2009 00:34:43 Andy Walls wrote: > On Thu, 2009-03-12 at 10:49 +0100, Gregor Fuis wrote: > > On Thu, Mar 12, 2009 at 10:28 AM, Hans Verkuil wrote: > > >> Hello, > > >> > > >> Is it possible to disable v4l2-ctl aplication logging into > > >> /var/log/messages. > > >> I am using it to control and monitor my PVR 150 cards and every time > > >> I run v4l2-ctl -d /dev/video0 --log-status all output is logged into > > >> /var/log/messages and some other linux log files. > > > > > > All --log-status does is to tell the driver to show it's status in > > > the kernel log for debugging purposes. It cannot and should not be > > > relied upon for monitoring/controlling a driver. > > > > > > What do you need it for anyway? > > > > I am just monitoring if signal is present on tuner, and what signal > > format is detected. > > These two lines: > > cx25840 1-0044: Video signal: not present > > cx25840 1-0044: Detected format: PAL-Nc > > I run this every minute and it is really annoying to have all this in > > my system logs. > > Is it possible to modify v4l2-ctl source to disable system logging? > > $ v4l2-ctl -d /dev/video0 -T > > which calls the VIDIOC_G_TUNER ioctl(), can be used to tell you if a > signal is present: > > Tuner: > Name : cx18 TV Tuner > Capabilities : 62.5 kHz multi-standard stereo lang1 lang2 > Frequency range : 44.0 MHz - 958.0 MHz > Signal strength/AFC : 0%/-187500 > Current audio mode : lang1 > Available subchannels: mono > > Signal strength will be 0% or 100% - both the cx18 driver and the > cx25840 driver behave the same in this regard. > > AFAICT, other than --log-status (the VIDIOC_LOG_STATUS ioctl()) which > always writes to the system logs, there is no way for a non-root user to > read out the Video standard detected by the CX25843 hardware. That > would require a change to the driver(s) and maybe an API change (I'm not > sure). There is a VIDIOC_QUERYSTD ioctl. However, neither ivtv nor cx25840 supports that. I've always thought that that would be a useful addition, but never got around to implementing it. You are the first one for whom such an ioctl would actually be useful, Gregor :-) It should be fairly easy to add this, but I really don't have the time for this I'm afraid. 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: disable v4l2-ctl logging --log-status in /var/log/messages
On Thu, 2009-03-12 at 10:49 +0100, Gregor Fuis wrote: > On Thu, Mar 12, 2009 at 10:28 AM, Hans Verkuil wrote: > > > >> Hello, > >> > >> Is it possible to disable v4l2-ctl aplication logging into > >> /var/log/messages. > >> I am using it to control and monitor my PVR 150 cards and every time I > >> run v4l2-ctl -d /dev/video0 --log-status all output is logged into > >> /var/log/messages and some other linux log files. > > > > All --log-status does is to tell the driver to show it's status in the > > kernel log for debugging purposes. It cannot and should not be relied upon > > for monitoring/controlling a driver. > > > > What do you need it for anyway? > > I am just monitoring if signal is present on tuner, and what signal > format is detected. > These two lines: > cx25840 1-0044: Video signal: not present > cx25840 1-0044: Detected format: PAL-Nc > I run this every minute and it is really annoying to have all this in > my system logs. > Is it possible to modify v4l2-ctl source to disable system logging? $ v4l2-ctl -d /dev/video0 -T which calls the VIDIOC_G_TUNER ioctl(), can be used to tell you if a signal is present: Tuner: Name : cx18 TV Tuner Capabilities : 62.5 kHz multi-standard stereo lang1 lang2 Frequency range : 44.0 MHz - 958.0 MHz Signal strength/AFC : 0%/-187500 Current audio mode : lang1 Available subchannels: mono Signal strength will be 0% or 100% - both the cx18 driver and the cx25840 driver behave the same in this regard. AFAICT, other than --log-status (the VIDIOC_LOG_STATUS ioctl()) which always writes to the system logs, there is no way for a non-root user to read out the Video standard detected by the CX25843 hardware. That would require a change to the driver(s) and maybe an API change (I'm not sure). Regards, Andy > > Regards, > Gregor -- 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
cx231xx review of i2c handling
Hi Sri,
Here is a review of the i2c part of this driver, together with pointers on
how to proceed to convert it to v4l2_device/v4l2_subdev.
Time permitting I hope to look at the v4l2 implementation in the driver as
well over the weekend, but the i2c part is for me the most urgent issue at
the moment as you've no doubt guessed by now :-)
Although I couldn't help noticing this typo:
cx231xx-cards.c:cx231xx_info("Board is Conexnat RDE 250\n");
cx231xx-cards.c:cx231xx_info("Board is Conexnat RDU 250\n");
:-)
Looking at cx231xx-i2c.c I see it has the following devices:
0x32: Geminit III
0x02: Acquarius
0xa0: eeprom
0x60: Colibri
0x8e: IR
0x80/0x88: Hammerhead
And it also uses an external tuner.
It is my understanding that these devices are integrated on the cx231xx and
so are completely internal to it:
Geminit III, Acquarius, Colibri, Hammerhead.
Is the eeprom also internal, or is it external?
Why can Hammerhead be at two addresses? Since it is an integral device I'd
expect that the address would be fixed. Or are there two Hammerheads?
Looking at the source I'd say that it can only be at address 0x88.
A general note: please add a description in the cx231xx.h header or in
another suitable place for each of these devices. The codenames themselves
do not give much of an idea of what the device actually does.
I have 'decoded' that Hammerhead is the cx231xx version of the cx25843. You
are loading the cx25840 module to handle this (good), but you also write
directly to the i2c device from the cx231xx driver (bad). You have to make
a choice here: either handle it completely from inside cx231xx, or add full
support for it to the cx25840 module and call that.
The rule is that parent drivers of an i2c module should never attempt to set
registers directly as that breaks reusability. In this case, suppose a
change is made in cx25840 that overwrites a register you've set from
without cx231xx. Now the cx231xx is broken, and that is because there is no
way of knowing when you edit the cx25840 sources that it is used like that.
Whereas if all the code that reads and writes registers is fully within the
cx25840 module, then whoever needs to modify that driver can see the whole
picture.
It is much preferred to keep using cx25840 and just add the missing pieces
to that driver, rather than moving all the code inside cx231xx.
Since the i2c addresses for the integral i2c devices are hardwired (I
assume), I recommend making some simple inline functions like this:
static int inline colibri_read_byte(struct cx231xx *dev, int reg, u8 *byte)
{
return cx231xx_read_i2c_data(dev, Colibri_DEVICE_ADDRESS,
reg, 2, byte, 1);
}
That will make the code much more readable.
A note on the cx231xx_usb_disconnect: this can be simplified without needing
user counts and complicated code. Read the section on video_device cleanup
in the v4l2-framework.txt. The release() callback is guaranteed to be
called when the last user disappears, so you can do your cleanup there.
This is a fairly recent change. Before this was implemented each USB driver
had to do their own reference counting.
Anyway, none of the points above is really urgent. What is urgent is that
the new i2c API should be used. The background for this is that currently
you just load an i2c module (e.g. tuner or cx25840) and it magically probes
the i2c bus and attaches itself when it finds a suitable i2c device. The
problem with that is that not all i2c devices can be uniquely identified,
so that can lead to misdetections and that can cause lots of problems,
including cases of corrupted eeproms.
A new i2c API was created for this and at the moment both old and new
co-exist. However, the intention is to remove support for the old i2c API
from the i2c core in 2.6.30.
Rather than just switching to the new API I've taken the opportunity to
integrate it into a bigger v4l2 framework, based around new v4l2_device and
v4l2_subdev structs. Currently the sole purpose is to aid in the migration
to the new i2c API, basically hiding all the details from the driver. A
major advantage of v4l2_subdev is also that it is not limited to i2c
devices, instead you can model just about any type of device around it.
This is particularly useful for highly integrated devices and it might be
interesting to consider their use for the integrated devices that cx231xx
has.
Please read v4l2-framework.txt. Let me know if something is not clear as
that might indicate that I need to improve it.
This driver luckily doesn't need a lot of work. The first step is to
introduce struct v4l2_device. Just stick it in struct cx231xx, register it
in cx231xx_usb_probe and unregister it when cleaning up.
One thing you need to be aware of is that you should set i2c_set_adapdata to
the v4l2_device pointer instead of the cx231xx_i2c bus.
The second step is to load the i2c modules through v4l2_i2c_new_subdev or
v4l2
Re: Fwd: [stable] [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
Andy Walls wrote: On Thu, 2009-03-12 at 16:24 -0400, Michael Krufky wrote: Can we have this merged into -stable? Jarod Wilson sent this last month, but he left off the cc to sta...@kernel.org Signed-off-by: Michael Krufky Mike, A version of this is already in the v4l-dvb hg development repository: hg log -vp --limit 1 linux/drivers/media/video/cx23885/cx23885-417.c hg log -vp --limit 2 linux/drivers/media/video/cx23885/cx23885-video.c I helped Mark work through the solution: I coded some of it, he coded some of it and he also tested it. Regards, Andy I'm aware of that, Andy -- That's why I am sending this off to the -stable team for 2.6.27.y Thanks & regards, Mike -- 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: Fwd: [stable] [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
On Thu, 2009-03-12 at 16:24 -0400, Michael Krufky wrote:
> Can we have this merged into -stable? Jarod Wilson sent this last
> month, but he left off the cc to sta...@kernel.org
>
> Signed-off-by: Michael Krufky
Mike,
A version of this is already in the v4l-dvb hg development repository:
hg log -vp --limit 1 linux/drivers/media/video/cx23885/cx23885-417.c
hg log -vp --limit 2 linux/drivers/media/video/cx23885/cx23885-video.c
I helped Mark work through the solution: I coded some of it, he coded
some of it and he also tested it.
Regards,
Andy
>
> -- Forwarded message --
> From: Jarod Wilson
> Date: Tue, Feb 24, 2009 at 6:00 PM
> Subject: [stable] [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
> To: linux-ker...@vger.kernel.org
> Cc: Mike Krufky
>
>
> From: Mark Jenks
> https://www.redhat.com/mailman/private/video4linux-list/2009-January/msg00041.html
>
> The Hauppauge WinTV HVR-1800 tv tuner card has both digital and analog
> abilities, both of which are supported by v4l/dvb under 2.6.27.y. The analog
> side also features a hardware mpeg2 encoder. The HVR-1250 tv tuner card
> has both digital and analog abilities, but analog isn't currently supported
> under any kernel. These cards both utilize the cx23885 driver, but with
> slightly different usage. When the code paths for each card is executed,
> they wind up poking a cx23885_devlist, which contains devices from both
> of the cards, and access attempts are made to portions of 'struct
> cx23885_dev' that aren't valid for that device. Simply add some extra
> checks before trying to access these structs.
>
> More gory details:
> http://article.gmane.org/gmane.linux.drivers.dvb/46630
>
> This was triggering on my own system at home w/both cards in it, and
> no longer happens with this patch included.
>
> Signed-off-by: Jarod Wilson
> Reviewed-by: Michael Krufky
>
> ---
>
> drivers/media/video/cx23885/cx23885-417.c |2 +-
> drivers/media/video/cx23885/cx23885-video.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/video/cx23885/cx23885-417.c
> b/drivers/media/video/cx23885/cx23885-417.c
> index 7b0e8c0..19154b6 100644
> --- a/drivers/media/video/cx23885/cx23885-417.c
> +++ b/drivers/media/video/cx23885/cx23885-417.c
> @@ -1585,7 +1585,7 @@ static int mpeg_open(struct inode *inode, struct
> file *file)
>
>list_for_each(list, &cx23885_devlist) {
>h = list_entry(list, struct cx23885_dev, devlist);
> - if (h->v4l_device->minor == minor) {
> + if (h->v4l_device && h->v4l_device->minor == minor) {
>dev = h;
>break;
>}
> diff --git a/drivers/media/video/cx23885/cx23885-video.c
> b/drivers/media/video/cx23885/cx23885-video.c
> index 6047c78..a2b5a0c 100644
> --- a/drivers/media/video/cx23885/cx23885-video.c
> +++ b/drivers/media/video/cx23885/cx23885-video.c
> @@ -733,7 +733,7 @@ static int video_open(struct inode *inode, struct
> file *file)
>
>list_for_each(list, &cx23885_devlist) {
>h = list_entry(list, struct cx23885_dev, devlist);
> - if (h->video_dev->minor == minor) {
> + if (h->video_dev && h->video_dev->minor == minor) {
>dev = h;
>type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>}
>
>
> --
> Jarod Wilson
> ja...@redhat.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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] Add support for ProVideo PV-183 to bttv
This patch adds support for the ProVideo PV-183 card to the bttv
device driver. The PV-183 is a PCI card with 8 BT878 devices plus a Hint
Corp HiNT HB4 PCI-PCI Bridge. Each BT878 has two composite input channels
available. There are no tuners on this card.
This patch was generated against the V4L-DVB mercurial tree as of 12
March 2009.
Signed-off-by: Alan McIvor
--- linux/drivers/media/video/bt8xx/bttv.h.orig 2009-03-13 10:12:09.0
+1300
+++ linux/drivers/media/video/bt8xx/bttv.h 2009-03-13 10:18:46.0
+1300
@@ -184,6 +184,7 @@
#define BTTV_BOARD_IVCE8784 0x9c
#define BTTV_BOARD_GEOVISION_GV800S 0x9d
#define BTTV_BOARD_GEOVISION_GV800S_SL0x9e
+#define BTTV_BOARD_PV183 0x9f
/* more card-specific defines */
--- linux/drivers/media/video/bt8xx/bttv-cards.c.orig 2009-03-13
10:12:19.0 +1300
+++ linux/drivers/media/video/bt8xx/bttv-cards.c2009-03-13
10:24:28.0 +1300
@@ -321,6 +321,16 @@ static struct CARD {
{ 0x763d800b, BTTV_BOARD_GEOVISION_GV800S_SL, "GeoVision GV-800(S)
(slave)" },
{ 0x763d800c, BTTV_BOARD_GEOVISION_GV800S_SL, "GeoVision GV-800(S)
(slave)" },
{ 0x763d800d, BTTV_BOARD_GEOVISION_GV800S_SL, "GeoVision GV-800(S)
(slave)" },
+
+{ 0x15401830, BTTV_BOARD_PV183, "Provideo PV183-1" },
+{ 0x15401831, BTTV_BOARD_PV183, "Provideo PV183-2" },
+{ 0x15401832, BTTV_BOARD_PV183, "Provideo PV183-3" },
+{ 0x15401833, BTTV_BOARD_PV183, "Provideo PV183-4" },
+{ 0x15401834, BTTV_BOARD_PV183, "Provideo PV183-5" },
+{ 0x15401835, BTTV_BOARD_PV183, "Provideo PV183-6" },
+{ 0x15401836, BTTV_BOARD_PV183, "Provideo PV183-7" },
+{ 0x15401837, BTTV_BOARD_PV183, "Provideo PV183-8" },
+
{ 0, -1, NULL }
};
@@ -2910,6 +2920,20 @@ struct tvcard bttv_tvcards[] = {
.no_tda9875 = 1,
.muxsel_hook= gv800s_muxsel,
},
+ [BTTV_BOARD_PV183] = {
+ .name = "ProVideo PV183", /* 0x9f */
+ .video_inputs = 2,
+ /* .audio_inputs= 0, */
+ .svhs = NO_SVHS,
+ .gpiomask = 0,
+ .muxsel = MUXSEL(2, 3),
+ .gpiomux= { 0 },
+ .needs_tvaudio = 0,
+ .no_msp34xx = 1,
+ .pll= PLL_28,
+ .tuner_type = TUNER_ABSENT,
+ .tuner_addr = ADDR_UNSET,
+ },
};
static const unsigned int bttv_num_tvcards = ARRAY_SIZE(bttv_tvcards);
--
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
[Fwd: Re: [linux-dvb] getting started]
ok, adapted the value in v4l/.version make is doing fine now Original Message Subject:Re: [linux-dvb] getting started Date: Thu, 12 Mar 2009 23:47:24 +0100 From: Rolf Schumacher To: linux-media@vger.kernel.org References: <49b982a5.7010...@august.de> <49b98677.9030...@iki.fi> thank you, Antti, Thomas kernel-headers are installed. Why does make try to read the wrong file? My kernel is named 2.6.28-7.slh.4-sidux-686, not 2.6.28-7.slh.3-sidux-686 - r...@rolf9:~/src/v4l-dvb$ make make -C /home/rsc/src/v4l-dvb/v4l make[1]: Entering directory `/home/rsc/src/v4l-dvb/v4l' Updating/Creating .config Preparing to compile for kernel version 2.6.28 File not found: /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config at ./scripts/make_kconfig.pl line 32, line 4. make[1]: *** Keine Regel vorhanden, um das Target ?.myconfig?, beno"tigt von ?config-compat.h?, zu erstellen. Schluss. make[1]: Leaving directory `/home/rsc/src/v4l-dvb/v4l' make: *** [all] Fehler 2 r...@rolf9:~/src/v4l-dvb$ r...@rolf9:~/src/v4l-dvb$ ls -la /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config ls: Zugriff auf /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config nicht mo"glich: Datei oder Verzeichnis nicht gefunden r...@rolf9:~/src/v4l-dvb$ ls -la /lib/modules/2.6.28-7.slh.4-sidux-686/build/.config -rw-r--r-- 1 root root 95158 12. Ma"r 00:30 /lib/modules/2.6.28-7.slh.4-sidux-686/build/.config r...@rolf9:~/src/v4l-dvb$ hg update 0 files updated, 0 files merged, 0 files removed, 0 files unresolved r...@rolf9:~/src/v4l-dvb$ Antti Palosaari wrote: > Rolf Schumacher wrote: > >> File not found: /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config at >> ./scripts/make_kconfig.pl line 32, line 4. >> > > kernel-devel, kernel-headers, linux-devel or linux-headers package is > missing. Package name varies from distribution to distribution... > > > -- 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: [linux-dvb] getting started
thank you, Antti, Thomas kernel-headers are installed. Why does make try to read the wrong file? My kernel is named 2.6.28-7.slh.4-sidux-686, not 2.6.28-7.slh.3-sidux-686 - r...@rolf9:~/src/v4l-dvb$ make make -C /home/rsc/src/v4l-dvb/v4l make[1]: Entering directory `/home/rsc/src/v4l-dvb/v4l' Updating/Creating .config Preparing to compile for kernel version 2.6.28 File not found: /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config at ./scripts/make_kconfig.pl line 32, line 4. make[1]: *** Keine Regel vorhanden, um das Target ?.myconfig?, beno"tigt von ?config-compat.h?, zu erstellen. Schluss. make[1]: Leaving directory `/home/rsc/src/v4l-dvb/v4l' make: *** [all] Fehler 2 r...@rolf9:~/src/v4l-dvb$ r...@rolf9:~/src/v4l-dvb$ ls -la /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config ls: Zugriff auf /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config nicht mo"glich: Datei oder Verzeichnis nicht gefunden r...@rolf9:~/src/v4l-dvb$ ls -la /lib/modules/2.6.28-7.slh.4-sidux-686/build/.config -rw-r--r-- 1 root root 95158 12. Ma"r 00:30 /lib/modules/2.6.28-7.slh.4-sidux-686/build/.config r...@rolf9:~/src/v4l-dvb$ hg update 0 files updated, 0 files merged, 0 files removed, 0 files unresolved r...@rolf9:~/src/v4l-dvb$ Antti Palosaari wrote: > Rolf Schumacher wrote: > >> File not found: /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config at >> ./scripts/make_kconfig.pl line 32, line 4. >> > > kernel-devel, kernel-headers, linux-devel or linux-headers package is > missing. Package name varies from distribution to distribution... > > > -- 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/1] siano: add high level SDIO interface driver for SMS based cards
Hello, Uri
On Thu, 2009-03-12 at 06:52 -0700, Uri Shkolnik wrote:
> # HG changeset patch
> # User Uri Shkolnik
> # Date 1236865697 -7200
> # Node ID 7352ee1288f651d19d58c7bb479a98f070ad98e6
> # Parent 3392722cc5b687586c4d898b73050ab6e59bf401
> siano: add high level SDIO interface driver for SMS based cards
>
> From: Uri Shkolnik
>
> This patch provides SDIO interface driver for
> SMS (Siano Mobile Silicon) based devices.
> The patch includes SMS high level SDIO driver and
> requires patching the kernel SDIO stack,
> those stack patches had been provided previously.
>
> I would like to thank Pierre Ossman, MMC maintainer,
> who wrote this driver.
>
> Priority: normal
>
> Signed-off-by: Pierre Ossman
> Signed-off-by: Uri Shkolnik
>
> diff -r 3392722cc5b6 -r 7352ee1288f6 linux/drivers/media/dvb/siano/smssdio.c
> --- /dev/null Thu Jan 01 00:00:00 1970 +
> +++ b/linux/drivers/media/dvb/siano/smssdio.c Thu Mar 12 15:48:17 2009 +0200
> @@ -0,0 +1,356 @@
> +/*
> + * smssdio.c - Siano 1xxx SDIO interface driver
> + *
> + * Copyright 2008 Pierre Ossman
I'm sorry, but may be 2009 ?
> + *
> + * Based on code by Siano Mobile Silicon, Inc.,
> + * Copyright (C) 2006-2008, Uri Shkolnik
> + *
> + * 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 hardware is a bit odd in that all transfers should be done
> + * to/from the SMSSDIO_DATA register, yet the "increase address" bit
> + * always needs to be set.
> + *
> + * Also, buffers from the card are always aligned to 128 byte
> + * boundaries.
> + */
> +
> +/*
> + * General cleanup notes:
> + *
> + * - only typedefs should be name *_t
> + *
> + * - use ERR_PTR and friends for smscore_register_device()
> + *
> + * - smscore_getbuffer should zero fields
> + *
> + * Fix stop command
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "smscoreapi.h"
> +#include "sms-cards.h"
> +
> +/* Registers */
> +
> +#define SMSSDIO_DATA 0x00
> +#define SMSSDIO_INT 0x04
> +
> +static const struct sdio_device_id smssdio_ids[] = {
> + {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_STELLAR),
> + .driver_data = SMS1XXX_BOARD_SIANO_STELLAR},
> + {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_NOVA_A0),
> + .driver_data = SMS1XXX_BOARD_SIANO_NOVA_A},
> + {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_NOVA_B0),
> + .driver_data = SMS1XXX_BOARD_SIANO_NOVA_B},
> + {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_VEGA_A0),
> + .driver_data = SMS1XXX_BOARD_SIANO_VEGA},
> + {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_VENICE),
> + .driver_data = SMS1XXX_BOARD_SIANO_VEGA},
> + { /* end: all zeroes */ },
> +};
> +
> +MODULE_DEVICE_TABLE(sdio, smssdio_ids);
> +
> +struct smssdio_device {
> + struct sdio_func *func;
> +
> + struct smscore_device_t *coredev;
> +
> + struct smscore_buffer_t *split_cb;
> +};
> +
> +/***/
> +/* Siano core callbacks*/
> +/***/
> +
> +static int smssdio_sendrequest(void *context, void *buffer, size_t size)
> +{
> + int ret;
> + struct smssdio_device *smsdev;
> +
> + smsdev = context;
> +
> + sdio_claim_host(smsdev->func);
> +
> + while (size >= smsdev->func->cur_blksize) {
> + ret = sdio_write_blocks(smsdev->func, SMSSDIO_DATA, buffer, 1);
> + if (ret)
> + goto out;
> +
> + buffer += smsdev->func->cur_blksize;
> + size -= smsdev->func->cur_blksize;
> + }
> +
> + if (size) {
> + ret = sdio_write_bytes(smsdev->func, SMSSDIO_DATA,
> +buffer, size);
> + if (ret)
> + goto out;
> + }
Do you really need this check and goto ?
Without them, as i see, the algorithm will do the same.
> +
> +out:
> + sdio_release_host(smsdev->func);
> +
> + return ret;
> +}
> +
> +/***/
> +/* SDIO callbacks */
> +/***/
> +
> +static void smssdio_interrupt(struct sdio_func *func)
> +{
> + int ret, isr;
> +
> + struct smssdio_device *smsdev;
> + struct smscore_buffer_t *cb;
> + struct SmsMsgHdr_ST *hdr;
> + size_t size;
> +
> + smsdev = sdio_get_drvdata(func);
> +
> + /*
> + * The interrupt register has no defined meaning. It is just
> + * a way of turning of the level triggered interrupt.
> + */
> + isr = sdio_read
[linux-dvb] getting started
I once had my TechnoTrend DVB-C driver working with linux, looking tv. However, completely forgot how I managed that. I think I was following the wiki How to Obtain, Build and Install V4L-DVB Device Driver I checked out the v4l-dvb sources using Mercurial. However, a make failed immediately: make -C /home/rsc/src/v4l-dvb/v4l make[1]: Entering directory `/home/rsc/src/v4l-dvb/v4l' Updating/Creating .config Preparing to compile for kernel version 2.6.28 File not found: /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config at ./scripts/make_kconfig.pl line 32, line 4. make[1]: *** Keine Regel vorhanden, um das Target ».myconfig«, benötigt von »config-compat.h«, zu erstellen. Schluss. make[1]: Leaving directory `/home/rsc/src/v4l-dvb/v4l' make: *** [all] Fehler 2 --- Am I on the right track? If so, what is missing? ngong ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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/4] pxa_camera: Fix overrun condition on last buffer
On Thu, 12 Mar 2009, Robert Jarzmik wrote:
> Guennadi Liakhovetski writes:
>
> >> diff --git a/drivers/media/video/pxa_camera.c
> >> b/drivers/media/video/pxa_camera.c
> >> index 16bf0a3..dd56c35 100644
> >> --- a/drivers/media/video/pxa_camera.c
> >> +++ b/drivers/media/video/pxa_camera.c
> >> @@ -734,14 +734,18 @@ static void pxa_camera_dma_irq(int channel, struct
> >> pxa_camera_dev *pcdev,
> >>status & DCSR_ENDINTR ? "EOF " : "", vb, DDADR(channel));
> >>
> >>if (status & DCSR_ENDINTR) {
> >> - if (camera_status & overrun) {
> >> + /*
> >> + * It's normal if the last frame creates an overrun, as there
> >> + * are no more DMA descriptors to fetch from QIF fifos
> >> + */
> >> + if (camera_status & overrun
> >> + && !list_is_last(pcdev->capture.next, &pcdev->capture)) {
> >
> > On a second look - didn't you want to test for ->active being the last?
>
> Mmm, I'm not sure I get you right here. AFAICR pcdev->active has no direct
> link
> with pcdev->capture (it has nothing to do with a list_head *). Of course with
> a
> bit of "container_of" magic (or list_entry equivalent), I'll find it ...
Ah, sorry, scratch it, I now understand what you're doing here, looks ok.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
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: [linux-dvb] getting started
Rolf Schumacher wrote: I once had my TechnoTrend DVB-C driver working with linux, looking tv. However, completely forgot how I managed that. I think I was following the wiki How to Obtain, Build and Install V4L-DVB Device Driver I checked out the v4l-dvb sources using Mercurial. However, a make failed immediately: make -C /home/rsc/src/v4l-dvb/v4l make[1]: Entering directory `/home/rsc/src/v4l-dvb/v4l' Updating/Creating .config Preparing to compile for kernel version 2.6.28 File not found: /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config at ./scripts/make_kconfig.pl line 32, line 4. make[1]: *** Keine Regel vorhanden, um das Target ».myconfig«, benötigt von »config-compat.h«, zu erstellen. Schluss. make[1]: Leaving directory `/home/rsc/src/v4l-dvb/v4l' make: *** [all] Fehler 2 --- Am I on the right track? If so, what is missing? Kernel-headers and/or source installed? Thomas -- 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: [linux-dvb] getting started
Rolf Schumacher wrote: File not found: /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config at ./scripts/make_kconfig.pl line 32, line 4. kernel-devel, kernel-headers, linux-devel or linux-headers package is missing. Package name varies from distribution to distribution... -- http://palosaari.fi/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - doc: improve the v4l2-framework documentation. - cx231xx: prevent building it on kernels < 2.6.23. - cx231xx: fix compile warning - v4l2-common: add missing i2c_unregister_device. Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt | 12 -- linux/drivers/media/video/cx231xx/cx231xx-cards.c |2 - linux/drivers/media/video/v4l2-common.c| 25 - v4l/versions.txt |4 +++ 4 files changed, 35 insertions(+), 8 deletions(-) -- 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 4/4] pxa_camera: Fix overrun condition on last buffer
Guennadi Liakhovetski writes:
>> diff --git a/drivers/media/video/pxa_camera.c
>> b/drivers/media/video/pxa_camera.c
>> index 16bf0a3..dd56c35 100644
>> --- a/drivers/media/video/pxa_camera.c
>> +++ b/drivers/media/video/pxa_camera.c
>> @@ -734,14 +734,18 @@ static void pxa_camera_dma_irq(int channel, struct
>> pxa_camera_dev *pcdev,
>> status & DCSR_ENDINTR ? "EOF " : "", vb, DDADR(channel));
>>
>> if (status & DCSR_ENDINTR) {
>> -if (camera_status & overrun) {
>> +/*
>> + * It's normal if the last frame creates an overrun, as there
>> + * are no more DMA descriptors to fetch from QIF fifos
>> + */
>> +if (camera_status & overrun
>> +&& !list_is_last(pcdev->capture.next, &pcdev->capture)) {
>
> On a second look - didn't you want to test for ->active being the last?
Mmm, I'm not sure I get you right here. AFAICR pcdev->active has no direct link
with pcdev->capture (it has nothing to do with a list_head *). Of course with a
bit of "container_of" magic (or list_entry equivalent), I'll find it ...
If that list_is_last is not good, would you provide me with a better alternative
?
Cheers.
--
Robert
--
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
Fwd: [stable] [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
Can we have this merged into -stable? Jarod Wilson sent this last
month, but he left off the cc to sta...@kernel.org
Signed-off-by: Michael Krufky
-- Forwarded message --
From: Jarod Wilson
Date: Tue, Feb 24, 2009 at 6:00 PM
Subject: [stable] [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
To: linux-ker...@vger.kernel.org
Cc: Mike Krufky
From: Mark Jenks
https://www.redhat.com/mailman/private/video4linux-list/2009-January/msg00041.html
The Hauppauge WinTV HVR-1800 tv tuner card has both digital and analog
abilities, both of which are supported by v4l/dvb under 2.6.27.y. The analog
side also features a hardware mpeg2 encoder. The HVR-1250 tv tuner card
has both digital and analog abilities, but analog isn't currently supported
under any kernel. These cards both utilize the cx23885 driver, but with
slightly different usage. When the code paths for each card is executed,
they wind up poking a cx23885_devlist, which contains devices from both
of the cards, and access attempts are made to portions of 'struct
cx23885_dev' that aren't valid for that device. Simply add some extra
checks before trying to access these structs.
More gory details:
http://article.gmane.org/gmane.linux.drivers.dvb/46630
This was triggering on my own system at home w/both cards in it, and
no longer happens with this patch included.
Signed-off-by: Jarod Wilson
Reviewed-by: Michael Krufky
---
drivers/media/video/cx23885/cx23885-417.c | 2 +-
drivers/media/video/cx23885/cx23885-video.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/cx23885/cx23885-417.c
b/drivers/media/video/cx23885/cx23885-417.c
index 7b0e8c0..19154b6 100644
--- a/drivers/media/video/cx23885/cx23885-417.c
+++ b/drivers/media/video/cx23885/cx23885-417.c
@@ -1585,7 +1585,7 @@ static int mpeg_open(struct inode *inode, struct
file *file)
list_for_each(list, &cx23885_devlist) {
h = list_entry(list, struct cx23885_dev, devlist);
- if (h->v4l_device->minor == minor) {
+ if (h->v4l_device && h->v4l_device->minor == minor) {
dev = h;
break;
}
diff --git a/drivers/media/video/cx23885/cx23885-video.c
b/drivers/media/video/cx23885/cx23885-video.c
index 6047c78..a2b5a0c 100644
--- a/drivers/media/video/cx23885/cx23885-video.c
+++ b/drivers/media/video/cx23885/cx23885-video.c
@@ -733,7 +733,7 @@ static int video_open(struct inode *inode, struct
file *file)
list_for_each(list, &cx23885_devlist) {
h = list_entry(list, struct cx23885_dev, devlist);
- if (h->video_dev->minor == minor) {
+ if (h->video_dev && h->video_dev->minor == minor) {
dev = h;
type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
}
--
Jarod Wilson
ja...@redhat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] pcm990 baseboard: add camera bus width switch setting
On Thu, Mar 12, 2009 at 08:11:27PM +0100, Guennadi Liakhovetski wrote:
> ...one more thing. I noticed, that after patch 2 the cameras would stop
> work, because iclink->gpio would be set to 0. Which would break bisection.
> Ok, this is rather theoretical, still I modified the patches a bit.
> Please, have a look, if you're ok with these changes, that's how I'm going
> to commit them. Affected are patches 2/5 and 5/5. I'm just quoting them
> below.
Yes, I was aware of this bisection problem. I just wanted to avoid
having patch 5/5 touch arch/arm and include/media or even split this
up further.
Anyway, I'm fine with the change.
Sascha
>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
>
> From 80912f8e2bbbf0f81318c68e1bd5f69fc9537795 Mon Sep 17 00:00:00 2001
> From: Sascha Hauer
> Date: Thu, 12 Mar 2009 20:04:43 +0100
> Subject: [PATCH] pcm990 baseboard: add camera bus width switch setting
>
> Some Phytec cameras have a I2C GPIO expander which allows it to
> switch between different sensor bus widths. This was previously
> handled in the camera driver. Since handling of this switch
> varies on several boards the cameras are used on, the board
> support seems a better place to handle the switch
>
> Signed-off-by: Sascha Hauer
> Signed-off-by: Guennadi Liakhovetski
> ---
> arch/arm/mach-pxa/pcm990-baseboard.c | 54 -
> 1 files changed, 45 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
> b/arch/arm/mach-pxa/pcm990-baseboard.c
> index f46698e..90a3990 100644
> --- a/arch/arm/mach-pxa/pcm990-baseboard.c
> +++ b/arch/arm/mach-pxa/pcm990-baseboard.c
> @@ -380,14 +380,50 @@ static struct pca953x_platform_data pca9536_data = {
> .gpio_base = NR_BUILTIN_GPIO + 1,
> };
>
> -static struct soc_camera_link iclink[] = {
> - {
> - .bus_id = 0, /* Must match with the camera ID above */
> - .gpio = NR_BUILTIN_GPIO + 1,
> - }, {
> - .bus_id = 0, /* Must match with the camera ID above */
> - .gpio = -ENXIO,
> +static int gpio_bus_switch;
> +
> +static int pcm990_camera_set_bus_param(struct soc_camera_link *link,
> + unsigned long flags)
> +{
> + if (gpio_bus_switch <= 0) {
> + if (flags == SOCAM_DATAWIDTH_10)
> + return 0;
> + else
> + return -EINVAL;
> + }
> +
> + if (flags & SOCAM_DATAWIDTH_8)
> + gpio_set_value(gpio_bus_switch, 1);
> + else
> + gpio_set_value(gpio_bus_switch, 0);
> +
> + return 0;
> +}
> +
> +static unsigned long pcm990_camera_query_bus_param(struct soc_camera_link
> *link)
> +{
> + int ret;
> +
> + if (!gpio_bus_switch) {
> + ret = gpio_request(NR_BUILTIN_GPIO + 1, "camera");
> + if (!ret) {
> + gpio_bus_switch = NR_BUILTIN_GPIO + 1;
> + gpio_direction_output(gpio_bus_switch, 0);
> + } else
> + gpio_bus_switch = -EINVAL;
> }
> +
> + if (gpio_bus_switch > 0)
> + return SOCAM_DATAWIDTH_8 | SOCAM_DATAWIDTH_10;
> + else
> + return SOCAM_DATAWIDTH_10;
> +}
> +
> +static struct soc_camera_link iclink = {
> + .bus_id = 0, /* Must match with the camera ID above */
> + .gpio = NR_BUILTIN_GPIO + 1,
> + .query_bus_param = pcm990_camera_query_bus_param,
> + .set_bus_param = pcm990_camera_set_bus_param,
> };
>
> /* Board I2C devices. */
> @@ -398,10 +434,10 @@ static struct i2c_board_info __initdata
> pcm990_i2c_devices[] = {
> .platform_data = &pca9536_data,
> }, {
> I2C_BOARD_INFO("mt9v022", 0x48),
> - .platform_data = &iclink[0], /* With extender */
> + .platform_data = &iclink, /* With extender */
> }, {
> I2C_BOARD_INFO("mt9m001", 0x5d),
> - .platform_data = &iclink[0], /* With extender */
> + .platform_data = &iclink, /* With extender */
> },
> };
> #endif /* CONFIG_VIDEO_PXA27x ||CONFIG_VIDEO_PXA27x_MODULE */
> --
> 1.5.4
>
>
> From 2d9b3eb219c391f9d626ae63835c8224ea8ef10e Mon Sep 17 00:00:00 2001
> From: Sascha Hauer
> Date: Thu, 12 Mar 2009 20:06:01 +0100
> Subject: [PATCH] soc-camera: remove now unused gpio member of struct
> soc_camera_link
>
> Signed-off-by: Sascha Hauer
> Signed-off-by: Guennadi Liakhovetski
> ---
> arch/arm/mach-pxa/pcm990-baseboard.c |1 -
> include/media/soc_camera.h |2 --
> 2 files changed, 0 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
> b/arch/arm/mach-pxa/pcm990-baseboard.c
> index 90a3990..6112740 100644
> --- a/arch/arm/mach-pxa/pcm990-baseboard.c
> +++ b/arch/arm/mach-pxa/pcm990-baseboard.c
> @@ -421,7 +421,6 @@ static unsigned long pcm990_camera_query_bus_param(struct
> soc_camera_link *link)
>
> static struct
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Mar 12 19:00:05 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10979:0475dee8dab8 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: OK linux-2.6.28-armv5: OK linux-2.6.29-rc7-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc7-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc7-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-rc7-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-rc7-m32r: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc7-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc7-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS 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-rc7-x86_64: WARNINGS fw/apps: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc7): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification from this daily build 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: [PATCH 2/5] pcm990 baseboard: add camera bus width switch setting
...one more thing. I noticed, that after patch 2 the cameras would stop
work, because iclink->gpio would be set to 0. Which would break bisection.
Ok, this is rather theoretical, still I modified the patches a bit.
Please, have a look, if you're ok with these changes, that's how I'm going
to commit them. Affected are patches 2/5 and 5/5. I'm just quoting them
below.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
>From 80912f8e2bbbf0f81318c68e1bd5f69fc9537795 Mon Sep 17 00:00:00 2001
From: Sascha Hauer
Date: Thu, 12 Mar 2009 20:04:43 +0100
Subject: [PATCH] pcm990 baseboard: add camera bus width switch setting
Some Phytec cameras have a I2C GPIO expander which allows it to
switch between different sensor bus widths. This was previously
handled in the camera driver. Since handling of this switch
varies on several boards the cameras are used on, the board
support seems a better place to handle the switch
Signed-off-by: Sascha Hauer
Signed-off-by: Guennadi Liakhovetski
---
arch/arm/mach-pxa/pcm990-baseboard.c | 54 -
1 files changed, 45 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index f46698e..90a3990 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -380,14 +380,50 @@ static struct pca953x_platform_data pca9536_data = {
.gpio_base = NR_BUILTIN_GPIO + 1,
};
-static struct soc_camera_link iclink[] = {
- {
- .bus_id = 0, /* Must match with the camera ID above */
- .gpio = NR_BUILTIN_GPIO + 1,
- }, {
- .bus_id = 0, /* Must match with the camera ID above */
- .gpio = -ENXIO,
+static int gpio_bus_switch;
+
+static int pcm990_camera_set_bus_param(struct soc_camera_link *link,
+ unsigned long flags)
+{
+ if (gpio_bus_switch <= 0) {
+ if (flags == SOCAM_DATAWIDTH_10)
+ return 0;
+ else
+ return -EINVAL;
+ }
+
+ if (flags & SOCAM_DATAWIDTH_8)
+ gpio_set_value(gpio_bus_switch, 1);
+ else
+ gpio_set_value(gpio_bus_switch, 0);
+
+ return 0;
+}
+
+static unsigned long pcm990_camera_query_bus_param(struct soc_camera_link
*link)
+{
+ int ret;
+
+ if (!gpio_bus_switch) {
+ ret = gpio_request(NR_BUILTIN_GPIO + 1, "camera");
+ if (!ret) {
+ gpio_bus_switch = NR_BUILTIN_GPIO + 1;
+ gpio_direction_output(gpio_bus_switch, 0);
+ } else
+ gpio_bus_switch = -EINVAL;
}
+
+ if (gpio_bus_switch > 0)
+ return SOCAM_DATAWIDTH_8 | SOCAM_DATAWIDTH_10;
+ else
+ return SOCAM_DATAWIDTH_10;
+}
+
+static struct soc_camera_link iclink = {
+ .bus_id = 0, /* Must match with the camera ID above */
+ .gpio = NR_BUILTIN_GPIO + 1,
+ .query_bus_param = pcm990_camera_query_bus_param,
+ .set_bus_param = pcm990_camera_set_bus_param,
};
/* Board I2C devices. */
@@ -398,10 +434,10 @@ static struct i2c_board_info __initdata
pcm990_i2c_devices[] = {
.platform_data = &pca9536_data,
}, {
I2C_BOARD_INFO("mt9v022", 0x48),
- .platform_data = &iclink[0], /* With extender */
+ .platform_data = &iclink, /* With extender */
}, {
I2C_BOARD_INFO("mt9m001", 0x5d),
- .platform_data = &iclink[0], /* With extender */
+ .platform_data = &iclink, /* With extender */
},
};
#endif /* CONFIG_VIDEO_PXA27x ||CONFIG_VIDEO_PXA27x_MODULE */
--
1.5.4
>From 2d9b3eb219c391f9d626ae63835c8224ea8ef10e Mon Sep 17 00:00:00 2001
From: Sascha Hauer
Date: Thu, 12 Mar 2009 20:06:01 +0100
Subject: [PATCH] soc-camera: remove now unused gpio member of struct
soc_camera_link
Signed-off-by: Sascha Hauer
Signed-off-by: Guennadi Liakhovetski
---
arch/arm/mach-pxa/pcm990-baseboard.c |1 -
include/media/soc_camera.h |2 --
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index 90a3990..6112740 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -421,7 +421,6 @@ static unsigned long pcm990_camera_query_bus_param(struct
soc_camera_link *link)
static struct soc_camera_link iclink = {
.bus_id = 0, /* Must match with the camera ID above */
- .gpio = NR_BUILTIN_GPIO + 1,
.query_bus_param = pcm990_camera_query_bus_param,
.set_bus_param = pcm990_camera_set_bus_param,
};
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index b44fa09..3701368 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -95,8 +95,6 @@ struct soc_c
[PULL] gspca
Hi Mauro, Is there any problem with these changesets from http://linuxtv.org/hg/~jfrancois/v4l-dvb/ ? changeset: 10789:57bfe95f2ac1 gspca - most jpeg subdrivers: Change the JPEG header creation. changeset: 10790:2a1b8f88f331 gspca - most jpeg subdrivers: Have the JPEG quality settable. Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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] mt9t031 bugfix
On Fri, 6 Mar 2009, Philippe Rétornaz wrote: > - The video device is not allocated when mt9t031_init() is called, don't use > it in debug printk. > > - The clock polarity is inverted in mt9t031_set_bus_param(), use the correct > one. > > > Signed-off-by: Philippe Rétornaz > > --- > > diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c > index acc1fa9..d846110 100644 > --- a/drivers/media/video/mt9t031.c > +++ b/drivers/media/video/mt9t031.c > @@ -144,8 +144,6 @@ static int mt9t031_init(struct soc_camera_device *icd) > int ret; > > /* Disable chip output, synchronous option update */ > - dev_dbg(icd->vdev->parent, "%s\n", __func__); > - > ret = reg_write(icd, MT9T031_RESET, 1); > if (ret >= 0) > ret = reg_write(icd, MT9T031_RESET, 0); > @@ -186,9 +184,9 @@ static int mt9t031_set_bus_param(struct soc_camera_device > *icd, > return -EINVAL; > > if (flags & SOCAM_PCLK_SAMPLE_FALLING) > - reg_set(icd, MT9T031_PIXEL_CLOCK_CONTROL, 0x8000); > - else > reg_clear(icd, MT9T031_PIXEL_CLOCK_CONTROL, 0x8000); > + else > + reg_set(icd, MT9T031_PIXEL_CLOCK_CONTROL, 0x8000); Why do you think this is the correct one? According to the "Pin Description" Table (Table 3 on page 8 in my copy), indeed, it says Pixel clock: pixel data outputs are valid during falling edge of this clock. which _probably_ should refer to the default configuration, which is R10=0, i.e., non-inverted pixclk. In this case you are right. However, in Figure "Pixel Color Pattern Detail (Top Right Corner)" (Figure 5 on page 10) you see the first pixel green in a red row, and this is what I seem to be getting with the current driver, after applying your patch I'm getting a red pixel at the start. Are you basing your patch only on Table 3 or you verified it practically somehow? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.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] http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Thu, Mar 12, 2009 at 11:06 AM, Mauro Carvalho Chehab wrote: >> Yeah, printing "NULL" is bad and I can obviously fix that. The real >> reason for the addition of the "UNDEFINED" entry is I use that to >> detect if there are *any* analog inputs defined, which dictates >> whether the analog subsystem is initialized. Because the .input >> section is a member of the au0828_dev struct, and not a pointer, I >> needed some way to tell if it was populated with anything. > > if you attribute it to -1, the userspace calls will never set it to undefined. > You should take some care to avoid reading outside some array though. The problem is that I check for UNDEFINED so that the .input section of the au0828 board definition can be left uninitialized. Otherwise, I would have to add something like "num_inputs" to the board definition and worry about the value matching the actual number of inputs defined. >> I looked at the list and all of these issues are easy to fix, and I >> will do that tonight. > > Ok. > >> Please let me know if you have any other concerns (and what you want >> me to do regarding the VBI stuff), since I would like to avoid having >> do redo the tree again. > > No, just the above. Please, instead of redo the tree, just add some patches > fixing those issues. This allows me to review faster your series. Do you mean the checkpatch fixes should be done as a separate patch too? I assumed you wanted me to fix the original patch to pass make checkpatch. Is there a way to do the equivalent of "make checkpatch" against particular hg revisions or source files? I'm just trying to understand the best way to ensure that all of the issues actually get fixed. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Thu, 12 Mar 2009 10:24:02 -0400
Devin Heitmueller wrote:
> > hmm.. you are cleaning up f->reserved three times: at v4l2-ioctl, at the
> > memset(f) and at memset(f->reserved).
> >
> > You really wanted to make sure that you've cleaned it, don't you? ;)
>
> Well, I wanted to be *extra* sure. ;-) Yeah, I'll yank the duplicate code.
LOL
> > hmm...
> >
> > +#ifdef VBI_NOT_YET_WORKING
> > + .vidioc_g_fmt_vbi_cap = vidioc_g_fmt_vbi_cap,
> > + .vidioc_try_fmt_vbi_cap = vidioc_s_fmt_vbi_cap,
> > + .vidioc_s_fmt_vbi_cap = vidioc_s_fmt_vbi_cap,
> > +#endif
> >
> > I don't see any reference of this macro. If VBI is working, please cleanup
> > the
> > driver. Btw, your logic seems to be inverted on some cases. Why are you
> > adding
> > VBI macros, if it is not working yet?
> >
> > On the other hand, if VBI is broken we'll need some rules for removing vbi
> > code
> > from upstream, at gentree.pl.
>
> Here's the situation with VBI: I did all the groundwork, but it
> doesn't work yet. I am hoping on getting it working over the next
> couple of weeks. I believed that #ifdef'ing out the code was the
> safest way to ensure that the code does not get called, while not
> having to remove it from the tree entirely.
>
> If this is important to you that the code not appear in the source
> tree at all until it works entirely, then I will remove the VBI code
> entirely.
Hmm... So, I understood just the opposite ;)
you wrote "if VBI_IS_NOT_WORKING", when you should have written "if
VBI_IS_WORKING".
Just rename it. I'll add it at gentree.pl to remove this symbol.
>
> > +enum au0828_itype {
> > + AU0828_VMUX_UNDEFINED = 0,
> > + AU0828_VMUX_COMPOSITE,
> > + AU0828_VMUX_SVIDEO,
> > + AU0828_VMUX_CABLE,
> > + AU0828_VMUX_TELEVISION,
> > + AU0828_VMUX_DVB,
> > + AU0828_VMUX_DEBUG
> > +};
> >
> > ...
> >
> > +static int vidioc_enum_input(struct file *file, void *priv,
> > + struct v4l2_input *input)
> > +{
> > + struct au0828_fh *fh = priv;
> > + struct au0828_dev *dev = fh->dev;
> > + unsigned int tmp;
> > +
> > + static const char *inames[] = {
> > + [AU0828_VMUX_COMPOSITE] = "Composite",
> > + [AU0828_VMUX_SVIDEO] = "S-Video",
> > + [AU0828_VMUX_CABLE] = "Cable TV",
> > + [AU0828_VMUX_TELEVISION] = "Television",
> > + [AU0828_VMUX_DVB] = "DVB",
> > + [AU0828_VMUX_DEBUG] = "tv debug"
> > + };
> >
> > If the user enumerates an entry marked as UNDEFINED, it will print NULL. Is
> > it
> > what you really wanted? I would, instead, assign another value for
> > AU0828_VMUX_UNDEFINED, like -1.
>
> Yeah, printing "NULL" is bad and I can obviously fix that. The real
> reason for the addition of the "UNDEFINED" entry is I use that to
> detect if there are *any* analog inputs defined, which dictates
> whether the analog subsystem is initialized. Because the .input
> section is a member of the au0828_dev struct, and not a pointer, I
> needed some way to tell if it was populated with anything.
if you attribute it to -1, the userspace calls will never set it to undefined.
You should take some care to avoid reading outside some array though.
> > Ah, finally, there are a number of CodingStyle fun. I've enclosed what it
> > got,
> > from the final code. Please, always use make checkpatch before committing a
> > patch.
>
> I rather foolishly assumed that "make commit" ran "make checkpatch".
It runs, and outputs its result at the commit comments.
> I looked at the list and all of these issues are easy to fix, and I
> will do that tonight.
Ok.
> Please let me know if you have any other concerns (and what you want
> me to do regarding the VBI stuff), since I would like to avoid having
> do redo the tree again.
No, just the above. Please, instead of redo the tree, just add some patches
fixing those issues. This allows me to review faster your series.
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 1/1] siano: add high level SDIO interface driver for SMS based cards
Mauro and all, I submitted 3 patches, two modifications for the SDIO generic stack, and one new high level SDIO interface driver for Siano based devices. This concludes SDIO related changes, with one exception, which is explained below. However this explanation requires some overview about Siano's module inner architecture. The Siano kernel module architecture is composed from: 1) SMS "Core" - This main component holds all Siano's host-device protocol logic, and any logic needed to bind the other module's components, interface and adapters. 2) Interfaces drivers (SDIO, USB, TS, SPP, HIF, ...) - At lease one interface driver must be compiled and linked, but multiple interfaces are supported. This feature enables platforms like the Asus UMPC series to use SMS based USB dongle and SMS based SDIO dongle simultaneously. 3) Client adapters (DVB API v3, DVB API v5, others) - Similar to the interfaces drivers, at least one client adapter must be linked, but multiple are supported. 4) SMS "cards" - This component contains any hardware target specific information (like LEDs locations, antenna configuration, alternative firmware names, and much more), leaving any other component target-independent. And now back to SDIO True all SDIO related sources files are now updated (after these 3 patches), but since the build system (Kconfig & Makefile) and "smscore" component are yet to be updated, the SDIO interface driver can not be linked into the module. The option to link and use the SDIO interface driver, will be available after those files will be updated (hope it'll happen shortly). One question: Should I continue submit patches (I have them ready), or should I wait till the 3 previous submission will be reviewed and committed? Regards, Uri -- 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://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
Hello Mauro,
Thank you for reviewing. See comments inline.
On Thu, Mar 12, 2009 at 6:06 AM, Mauro Carvalho Chehab
wrote:
> +static int vidioc_querycap(struct file *file, void *priv,
> + struct v4l2_capability *cap)
> +{
> + struct au0828_fh *fh = priv;
> + struct au0828_dev *dev = fh->dev;
> +
> + memset(cap, 0, sizeof(*cap));
>
> Please remove all memsets for input/output arguments on vidioc_foo at
> au0828-video.c.
> The V4L2 core warrants that the non-input fields are zeroed.
Ok.
> +static int vidioc_enum_fmt_vid_cap(struct file *file, void *priv,
> + struct v4l2_fmtdesc *f)
> +{
> + if(f->index)
> + return -EINVAL;
> +
> + memset(f, 0, sizeof(*f));
> + f->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> + strcpy(f->description, "Packed YUV2");
> +
> + f->flags = 0;
> + f->pixelformat = V4L2_PIX_FMT_UYVY;
> +
> + memset(f->reserved, 0, sizeof(f->reserved));
> + return 0;
> +}
>
> hmm.. you are cleaning up f->reserved three times: at v4l2-ioctl, at the
> memset(f) and at memset(f->reserved).
>
> You really wanted to make sure that you've cleaned it, don't you? ;)
Well, I wanted to be *extra* sure. ;-) Yeah, I'll yank the duplicate code.
> hmm...
>
> +#ifdef VBI_NOT_YET_WORKING
> + .vidioc_g_fmt_vbi_cap = vidioc_g_fmt_vbi_cap,
> + .vidioc_try_fmt_vbi_cap = vidioc_s_fmt_vbi_cap,
> + .vidioc_s_fmt_vbi_cap = vidioc_s_fmt_vbi_cap,
> +#endif
>
> I don't see any reference of this macro. If VBI is working, please cleanup the
> driver. Btw, your logic seems to be inverted on some cases. Why are you adding
> VBI macros, if it is not working yet?
>
> On the other hand, if VBI is broken we'll need some rules for removing vbi
> code
> from upstream, at gentree.pl.
Here's the situation with VBI: I did all the groundwork, but it
doesn't work yet. I am hoping on getting it working over the next
couple of weeks. I believed that #ifdef'ing out the code was the
safest way to ensure that the code does not get called, while not
having to remove it from the tree entirely.
If this is important to you that the code not appear in the source
tree at all until it works entirely, then I will remove the VBI code
entirely.
> +enum au0828_itype {
> + AU0828_VMUX_UNDEFINED = 0,
> + AU0828_VMUX_COMPOSITE,
> + AU0828_VMUX_SVIDEO,
> + AU0828_VMUX_CABLE,
> + AU0828_VMUX_TELEVISION,
> + AU0828_VMUX_DVB,
> + AU0828_VMUX_DEBUG
> +};
>
> ...
>
> +static int vidioc_enum_input(struct file *file, void *priv,
> + struct v4l2_input *input)
> +{
> + struct au0828_fh *fh = priv;
> + struct au0828_dev *dev = fh->dev;
> + unsigned int tmp;
> +
> + static const char *inames[] = {
> + [AU0828_VMUX_COMPOSITE] = "Composite",
> + [AU0828_VMUX_SVIDEO] = "S-Video",
> + [AU0828_VMUX_CABLE] = "Cable TV",
> + [AU0828_VMUX_TELEVISION] = "Television",
> + [AU0828_VMUX_DVB] = "DVB",
> + [AU0828_VMUX_DEBUG] = "tv debug"
> + };
>
> If the user enumerates an entry marked as UNDEFINED, it will print NULL. Is it
> what you really wanted? I would, instead, assign another value for
> AU0828_VMUX_UNDEFINED, like -1.
Yeah, printing "NULL" is bad and I can obviously fix that. The real
reason for the addition of the "UNDEFINED" entry is I use that to
detect if there are *any* analog inputs defined, which dictates
whether the analog subsystem is initialized. Because the .input
section is a member of the au0828_dev struct, and not a pointer, I
needed some way to tell if it was populated with anything.
> + switch(AUVI_INPUT(index).type) {
> + case AU0828_VMUX_SVIDEO:
> + {
> + dev->input_type = AU0828_VMUX_SVIDEO;
> + break;
> + }
> + case AU0828_VMUX_COMPOSITE:
> + {
> + dev->input_type = AU0828_VMUX_COMPOSITE;
> + break;
> + }
> + case AU0828_VMUX_TELEVISION:
> + {
> + dev->input_type = AU0828_VMUX_TELEVISION;
> + break;
> + }
> + default:
> + ;
> + }
>
> You don't need all those braces.
I will remove the braces.
>
> Also, the default rule is missing. I don't see why you would preserve the same
> dev->input_type if the user selects an undefined entry, or a DVB or a debug.
I will fix that.
> Ah, finally, there are a number of CodingStyle fun. I've enclosed what it got,
> from the final code. Please, always use make checkpatch before committing a
> patch.
I rather foolishly assumed that "make commit" ran "make checkpatch".
I looked at the list and all of these issues are easy to fix, and I
will do that tonight.
Please let me know if you have any other concerns (and what you want
me to do regarding the VBI stuff), since I would like to a
Re: [PULL] http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
> On Thu, Mar 12, 2009 at 5:19 AM, Hans Verkuil wrote: >> Hi Devin, >> >> Can you also do the last bit of the v4l2_device/subdev conversion by >> actually using the subdev callbacks (replace au0828_call_i2c_clients >> with >> v4l2_device_call_all), removing attach_inform and detach_inform (already >> deprecated in 2.6.29) and in au8522_decoder.c replacing >> v4l2-i2c-drv-legacy.h by v4l2-i2c-drv.h and removing the au8522_command. >> >> Basically, when you compile against 2.6.29 you shouldn't see any >> 'deprecated' warnings! >> >> I also suggest renaming au8522_decoder.c to just au8522.c, like all the >> other i2c modules. > > Hello Hans, > > I am certainly in favor of what you have proposed. However, I would > like to do it as an incremental improvement over what the series > currently contains. > > Any chance you can allow the current series to go in as-is, and I can > work on this over the next couple of days (as I will need to retest > everything)? The patch series has gotten kind of unwieldy. No problem. It's fairly trivial to do since you're 90% there already :-) 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 0/5] V2: soc-camera: setting the buswidth of camera sensors
On Thu, Mar 12, 2009 at 02:31:17PM +0100, Guennadi Liakhovetski wrote: > On Thu, 12 Mar 2009, Sascha Hauer wrote: > > > Take 2: I hope I addressed all comments I receive in the first round. > > > > The following patches change the handling of the bus width > > for camera sensors so that a board can overwrite a sensors > > native bus width > > > > Sascha Hauer (5): > > soc-camera: add board hook to specify the buswidth for camera sensors > > pcm990 baseboard: add camera bus width switch setting > > mt9m001: allow setting of bus width from board code > > mt9v022: allow setting of bus width from board code > > soc-camera: remove now unused gpio member of struct soc_camera_link > > Ok, the rest look good to me. So, after you fix or explain 2/5 I'll be > pulling them. If by pulling you mean 'git pull' you can do it here: git://git.pengutronix.de/git/sha/linux-2.6.git soc-camera-bus-switch Thanks Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] pcm990 baseboard: add camera bus width switch setting
On Thu, Mar 12, 2009 at 02:12:09PM +0100, Guennadi Liakhovetski wrote:
> On Thu, 12 Mar 2009, Sascha Hauer wrote:
>
> > Some Phytec cameras have a I2C GPIO expander which allows it to
> > switch between different sensor bus widths. This was previously
> > handled in the camera driver. Since handling of this switch
> > varies on several boards the cameras are used on, the board
> > support seems a better place to handle the switch
> >
> > Signed-off-by: Sascha Hauer
> > ---
> > arch/arm/mach-pxa/pcm990-baseboard.c | 49
> > +++--
> > 1 files changed, 40 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
> > b/arch/arm/mach-pxa/pcm990-baseboard.c
> > index 34841c7..8b01565 100644
> > --- a/arch/arm/mach-pxa/pcm990-baseboard.c
> > +++ b/arch/arm/mach-pxa/pcm990-baseboard.c
> > @@ -381,14 +381,45 @@ static struct pca953x_platform_data pca9536_data = {
> > .gpio_base = NR_BUILTIN_GPIO + 1,
> > };
> >
> > -static struct soc_camera_link iclink[] = {
> > - {
> > - .bus_id = 0, /* Must match with the camera ID above */
> > - .gpio = NR_BUILTIN_GPIO + 1,
> > - }, {
> > - .bus_id = 0, /* Must match with the camera ID above */
> > - .gpio = -ENXIO,
> > +static int gpio_bus_switch;
> > +
> > +static int pcm990_camera_set_bus_param(struct soc_camera_link *link,
> > + unsigned long flags)
> > +{
> > + if (gpio_bus_switch <= 0)
> > + return 0;
>
> Are you really sure you don't want to return an error here? In
> query_bus_param() below, if you fail to get the GPIO, you set
> gpio_bus_switch to -EINVAL and return only 10 bit. Now if a buggy host
> driver still requests 8 bits, mt9m001 will call ->set_bus_param and you
> will happily return 0...
>
Of course there are no buggy host drivers ;)
Ok, changed it to support only ten bit without gpio switch and return
-EINVAL for any other width.
Sasche
>From 58485f136579273d4da41d65974ce6ed02ba877a Mon Sep 17 00:00:00 2001
From: Sascha Hauer
Date: Tue, 10 Mar 2009 16:45:58 +0100
Subject: [PATCH 2/5] pcm990 baseboard: add camera bus width switch setting
Some Phytec cameras have a I2C GPIO expander which allows it to
switch between different sensor bus widths. This was previously
handled in the camera driver. Since handling of this switch
varies on several boards the cameras are used on, the board
support seems a better place to handle the switch
Signed-off-by: Sascha Hauer
---
arch/arm/mach-pxa/pcm990-baseboard.c | 53 --
1 files changed, 44 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index 34841c7..fd8f786 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -381,14 +381,49 @@ static struct pca953x_platform_data pca9536_data = {
.gpio_base = NR_BUILTIN_GPIO + 1,
};
-static struct soc_camera_link iclink[] = {
- {
- .bus_id = 0, /* Must match with the camera ID above */
- .gpio = NR_BUILTIN_GPIO + 1,
- }, {
- .bus_id = 0, /* Must match with the camera ID above */
- .gpio = -ENXIO,
+static int gpio_bus_switch;
+
+static int pcm990_camera_set_bus_param(struct soc_camera_link *link,
+ unsigned long flags)
+{
+ if (gpio_bus_switch <= 0) {
+ if (flags == SOCAM_DATAWIDTH_10)
+ return 0;
+ else
+ return -EINVAL;
+ }
+
+ if (flags & SOCAM_DATAWIDTH_8)
+ gpio_set_value(gpio_bus_switch, 1);
+ else
+ gpio_set_value(gpio_bus_switch, 0);
+
+ return 0;
+}
+
+static unsigned long pcm990_camera_query_bus_param(struct soc_camera_link
*link)
+{
+ int ret;
+
+ if (!gpio_bus_switch) {
+ ret = gpio_request(NR_BUILTIN_GPIO + 1, "camera");
+ if (!ret) {
+ gpio_bus_switch = NR_BUILTIN_GPIO + 1;
+ gpio_direction_output(gpio_bus_switch, 0);
+ } else
+ gpio_bus_switch = -EINVAL;
}
+
+ if (gpio_bus_switch > 0)
+ return SOCAM_DATAWIDTH_8 | SOCAM_DATAWIDTH_10;
+ else
+ return SOCAM_DATAWIDTH_10;
+}
+
+static struct soc_camera_link iclink = {
+ .bus_id = 0, /* Must match with the camera ID above */
+ .query_bus_param = pcm990_camera_query_bus_param,
+ .set_bus_param = pcm990_camera_set_bus_param,
};
/* Board I2C devices. */
@@ -399,10 +434,10 @@ static struct i2c_board_info __initdata
pcm990_i2c_devices[] = {
.platform_data = &pca9536_data,
}, {
I2C_BOARD_INFO("mt9v022", 0x48),
- .platform_data = &iclink[0], /* With extender */
+ .platform_data = &iclink, /* With extender */
}, {
I2C_BOAR
Re: [PULL] http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Thu, Mar 12, 2009 at 5:19 AM, Hans Verkuil wrote: > Hi Devin, > > Can you also do the last bit of the v4l2_device/subdev conversion by > actually using the subdev callbacks (replace au0828_call_i2c_clients with > v4l2_device_call_all), removing attach_inform and detach_inform (already > deprecated in 2.6.29) and in au8522_decoder.c replacing > v4l2-i2c-drv-legacy.h by v4l2-i2c-drv.h and removing the au8522_command. > > Basically, when you compile against 2.6.29 you shouldn't see any > 'deprecated' warnings! > > I also suggest renaming au8522_decoder.c to just au8522.c, like all the > other i2c modules. Hello Hans, I am certainly in favor of what you have proposed. However, I would like to do it as an incremental improvement over what the series currently contains. Any chance you can allow the current series to go in as-is, and I can work on this over the next couple of days (as I will need to retest everything)? The patch series has gotten kind of unwieldy. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Thu, Mar 12, 2009 at 4:54 AM, Mauro Carvalho Chehab wrote: > Hi Devin, > > There's a bug on your patch series: see this: > > Those are the locations of au8522 files at Kernel's tree: > drivers/media/dvb/frontends/au8522.h > drivers/media/dvb/frontends/au8522_dig.c > drivers/media/dvb/frontends/au8522_priv.h > drivers/media/video/au8522_decoder.c > > And those are the Makefile rules for au8522.h on > drivers/media/dvb/frontends/Makefile: > > au8522-objs = au8522_dig.o au8522_decoder.o > obj-$(CONFIG_DVB_AU8522) += au8522.o > > When you're compiling the out-of-tree version, everything works OK, but, for > in-tree compilation, au8522_decoder won't be compiled, since the file will be > in the wrong dir. > > If I'm understanding well, this chip has two functions: it is a dvb frontend > and an analog video/audio demodulator, right? > > One solution would be to have all those files in the same directory. However, > au8522_decoder doesn't fit well on dvb/frontends. It is also not a tuner, > otherwise common/tuners would be another better place. > > Another alternative would be to create two kconfig rules (and two separate > modules), being one for au8522_decoder and another for the frontend, since > they > are, in fact, two different things. > > I suspect,however, that compiling just one or another would break compilation. > So, we need to create some sort of rules that will warrant that both modules > will be compiled at the same time. This is not an easy task, since we cannot > add "depends on", since frontends are compiled by using "select". So, we will > need to re-design the Kconfig rules to use depends on instead of select (well, > this is something good, anyway, since the usage of "select" is something that > should be avoided, according with Kbuild docs). > > I'll keep reviewing the patch series. Maybe I'll merge it, but, in this case, > I'll need to blacklist the module until we found a solution, or find a way to > allow my -git trees to compile. > > Cheers, > Mauro > Hello Mauro, Both files are required, as they share certain functions (such as the i2c transfer functions). Also, they share a common state mechanism, which is why both files end up in the same .ko file. This case is a little unique since it is the first case where we have a single chip that acts as a digital demod, an analog demod, and an analog video/audio decoder. I can certainly put the au8522_decoder.c into dvb/frontends even though this probably violates some rule about analog stuff being in the DVB section of the tree. Would that resolve your concern? I really don't want to make redesigning the KConfig rules a prerequisite to getting this rather large patch series merged. I would suggest we do what is required to get the code in (such as moving the _decoder.c to frontends), and then we can tune the solution to be something more optimal in terms of how the tree is structured. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
> On Thu, Mar 12, 2009 at 5:19 AM, Hans Verkuil wrote: >> >>> On Wed, 11 Mar 2009 11:25:20 -0400 >>> Devin Heitmueller wrote: >>> Hello Mauro, Please pull from: http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2 for the following: xc5000: fix bug for hybrid xc5000 devices with IF other than 5380 au8522: rename the au8522.c source file au8522: move shared state and common functions into a separate header files au8522: fix register read/write high bits au8522: power down the digital demod when not in use au8522: make use of hybrid framework so analog/digital demod can share state au8522: add support for analog side of demodulator au0828: add support for analog functionality in bridge au0828: workaround a bug in the au0828 i2c handling au0828: add analog profile for the HVR-850 au8522: add mutex protecting use of hybrid state au0828: Rework the way the analog video binding occurs tveeprom: add the xc5000 tuner to the tveeprom definition au0828: advertise only NTSC-M (as opposed to all NTSC standards) au0828: disable VBI code since it doesn't yet work au0828: fix i2c enumeration bug au0828: make register debug lines easier to read au0828: make g_chip_ident call work properly au0828: properly handle missing analog USB endpoint au0828: properly handle non-existent analog inputs au0828: fix panic on disconnect if analog initialization failed au0828: Convert to use v4l2_device/subdev framework >> >> Hi Devin, >> >> Can you also do the last bit of the v4l2_device/subdev conversion by >> actually using the subdev callbacks (replace au0828_call_i2c_clients >> with >> v4l2_device_call_all), removing attach_inform and detach_inform (already >> deprecated in 2.6.29) and in au8522_decoder.c replacing >> v4l2-i2c-drv-legacy.h by v4l2-i2c-drv.h and removing the au8522_command. >> >> Basically, when you compile against 2.6.29 you shouldn't see any >> 'deprecated' warnings! >> >> I also suggest renaming au8522_decoder.c to just au8522.c, like all the >> other i2c modules. > > > Hans, > > There was already a au8522.c in the master branch before Devin's > patches -- au8522.c is located in drivers/media/dvb/frontends -- it is > an ATSC/QAM demodulator modulator. Devin had renamed au8522.c to > au8522_dig.c , so that it can be built with au8522_decoder.c into a > single module. > > It is important that this remain a single module, because there is > state being shared between the analog and digitial sides of this > device. > > This is a hybrid demodulator, the first of it's kind within our codebase. Ah, thank you for the explanation. No need for a rename then :-) Thanks, 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
[PATCH 1/1] siano: add high level SDIO interface driver for SMS based cards
# HG changeset patch
# User Uri Shkolnik
# Date 1236865697 -7200
# Node ID 7352ee1288f651d19d58c7bb479a98f070ad98e6
# Parent 3392722cc5b687586c4d898b73050ab6e59bf401
siano: add high level SDIO interface driver for SMS based cards
From: Uri Shkolnik
This patch provides SDIO interface driver for
SMS (Siano Mobile Silicon) based devices.
The patch includes SMS high level SDIO driver and
requires patching the kernel SDIO stack,
those stack patches had been provided previously.
I would like to thank Pierre Ossman, MMC maintainer,
who wrote this driver.
Priority: normal
Signed-off-by: Pierre Ossman
Signed-off-by: Uri Shkolnik
diff -r 3392722cc5b6 -r 7352ee1288f6 linux/drivers/media/dvb/siano/smssdio.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/siano/smssdio.c Thu Mar 12 15:48:17 2009 +0200
@@ -0,0 +1,356 @@
+/*
+ * smssdio.c - Siano 1xxx SDIO interface driver
+ *
+ * Copyright 2008 Pierre Ossman
+ *
+ * Based on code by Siano Mobile Silicon, Inc.,
+ * Copyright (C) 2006-2008, Uri Shkolnik
+ *
+ * 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 hardware is a bit odd in that all transfers should be done
+ * to/from the SMSSDIO_DATA register, yet the "increase address" bit
+ * always needs to be set.
+ *
+ * Also, buffers from the card are always aligned to 128 byte
+ * boundaries.
+ */
+
+/*
+ * General cleanup notes:
+ *
+ * - only typedefs should be name *_t
+ *
+ * - use ERR_PTR and friends for smscore_register_device()
+ *
+ * - smscore_getbuffer should zero fields
+ *
+ * Fix stop command
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "smscoreapi.h"
+#include "sms-cards.h"
+
+/* Registers */
+
+#define SMSSDIO_DATA 0x00
+#define SMSSDIO_INT0x04
+
+static const struct sdio_device_id smssdio_ids[] = {
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_STELLAR),
+.driver_data = SMS1XXX_BOARD_SIANO_STELLAR},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_NOVA_A0),
+.driver_data = SMS1XXX_BOARD_SIANO_NOVA_A},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_NOVA_B0),
+.driver_data = SMS1XXX_BOARD_SIANO_NOVA_B},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_VEGA_A0),
+.driver_data = SMS1XXX_BOARD_SIANO_VEGA},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_VENICE),
+.driver_data = SMS1XXX_BOARD_SIANO_VEGA},
+ { /* end: all zeroes */ },
+};
+
+MODULE_DEVICE_TABLE(sdio, smssdio_ids);
+
+struct smssdio_device {
+ struct sdio_func *func;
+
+ struct smscore_device_t *coredev;
+
+ struct smscore_buffer_t *split_cb;
+};
+
+/***/
+/* Siano core callbacks*/
+/***/
+
+static int smssdio_sendrequest(void *context, void *buffer, size_t size)
+{
+ int ret;
+ struct smssdio_device *smsdev;
+
+ smsdev = context;
+
+ sdio_claim_host(smsdev->func);
+
+ while (size >= smsdev->func->cur_blksize) {
+ ret = sdio_write_blocks(smsdev->func, SMSSDIO_DATA, buffer, 1);
+ if (ret)
+ goto out;
+
+ buffer += smsdev->func->cur_blksize;
+ size -= smsdev->func->cur_blksize;
+ }
+
+ if (size) {
+ ret = sdio_write_bytes(smsdev->func, SMSSDIO_DATA,
+ buffer, size);
+ if (ret)
+ goto out;
+ }
+
+out:
+ sdio_release_host(smsdev->func);
+
+ return ret;
+}
+
+/***/
+/* SDIO callbacks */
+/***/
+
+static void smssdio_interrupt(struct sdio_func *func)
+{
+ int ret, isr;
+
+ struct smssdio_device *smsdev;
+ struct smscore_buffer_t *cb;
+ struct SmsMsgHdr_ST *hdr;
+ size_t size;
+
+ smsdev = sdio_get_drvdata(func);
+
+ /*
+* The interrupt register has no defined meaning. It is just
+* a way of turning of the level triggered interrupt.
+*/
+ isr = sdio_readb(func, SMSSDIO_INT, &ret);
+ if (ret) {
+ dev_err(&smsdev->func->dev,
+ "Unable to read interrupt register!\n");
+ return;
+ }
+
+ if (smsdev->split_cb == NULL) {
+ cb = smscore_getbuffer(smsdev->coredev);
+ if (!cb) {
+ dev_err(&smsdev->func->dev,
+ "Unable to
Re: [PULL] http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Thu, Mar 12, 2009 at 4:54 AM, Mauro Carvalho Chehab wrote: > On Wed, 11 Mar 2009 11:25:20 -0400 > Devin Heitmueller wrote: > >> Hello Mauro, >> >> Please pull from: >> >> http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2 >> >> for the following: >> >> xc5000: fix bug for hybrid xc5000 devices with IF other than 5380 >> au8522: rename the au8522.c source file >> au8522: move shared state and common functions into a separate header files >> au8522: fix register read/write high bits >> au8522: power down the digital demod when not in use >> au8522: make use of hybrid framework so analog/digital demod can share state >> au8522: add support for analog side of demodulator >> au0828: add support for analog functionality in bridge >> au0828: workaround a bug in the au0828 i2c handling >> au0828: add analog profile for the HVR-850 >> au8522: add mutex protecting use of hybrid state >> au0828: Rework the way the analog video binding occurs >> tveeprom: add the xc5000 tuner to the tveeprom definition >> au0828: advertise only NTSC-M (as opposed to all NTSC standards) >> au0828: disable VBI code since it doesn't yet work >> au0828: fix i2c enumeration bug >> au0828: make register debug lines easier to read >> au0828: make g_chip_ident call work properly >> au0828: properly handle missing analog USB endpoint >> au0828: properly handle non-existent analog inputs >> au0828: fix panic on disconnect if analog initialization failed >> au0828: Convert to use v4l2_device/subdev framework >> >> Cheers, >> >> Devin >> > > > Hi Devin, > > There's a bug on your patch series: see this: > > Those are the locations of au8522 files at Kernel's tree: > drivers/media/dvb/frontends/au8522.h > drivers/media/dvb/frontends/au8522_dig.c > drivers/media/dvb/frontends/au8522_priv.h > drivers/media/video/au8522_decoder.c > > And those are the Makefile rules for au8522.h on > drivers/media/dvb/frontends/Makefile: > > au8522-objs = au8522_dig.o au8522_decoder.o > obj-$(CONFIG_DVB_AU8522) += au8522.o > > When you're compiling the out-of-tree version, everything works OK, but, for > in-tree compilation, au8522_decoder won't be compiled, since the file will be > in the wrong dir. > > If I'm understanding well, this chip has two functions: it is a dvb frontend > and an analog video/audio demodulator, right? > > One solution would be to have all those files in the same directory. However, > au8522_decoder doesn't fit well on dvb/frontends. It is also not a tuner, > otherwise common/tuners would be another better place. > > Another alternative would be to create two kconfig rules (and two separate > modules), being one for au8522_decoder and another for the frontend, since > they > are, in fact, two different things. > > I suspect,however, that compiling just one or another would break compilation. > So, we need to create some sort of rules that will warrant that both modules > will be compiled at the same time. This is not an easy task, since we cannot > add "depends on", since frontends are compiled by using "select". So, we will > need to re-design the Kconfig rules to use depends on instead of select (well, > this is something good, anyway, since the usage of "select" is something that > should be avoided, according with Kbuild docs). > > I'll keep reviewing the patch series. Maybe I'll merge it, but, in this case, > I'll need to blacklist the module until we found a solution, or find a way to > allow my -git trees to compile. Mauro, I agree that the au8522* sources can be moved to a common area. For now, however, I believe that we should move au8522_decoder.c into the frontends/ directory, so that these patches can be merged for the time being. It is important that there is a single au8522 module, because the state needs to be shared and managed appropriately between the analog and digital sides of the device. This is just like a hybrid tuner, but its a hybrid demodulator instead. Currently, au8522 is only used by the au0828 module -- I don't forsee any *other* drivers using this au8522 module for any purpose in the near future. Since digital TV is the main function of the au0828 / au8522 drivers, I don't think there is any harm to move the analog part of the au8522 driver into media/dvb/frontends for now, so that the au8522 module can be built properly. We should revisit the idea of a media/common/demod directory (or something similar) as a separate effort after merge. Is that ok with everybody involved? Regards, Mike -- 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://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Thu, Mar 12, 2009 at 5:19 AM, Hans Verkuil wrote: > >> On Wed, 11 Mar 2009 11:25:20 -0400 >> Devin Heitmueller wrote: >> >>> Hello Mauro, >>> >>> Please pull from: >>> >>> http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2 >>> >>> for the following: >>> >>> xc5000: fix bug for hybrid xc5000 devices with IF other than 5380 >>> au8522: rename the au8522.c source file >>> au8522: move shared state and common functions into a separate header >>> files >>> au8522: fix register read/write high bits >>> au8522: power down the digital demod when not in use >>> au8522: make use of hybrid framework so analog/digital demod can share >>> state >>> au8522: add support for analog side of demodulator >>> au0828: add support for analog functionality in bridge >>> au0828: workaround a bug in the au0828 i2c handling >>> au0828: add analog profile for the HVR-850 >>> au8522: add mutex protecting use of hybrid state >>> au0828: Rework the way the analog video binding occurs >>> tveeprom: add the xc5000 tuner to the tveeprom definition >>> au0828: advertise only NTSC-M (as opposed to all NTSC standards) >>> au0828: disable VBI code since it doesn't yet work >>> au0828: fix i2c enumeration bug >>> au0828: make register debug lines easier to read >>> au0828: make g_chip_ident call work properly >>> au0828: properly handle missing analog USB endpoint >>> au0828: properly handle non-existent analog inputs >>> au0828: fix panic on disconnect if analog initialization failed >>> au0828: Convert to use v4l2_device/subdev framework > > Hi Devin, > > Can you also do the last bit of the v4l2_device/subdev conversion by > actually using the subdev callbacks (replace au0828_call_i2c_clients with > v4l2_device_call_all), removing attach_inform and detach_inform (already > deprecated in 2.6.29) and in au8522_decoder.c replacing > v4l2-i2c-drv-legacy.h by v4l2-i2c-drv.h and removing the au8522_command. > > Basically, when you compile against 2.6.29 you shouldn't see any > 'deprecated' warnings! > > I also suggest renaming au8522_decoder.c to just au8522.c, like all the > other i2c modules. Hans, There was already a au8522.c in the master branch before Devin's patches -- au8522.c is located in drivers/media/dvb/frontends -- it is an ATSC/QAM demodulator modulator. Devin had renamed au8522.c to au8522_dig.c , so that it can be built with au8522_decoder.c into a single module. It is important that this remain a single module, because there is state being shared between the analog and digitial sides of this device. This is a hybrid demodulator, the first of it's kind within our codebase. Regards, Mike -- 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 0/5] V2: soc-camera: setting the buswidth of camera sensors
On Thu, 12 Mar 2009, Sascha Hauer wrote: > Take 2: I hope I addressed all comments I receive in the first round. > > The following patches change the handling of the bus width > for camera sensors so that a board can overwrite a sensors > native bus width > > Sascha Hauer (5): > soc-camera: add board hook to specify the buswidth for camera sensors > pcm990 baseboard: add camera bus width switch setting > mt9m001: allow setting of bus width from board code > mt9v022: allow setting of bus width from board code > soc-camera: remove now unused gpio member of struct soc_camera_link Ok, the rest look good to me. So, after you fix or explain 2/5 I'll be pulling them. > > arch/arm/mach-pxa/pcm990-baseboard.c | 49 ++-- > drivers/media/video/Kconfig | 14 > drivers/media/video/mt9m001.c| 143 > ++ > drivers/media/video/mt9v022.c| 141 ++--- > include/media/soc_camera.h |9 ++- > 5 files changed, 129 insertions(+), 227 deletions(-) > Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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: null pointer access in error path of lgdt3305 driver
On Thu, Mar 12, 2009 at 7:04 AM, Matthias Schwarzott wrote: > Hi Michael! > > Looking at your new lgdt3305 driver, I noticed that the error path of > lgdt3305_attach, that is also jumped to kzalloc errors, sets > state->frontend.demodulator_priv to NULL. > > That will oops in case state is NULL. So you either need two goto labels for > failures or just return in case kzalloc fails. Patches welcomed. :-) Regards, David Ellingsworth -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linuxtv-commits] [hg:v4l-dvb] Add cx231xx USB driver
On Thu, 12 Mar 2009 12:14:22 +0100 (CET) "Hans Verkuil" wrote: > Mauro, you did not answer the question why this driver was just merged > without going through a public review? If I'd seen it beforehand I'd have > worked together with Sri to get it fixed first. I don't expect him to know > about this, but I didn't even get a chance to discuss it and help with it. > Everyone else has to go through the normal review channels, but apparently > this was just fast-tracked and merged. That's not the way to do it. It were added one week ago on a temporary public tree, at linuxtv. > Please back out this driver, put it in a separate tree and let me 1) > review this driver first, and 2) help Sri implementing the > v4l2_device/v4l2_subdev stuff. It is better to review it at the tree. I won't merge it upstream until the remaining bugs would be fixed. Until then, it will wait on my staging -git tree (the pending tree). > > First of all, except for ivtv drivers, the first conversion to the new > > model > > occurred just few weeks ago. The new model will bring some gains, but this > > shouldn't stop the merge of the drivers whose development started before > > we > > port the drivers used as example by the developer. > > > > This is a new model, and we should give people some time to adapt to it. > > This > > is the way we worked in the past and it is the way we should keep working. > > It's not a new model. It is. The first changeset were committed on Nov, 30, and the last internal API changes, according with the docs, happened on Feb, 14. So, if we don't touch on it, the first stable version of the framework will be available upstream on 2.6.30. If we keep it stable during 2.6.30, convert the drivers merged on 2.6.30 to the new framework, and mark the legacy approach as a feature to be removed on a patch applied at 2.6.30, then we can remove the previous support for 2.6.31. $ hg log linux/Documentation/video4linux/v4l2-framework.txt changeset: 10648:e471b963bef6 parent: 10640:4f6c3f9efa58 parent: 10647:63256532f5a7 user:Mauro Carvalho Chehab date:Tue Feb 17 23:44:45 2009 -0300 summary: merge: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb changeset: 10644:44b5df81ab02 user:Hans Verkuil date:Sat Feb 14 16:00:53 2009 +0100 summary: v4l2-subdev: rename dev field to v4l2_dev changeset: 10643:9eb2f6220a18 user:Hans Verkuil date:Sat Feb 14 15:54:23 2009 +0100 summary: v4l2-device: allow a NULL parent device when registering. changeset: 10573:b73e7bdad8c4 user:Mauro Carvalho Chehab date:Mon Feb 16 15:54:29 2009 -0300 summary: v4l2-framework.txt: Whitespace clenups changeset: 10571:12a10f808bfd user:Mauro Carvalho Chehab date:Sat Feb 14 08:51:28 2009 -0200 summary: v4l2-framework.txt: Fixes the videobuf init functions changeset: 10570:6f4cff0e7f16 user:Mauro Carvalho Chehab date:Sat Feb 14 08:29:07 2009 -0200 summary: v4l2-framework: documments videobuf usage on drivers changeset: 10489:c84416787a43 user:Mauro Carvalho Chehab date:Sat Feb 07 11:07:04 2009 +0100 summary: doc: use consistent naming conventions for vdev and v4l2_dev. changeset: 10252:09cabe4f0c63 user:Hans Verkuil date:Thu Jan 15 10:09:05 2009 +0100 summary: v4l2 doc: explain why v4l2_device_unregister_subdev() has to be called. changeset: 10141:4cc8ed11e2e0 user:Hans Verkuil date:Tue Dec 30 11:14:19 2008 +0100 summary: v4l2: debugging API changed to match against driver name instead of ID. changeset: 10136:ffe112f306a3 user:Hans Verkuil date:Tue Dec 23 17:42:25 2008 +0100 summary: v4l2 doc: update v4l2-framework.txt changeset: 10134:a11cf6774c04 user:Hans Verkuil date:Tue Dec 23 16:17:23 2008 +0100 summary: v4l2 doc: set v4l2_dev instead of parent. changeset: 10133:f03ab4ab3f87 user:Hans Verkuil date:Mon Dec 22 13:13:11 2008 +0100 summary: v4l2-framework: use correct comment style. changeset: 9943:2e680d8a3b2f user:Hans Verkuil date:Fri Dec 19 14:20:22 2008 +0100 summary: v4l2: document video_device. changeset: 9820:5611723c9512 parent: 9767:7100e78482d7 user:Hans Verkuil date:Sun Nov 30 01:36:58 2008 +0100 summary: v4l2: add v4l2_device and v4l2_subdev structs to the v4l2 framework. > The I2C core changes went in in 2.6.22. I'm not referring to i2c core changes, but to v4l2 dev/subdev stuff. > And please note that the use of the old API isn't the only question I > have, there are more oddities with the i2c handling that I'd like to have > more information about. Writing i2c registers directly from the adapter > driver doesn't look good to me at first sight. Yes, I'm aware of the I2C GPIO and similar stuff. This is one of the reasons why this shouldn't be merged upstream yet. > > The second point is
[PULL] Rhttp://linuxtv.org/hg/~mkrufky/lgdt3305 ( was - e: null pointer access in error path of lgdt3305 driver )
Matthias Schwarzott wrote: Hi Michael! Looking at your new lgdt3305 driver, I noticed that the error path of lgdt3305_attach, that is also jumped to kzalloc errors, sets state->frontend.demodulator_priv to NULL. That will oops in case state is NULL. So you either need two goto labels for failures or just return in case kzalloc fails. Regards Matthias Matthias, Thank you for pointing this out -- I am pushing up a fix right now. Mauro, Please pull from: http://linuxtv.org/hg/~mkrufky/lgdt3305 for the following fix, thanks to Matthias: - lgdt3305: avoid OOPS in error path of lgdt3305_attach lgdt3305.c |1 - 1 file changed, 1 deletion(-) Regards, Mike -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] pcm990 baseboard: add camera bus width switch setting
On Thu, 12 Mar 2009, Sascha Hauer wrote:
> Some Phytec cameras have a I2C GPIO expander which allows it to
> switch between different sensor bus widths. This was previously
> handled in the camera driver. Since handling of this switch
> varies on several boards the cameras are used on, the board
> support seems a better place to handle the switch
>
> Signed-off-by: Sascha Hauer
> ---
> arch/arm/mach-pxa/pcm990-baseboard.c | 49 +++--
> 1 files changed, 40 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
> b/arch/arm/mach-pxa/pcm990-baseboard.c
> index 34841c7..8b01565 100644
> --- a/arch/arm/mach-pxa/pcm990-baseboard.c
> +++ b/arch/arm/mach-pxa/pcm990-baseboard.c
> @@ -381,14 +381,45 @@ static struct pca953x_platform_data pca9536_data = {
> .gpio_base = NR_BUILTIN_GPIO + 1,
> };
>
> -static struct soc_camera_link iclink[] = {
> - {
> - .bus_id = 0, /* Must match with the camera ID above */
> - .gpio = NR_BUILTIN_GPIO + 1,
> - }, {
> - .bus_id = 0, /* Must match with the camera ID above */
> - .gpio = -ENXIO,
> +static int gpio_bus_switch;
> +
> +static int pcm990_camera_set_bus_param(struct soc_camera_link *link,
> + unsigned long flags)
> +{
> + if (gpio_bus_switch <= 0)
> + return 0;
Are you really sure you don't want to return an error here? In
query_bus_param() below, if you fail to get the GPIO, you set
gpio_bus_switch to -EINVAL and return only 10 bit. Now if a buggy host
driver still requests 8 bits, mt9m001 will call ->set_bus_param and you
will happily return 0...
> +
> + if (flags & SOCAM_DATAWIDTH_8)
> + gpio_set_value(gpio_bus_switch, 1);
> + else
> + gpio_set_value(gpio_bus_switch, 0);
> +
> + return 0;
> +}
> +
> +static unsigned long pcm990_camera_query_bus_param(struct soc_camera_link
> *link)
> +{
> + int ret;
> +
> + if (!gpio_bus_switch) {
> + ret = gpio_request(NR_BUILTIN_GPIO + 1, "camera");
> + if (!ret) {
> + gpio_bus_switch = NR_BUILTIN_GPIO + 1;
> + gpio_direction_output(gpio_bus_switch, 0);
> + } else
> + gpio_bus_switch = -EINVAL;
> }
> +
> + if (gpio_bus_switch > 0)
> + return SOCAM_DATAWIDTH_8 | SOCAM_DATAWIDTH_10;
> + else
> + return SOCAM_DATAWIDTH_10;
> +}
> +
> +static struct soc_camera_link iclink = {
> + .bus_id = 0, /* Must match with the camera ID above */
> + .query_bus_param = pcm990_camera_query_bus_param,
> + .set_bus_param = pcm990_camera_set_bus_param,
> };
>
> /* Board I2C devices. */
> @@ -399,10 +430,10 @@ static struct i2c_board_info __initdata
> pcm990_i2c_devices[] = {
> .platform_data = &pca9536_data,
> }, {
> I2C_BOARD_INFO("mt9v022", 0x48),
> - .platform_data = &iclink[0], /* With extender */
> + .platform_data = &iclink, /* With extender */
> }, {
> I2C_BOARD_INFO("mt9m001", 0x5d),
> - .platform_data = &iclink[0], /* With extender */
> + .platform_data = &iclink, /* With extender */
> },
> };
> #endif /* CONFIG_VIDEO_PXA27x ||CONFIG_VIDEO_PXA27x_MODULE */
> --
> 1.5.6.5
>
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] sdio: add cards ids for sms (Siano Mobile Silicon) MDTV receivers
sdio: add cards id for sms (Siano Mobile Silicon) MDTV receivers From: Uri Shkolnik Add SDIO vendor ID, and multiple device IDs for various SMS-based MDTV SDIO adapters. The patch has been done against 2.6.29-rc7 . Signed-off-by: Uri Shkolnik diff -uNr linux-2.6.29-rc7.prestine/include/linux/mmc/sdio_ids.h linux-2.6.29-rc7_sdio_patch/include/linux/mmc/sdio_ids.h --- linux-2.6.29-rc7.prestine/include/linux/mmc/sdio_ids.h 2009-03-04 03:05:22.0 +0200 +++ linux-2.6.29-rc7_sdio_patch/include/linux/mmc/sdio_ids.h2009-03-12 12:24:14.0 +0200 @@ -24,6 +24,14 @@ */ #define SDIO_VENDOR_ID_MARVELL 0x02df +#define SDIO_VENDOR_ID_SIANO 0x039a + #define SDIO_DEVICE_ID_MARVELL_LIBERTAS0x9103 +#define SDIO_DEVICE_ID_SIANO_STELLAR 0x5347 +#define SDIO_DEVICE_ID_SIANO_NOVA_A0 0x1100 +#define SDIO_DEVICE_ID_SIANO_NOVA_B0 0x0201 +#define SDIO_DEVICE_ID_SIANO_NICE 0x0202 +#define SDIO_DEVICE_ID_SIANO_VEGA_A0 0x0300 +#define SDIO_DEVICE_ID_SIANO_VENICE0x0301 #endif -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1 re-submit 1] sdio: add low level i/o functions for workarounds
sdio: add low level i/o functions for workarounds
From: Pierre Ossman
Some shoddy hardware doesn't properly adhere to the register model
of SDIO, but treats the system like a series of transaction. That means
that the drivers must have full control over what goes the bus (and the
core cannot optimize transactions or work around problems in host
controllers).
This commit adds some low level functions that gives SDIO drivers the
ability to send specific register access commands. They should only be
used when the hardware is truly broken though.
The patch has been done against 2.6.29-rc7 .
Signed-off-by: Pierre Ossman
Signed-off-by: Uri Shkolnik
diff -uNr linux-2.6.29-rc7.prestine/drivers/mmc/core/sdio_io.c
linux-2.6.29-rc7_sdio_patch/drivers/mmc/core/sdio_io.c
--- linux-2.6.29-rc7.prestine/drivers/mmc/core/sdio_io.c2009-03-04
03:05:22.0 +0200
+++ linux-2.6.29-rc7_sdio_patch/drivers/mmc/core/sdio_io.c 2009-03-12
12:22:42.0 +0200
@@ -635,3 +635,252 @@
*err_ret = ret;
}
EXPORT_SYMBOL_GPL(sdio_f0_writeb);
+
+/**
+ * sdio_read_bytes - low level byte mode transfer from an SDIO function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @bytes: number of bytes to read
+ *
+ * Performs a byte mode transfer from the address space of the given
+ * SDIO function. The address is increased for each byte. Return
+ * value indicates if the transfer succeeded or not.
+ *
+ * Note: This is a low level function that should only be used as a
+ * workaround when the hardware has a crappy register abstraction
+ * that relies on specific SDIO operations.
+ */
+int sdio_read_bytes(struct sdio_func *func, void *dst,
+ unsigned int addr, int bytes)
+{
+ if (bytes > sdio_max_byte_size(func))
+ return -EINVAL;
+
+ return mmc_io_rw_extended(func->card, 0, func->num, addr, 1,
+ dst, 1, bytes);
+}
+EXPORT_SYMBOL_GPL(sdio_read_bytes);
+
+/**
+ * sdio_read_bytes_noincr - low level byte mode transfer from an SDIO
function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @bytes: number of bytes to read
+ *
+ * Performs a byte mode transfer from the address space of the given
+ * SDIO function. The address is NOT increased for each byte. Return
+ * value indicates if the transfer succeeded or not.
+ *
+ * Note: This is a low level function that should only be used as a
+ * workaround when the hardware has a crappy register abstraction
+ * that relies on specific SDIO operations.
+ */
+int sdio_read_bytes_noincr(struct sdio_func *func, void *dst,
+ unsigned int addr, int bytes)
+{
+ if (bytes > sdio_max_byte_size(func))
+ return -EINVAL;
+
+ return mmc_io_rw_extended(func->card, 0, func->num, addr, 0,
+ dst, 1, bytes);
+}
+EXPORT_SYMBOL_GPL(sdio_read_bytes_noincr);
+
+/**
+ * sdio_read_blocks - low level block mode transfer from an SDIO function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @block: number of blocks to read
+ *
+ * Performs a block mode transfer from the address space of the given
+ * SDIO function. The address is increased for each byte. Return
+ * value indicates if the transfer succeeded or not.
+ *
+ * The block size needs to be explicitly changed by calling
+ * sdio_set_block_size().
+ *
+ * Note: This is a low level function that should only be used as a
+ * workaround when the hardware has a crappy register abstraction
+ * that relies on specific SDIO operations.
+ */
+int sdio_read_blocks(struct sdio_func *func, void *dst,
+ unsigned int addr, int blocks)
+{
+ if (!func->card->cccr.multi_block)
+ return -EINVAL;
+
+ if (blocks > func->card->host->max_blk_count)
+ return -EINVAL;
+ if (blocks > (func->card->host->max_seg_size / func->cur_blksize))
+ return -EINVAL;
+ if (blocks > 511)
+ return -EINVAL;
+
+ return mmc_io_rw_extended(func->card, 0, func->num, addr, 1,
+ dst, blocks, func->cur_blksize);
+}
+EXPORT_SYMBOL_GPL(sdio_read_blocks);
+
+/**
+ * sdio_read_blocks_noincr - low level block mode transfer from an SDIO
function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @block: number of blocks to read
+ *
+ * Performs a block mode transfer from the address space of the given
+ * SDIO function. The address is NOT increased for each byte. Return
+ * value indicates if the transfer succeeded or not.
+ *
+ * The block size needs to be explicitly changed by calling
+ * sdio_set_block_size().
+ *
+ *
Re: [PATCH 1/1] sdio: add low level i/o functions for workarounds
Hi, Sorry, but I emailed the wrong patch file, sorry about it. Please ignore and I'll re-submit it shortly. :-( Uri -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] sdio: add low level i/o functions for workarounds
sdio: add low level i/o functions for workarounds
From: Pierre Ossman
Some shoddy hardware doesn't properly adhere to the register model
of SDIO, but treats the system like a series of transaction. That means
that the drivers must have full control over what goes the bus (and the
core cannot optimize transactions or work around problems in host
controllers).
This commit adds some low level functions that gives SDIO drivers the
ability to send specific register access commands. They should only be
used when the hardware is truly broken though.
This patch has been created on August 2008, and re-generated against 2.6.29-rc7
.
Signed-off-by: Pierre Ossman
Signed-off-by: Uri Shkolnik
diff -uNr linux-2.6.29-rc7.prestine/drivers/mmc/core/sdio_io.c
linux-2.6.29-rc7/drivers/mmc/core/sdio_io.c
--- linux-2.6.29-rc7.prestine/drivers/mmc/core/sdio_io.c2009-03-04
03:05:22.0 +0200
+++ linux-2.6.29-rc7/drivers/mmc/core/sdio_io.c 2009-03-12 12:22:42.0
+0200
@@ -635,3 +635,252 @@
*err_ret = ret;
}
EXPORT_SYMBOL_GPL(sdio_f0_writeb);
+
+/**
+ * sdio_read_bytes - low level byte mode transfer from an SDIO function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @bytes: number of bytes to read
+ *
+ * Performs a byte mode transfer from the address space of the given
+ * SDIO function. The address is increased for each byte. Return
+ * value indicates if the transfer succeeded or not.
+ *
+ * Note: This is a low level function that should only be used as a
+ * workaround when the hardware has a crappy register abstraction
+ * that relies on specific SDIO operations.
+ */
+int sdio_read_bytes(struct sdio_func *func, void *dst,
+ unsigned int addr, int bytes)
+{
+ if (bytes > sdio_max_byte_size(func))
+ return -EINVAL;
+
+ return mmc_io_rw_extended(func->card, 0, func->num, addr, 1,
+ dst, 1, bytes);
+}
+EXPORT_SYMBOL_GPL(sdio_read_bytes);
+
+/**
+ * sdio_read_bytes_noincr - low level byte mode transfer from an SDIO
function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @bytes: number of bytes to read
+ *
+ * Performs a byte mode transfer from the address space of the given
+ * SDIO function. The address is NOT increased for each byte. Return
+ * value indicates if the transfer succeeded or not.
+ *
+ * Note: This is a low level function that should only be used as a
+ * workaround when the hardware has a crappy register abstraction
+ * that relies on specific SDIO operations.
+ */
+int sdio_read_bytes_noincr(struct sdio_func *func, void *dst,
+ unsigned int addr, int bytes)
+{
+ if (bytes > sdio_max_byte_size(func))
+ return -EINVAL;
+
+ return mmc_io_rw_extended(func->card, 0, func->num, addr, 0,
+ dst, 1, bytes);
+}
+EXPORT_SYMBOL_GPL(sdio_read_bytes_noincr);
+
+/**
+ * sdio_read_blocks - low level block mode transfer from an SDIO function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @block: number of blocks to read
+ *
+ * Performs a block mode transfer from the address space of the given
+ * SDIO function. The address is increased for each byte. Return
+ * value indicates if the transfer succeeded or not.
+ *
+ * The block size needs to be explicitly changed by calling
+ * sdio_set_block_size().
+ *
+ * Note: This is a low level function that should only be used as a
+ * workaround when the hardware has a crappy register abstraction
+ * that relies on specific SDIO operations.
+ */
+int sdio_read_blocks(struct sdio_func *func, void *dst,
+ unsigned int addr, int blocks)
+{
+ if (!func->card->cccr.multi_block)
+ return -EINVAL;
+
+ if (blocks > func->card->host->max_blk_count)
+ return -EINVAL;
+ if (blocks > (func->card->host->max_seg_size / func->cur_blksize))
+ return -EINVAL;
+ if (blocks > 511)
+ return -EINVAL;
+
+ return mmc_io_rw_extended(func->card, 0, func->num, addr, 1,
+ dst, blocks, func->cur_blksize);
+}
+EXPORT_SYMBOL_GPL(sdio_read_blocks);
+
+/**
+ * sdio_read_blocks_noincr - low level block mode transfer from an SDIO
function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @block: number of blocks to read
+ *
+ * Performs a block mode transfer from the address space of the given
+ * SDIO function. The address is NOT increased for each byte. Return
+ * value indicates if the transfer succeeded or not.
+ *
+ * The block size needs to be explicitly changed by calling
+ * sdio_set_block_size().
+
[PATCH 5/5] soc-camera: remove now unused gpio member of struct soc_camera_link
Signed-off-by: Sascha Hauer
---
include/media/soc_camera.h |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 62f07db..c7a6f42 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -93,8 +93,6 @@ struct soc_camera_host_ops {
struct soc_camera_link {
/* Camera bus id, used to match a camera and a bus */
int bus_id;
- /* GPIO number to switch between 8 and 10 bit modes */
- unsigned int gpio;
/* Per camera SOCAM_SENSOR_* bus flags */
unsigned long flags;
/* Optional callbacks to power on or off and reset the sensor */
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] mt9v022: allow setting of bus width from board code
This patch removes the phytec specific setting of the bus width
and switches to the more generic query_bus_param/set_bus_param
hooks
Signed-off-by: Sascha Hauer
---
drivers/media/video/Kconfig |7 --
drivers/media/video/mt9v022.c | 141 -
2 files changed, 42 insertions(+), 106 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 5fc1531..071d66f 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -747,13 +747,6 @@ config SOC_CAMERA_MT9V022
help
This driver supports MT9V022 cameras from Micron
-config MT9V022_PCA9536_SWITCH
- bool "pca9536 datawidth switch for mt9v022"
- depends on SOC_CAMERA_MT9V022 && GENERIC_GPIO
- help
- Select this if your MT9V022 camera uses a PCA9536 I2C GPIO
- extender to switch between 8 and 10 bit datawidth modes
-
config SOC_CAMERA_TW9910
tristate "tw9910 support"
depends on SOC_CAMERA && I2C
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index b04c8cb..4ddc394 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -13,7 +13,6 @@
#include
#include
#include
-#include
#include
#include
@@ -89,9 +88,7 @@ struct mt9v022 {
struct i2c_client *client;
struct soc_camera_device icd;
int model; /* V4L2_IDENT_MT9V022* codes from v4l2-chip-ident.h */
- int switch_gpio;
u16 chip_control;
- unsigned char datawidth;
};
static int reg_read(struct soc_camera_device *icd, const u8 reg)
@@ -209,66 +206,6 @@ static int mt9v022_stop_capture(struct soc_camera_device
*icd)
return 0;
}
-static int bus_switch_request(struct mt9v022 *mt9v022, struct soc_camera_link
*icl)
-{
-#ifdef CONFIG_MT9V022_PCA9536_SWITCH
- int ret;
- unsigned int gpio = icl->gpio;
-
- if (gpio_is_valid(gpio)) {
- /* We have a data bus switch. */
- ret = gpio_request(gpio, "mt9v022");
- if (ret < 0) {
- dev_err(&mt9v022->client->dev, "Cannot get GPIO %u\n",
gpio);
- return ret;
- }
-
- ret = gpio_direction_output(gpio, 0);
- if (ret < 0) {
- dev_err(&mt9v022->client->dev,
- "Cannot set GPIO %u to output\n", gpio);
- gpio_free(gpio);
- return ret;
- }
- }
-
- mt9v022->switch_gpio = gpio;
-#else
- mt9v022->switch_gpio = -EINVAL;
-#endif
- return 0;
-}
-
-static void bus_switch_release(struct mt9v022 *mt9v022)
-{
-#ifdef CONFIG_MT9V022_PCA9536_SWITCH
- if (gpio_is_valid(mt9v022->switch_gpio))
- gpio_free(mt9v022->switch_gpio);
-#endif
-}
-
-static int bus_switch_act(struct mt9v022 *mt9v022, int go8bit)
-{
-#ifdef CONFIG_MT9V022_PCA9536_SWITCH
- if (!gpio_is_valid(mt9v022->switch_gpio))
- return -ENODEV;
-
- gpio_set_value_cansleep(mt9v022->switch_gpio, go8bit);
- return 0;
-#else
- return -ENODEV;
-#endif
-}
-
-static int bus_switch_possible(struct mt9v022 *mt9v022)
-{
-#ifdef CONFIG_MT9V022_PCA9536_SWITCH
- return gpio_is_valid(mt9v022->switch_gpio);
-#else
- return 0;
-#endif
-}
-
static int mt9v022_set_bus_param(struct soc_camera_device *icd,
unsigned long flags)
{
@@ -282,19 +219,17 @@ static int mt9v022_set_bus_param(struct soc_camera_device
*icd,
if (!is_power_of_2(width_flag))
return -EINVAL;
- if ((mt9v022->datawidth != 10 && (width_flag == SOCAM_DATAWIDTH_10)) ||
- (mt9v022->datawidth != 9 && (width_flag == SOCAM_DATAWIDTH_9)) ||
- (mt9v022->datawidth != 8 && (width_flag == SOCAM_DATAWIDTH_8))) {
- /* Well, we actually only can do 10 or 8 bits... */
- if (width_flag == SOCAM_DATAWIDTH_9)
- return -EINVAL;
-
- ret = bus_switch_act(mt9v022,
-width_flag == SOCAM_DATAWIDTH_8);
- if (ret < 0)
+ if (icl->set_bus_param) {
+ ret = icl->set_bus_param(icl, width_flag);
+ if (ret)
return ret;
-
- mt9v022->datawidth = width_flag == SOCAM_DATAWIDTH_8 ? 8 : 10;
+ } else {
+ /*
+* Without board specific bus width settings we only support the
+* sensors native bus width
+*/
+ if (width_flag != SOCAM_DATAWIDTH_10)
+ return -EINVAL;
}
flags = soc_camera_apply_sensor_flags(icl, flags);
@@ -328,10 +263,14 @@ static int mt9v022_set_bus_param(struct soc_camera_device
*icd,
static unsigned long mt9v022_query_bus_param(struct soc_camera_device *icd)
{
struct mt9v022 *mt9v022 = container_of(ic
[PATCH 3/5] mt9m001: allow setting of bus width from board code
This patch removes the phytec specific setting of the bus width
and switches to the more generic query_bus_param/set_bus_param
hooks
Signed-off-by: Sascha Hauer
---
drivers/media/video/Kconfig |7 --
drivers/media/video/mt9m001.c | 143 +++-
2 files changed, 40 insertions(+), 110 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 19cf3b8..5fc1531 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -728,13 +728,6 @@ config SOC_CAMERA_MT9M001
This driver supports MT9M001 cameras from Micron, monochrome
and colour models.
-config MT9M001_PCA9536_SWITCH
- bool "pca9536 datawidth switch for mt9m001"
- depends on SOC_CAMERA_MT9M001 && GENERIC_GPIO
- help
- Select this if your MT9M001 camera uses a PCA9536 I2C GPIO
- extender to switch between 8 and 10 bit datawidth modes
-
config SOC_CAMERA_MT9M111
tristate "mt9m111 and mt9m112 support"
depends on SOC_CAMERA && I2C
diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c
index c1bf75e..d3bc84c 100644
--- a/drivers/media/video/mt9m001.c
+++ b/drivers/media/video/mt9m001.c
@@ -12,7 +12,6 @@
#include
#include
#include
-#include
#include
#include
@@ -73,9 +72,7 @@ struct mt9m001 {
struct i2c_client *client;
struct soc_camera_device icd;
int model; /* V4L2_IDENT_MT9M001* codes from v4l2-chip-ident.h */
- int switch_gpio;
unsigned char autoexposure;
- unsigned char datawidth;
};
static int reg_read(struct soc_camera_device *icd, const u8 reg)
@@ -181,92 +178,28 @@ static int mt9m001_stop_capture(struct soc_camera_device
*icd)
return 0;
}
-static int bus_switch_request(struct mt9m001 *mt9m001,
- struct soc_camera_link *icl)
-{
-#ifdef CONFIG_MT9M001_PCA9536_SWITCH
- int ret;
- unsigned int gpio = icl->gpio;
-
- if (gpio_is_valid(gpio)) {
- /* We have a data bus switch. */
- ret = gpio_request(gpio, "mt9m001");
- if (ret < 0) {
- dev_err(&mt9m001->client->dev, "Cannot get GPIO %u\n",
- gpio);
- return ret;
- }
-
- ret = gpio_direction_output(gpio, 0);
- if (ret < 0) {
- dev_err(&mt9m001->client->dev,
- "Cannot set GPIO %u to output\n", gpio);
- gpio_free(gpio);
- return ret;
- }
- }
-
- mt9m001->switch_gpio = gpio;
-#else
- mt9m001->switch_gpio = -EINVAL;
-#endif
- return 0;
-}
-
-static void bus_switch_release(struct mt9m001 *mt9m001)
-{
-#ifdef CONFIG_MT9M001_PCA9536_SWITCH
- if (gpio_is_valid(mt9m001->switch_gpio))
- gpio_free(mt9m001->switch_gpio);
-#endif
-}
-
-static int bus_switch_act(struct mt9m001 *mt9m001, int go8bit)
-{
-#ifdef CONFIG_MT9M001_PCA9536_SWITCH
- if (!gpio_is_valid(mt9m001->switch_gpio))
- return -ENODEV;
-
- gpio_set_value_cansleep(mt9m001->switch_gpio, go8bit);
- return 0;
-#else
- return -ENODEV;
-#endif
-}
-
-static int bus_switch_possible(struct mt9m001 *mt9m001)
-{
-#ifdef CONFIG_MT9M001_PCA9536_SWITCH
- return gpio_is_valid(mt9m001->switch_gpio);
-#else
- return 0;
-#endif
-}
-
static int mt9m001_set_bus_param(struct soc_camera_device *icd,
unsigned long flags)
{
struct mt9m001 *mt9m001 = container_of(icd, struct mt9m001, icd);
- unsigned int width_flag = flags & SOCAM_DATAWIDTH_MASK;
- int ret;
+ struct soc_camera_link *icl = mt9m001->client->dev.platform_data;
+ unsigned long width_flag = flags & SOCAM_DATAWIDTH_MASK;
- /* Flags validity verified in test_bus_param */
+ /* Only one width bit may be set */
+ if (!is_power_of_2(width_flag))
+ return -EINVAL;
- if ((mt9m001->datawidth != 10 && (width_flag == SOCAM_DATAWIDTH_10)) ||
- (mt9m001->datawidth != 9 && (width_flag == SOCAM_DATAWIDTH_9)) ||
- (mt9m001->datawidth != 8 && (width_flag == SOCAM_DATAWIDTH_8))) {
- /* Well, we actually only can do 10 or 8 bits... */
- if (width_flag == SOCAM_DATAWIDTH_9)
- return -EINVAL;
- ret = bus_switch_act(mt9m001,
-width_flag == SOCAM_DATAWIDTH_8);
- if (ret < 0)
- return ret;
+ if (icl->set_bus_param)
+ return icl->set_bus_param(icl, width_flag);
- mt9m001->datawidth = width_flag == SOCAM_DATAWIDTH_8 ? 8 : 10;
- }
+ /*
+* Without board specific bus width settings we only support the
+* sensors native bus width
+*/
+ if (width_flag == S
[PATCH 1/5] soc-camera: add board hook to specify the buswidth for camera sensors
Camera sensors have a native bus width say support, but on some
boards not all sensor data lines are connected to the image
interface and thus support a different bus width than the sensors
native one. Some boards even have a bus driver which dynamically
switches between different bus widths with a GPIO.
This patch adds a hook which board code can use to support different
bus widths.
Signed-off-by: Sascha Hauer
---
include/media/soc_camera.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 7440d92..62f07db 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -100,6 +100,13 @@ struct soc_camera_link {
/* Optional callbacks to power on or off and reset the sensor */
int (*power)(struct device *, int);
int (*reset)(struct device *);
+ /*
+* some platforms may support different data widths than the sensors
+* native ones due to different data line routing. Let the board code
+* overwrite the width flags.
+*/
+ int (*set_bus_param)(struct soc_camera_link *, unsigned long flags);
+ unsigned long (*query_bus_param)(struct soc_camera_link *);
};
static inline struct soc_camera_device *to_soc_camera_dev(struct device *dev)
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] V2: soc-camera: setting the buswidth of camera sensors
Take 2: I hope I addressed all comments I receive in the first round. The following patches change the handling of the bus width for camera sensors so that a board can overwrite a sensors native bus width Sascha Hauer (5): soc-camera: add board hook to specify the buswidth for camera sensors pcm990 baseboard: add camera bus width switch setting mt9m001: allow setting of bus width from board code mt9v022: allow setting of bus width from board code soc-camera: remove now unused gpio member of struct soc_camera_link arch/arm/mach-pxa/pcm990-baseboard.c | 49 ++-- drivers/media/video/Kconfig | 14 drivers/media/video/mt9m001.c| 143 ++ drivers/media/video/mt9v022.c| 141 ++--- include/media/soc_camera.h |9 ++- 5 files changed, 129 insertions(+), 227 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] pcm990 baseboard: add camera bus width switch setting
Some Phytec cameras have a I2C GPIO expander which allows it to
switch between different sensor bus widths. This was previously
handled in the camera driver. Since handling of this switch
varies on several boards the cameras are used on, the board
support seems a better place to handle the switch
Signed-off-by: Sascha Hauer
---
arch/arm/mach-pxa/pcm990-baseboard.c | 49 +++--
1 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index 34841c7..8b01565 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -381,14 +381,45 @@ static struct pca953x_platform_data pca9536_data = {
.gpio_base = NR_BUILTIN_GPIO + 1,
};
-static struct soc_camera_link iclink[] = {
- {
- .bus_id = 0, /* Must match with the camera ID above */
- .gpio = NR_BUILTIN_GPIO + 1,
- }, {
- .bus_id = 0, /* Must match with the camera ID above */
- .gpio = -ENXIO,
+static int gpio_bus_switch;
+
+static int pcm990_camera_set_bus_param(struct soc_camera_link *link,
+ unsigned long flags)
+{
+ if (gpio_bus_switch <= 0)
+ return 0;
+
+ if (flags & SOCAM_DATAWIDTH_8)
+ gpio_set_value(gpio_bus_switch, 1);
+ else
+ gpio_set_value(gpio_bus_switch, 0);
+
+ return 0;
+}
+
+static unsigned long pcm990_camera_query_bus_param(struct soc_camera_link
*link)
+{
+ int ret;
+
+ if (!gpio_bus_switch) {
+ ret = gpio_request(NR_BUILTIN_GPIO + 1, "camera");
+ if (!ret) {
+ gpio_bus_switch = NR_BUILTIN_GPIO + 1;
+ gpio_direction_output(gpio_bus_switch, 0);
+ } else
+ gpio_bus_switch = -EINVAL;
}
+
+ if (gpio_bus_switch > 0)
+ return SOCAM_DATAWIDTH_8 | SOCAM_DATAWIDTH_10;
+ else
+ return SOCAM_DATAWIDTH_10;
+}
+
+static struct soc_camera_link iclink = {
+ .bus_id = 0, /* Must match with the camera ID above */
+ .query_bus_param = pcm990_camera_query_bus_param,
+ .set_bus_param = pcm990_camera_set_bus_param,
};
/* Board I2C devices. */
@@ -399,10 +430,10 @@ static struct i2c_board_info __initdata
pcm990_i2c_devices[] = {
.platform_data = &pca9536_data,
}, {
I2C_BOARD_INFO("mt9v022", 0x48),
- .platform_data = &iclink[0], /* With extender */
+ .platform_data = &iclink, /* With extender */
}, {
I2C_BOARD_INFO("mt9m001", 0x5d),
- .platform_data = &iclink[0], /* With extender */
+ .platform_data = &iclink, /* With extender */
},
};
#endif /* CONFIG_VIDEO_PXA27x ||CONFIG_VIDEO_PXA27x_MODULE */
--
1.5.6.5
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linuxtv-commits] [hg:v4l-dvb] Add cx231xx USB driver
> > On Thu, 12 Mar 2009 08:38:59 +0100 > Hans Verkuil wrote: > >> Mauro, >> >> What the hell??! >> >> Since when does a big addition like this get merged without undergoing a >> public review? >> >> I've been working my ass off converting drivers to the new i2c API and >> v4l2_subdev structures and here you merge a big driver that uses >> old-style >> (which will lead to 'deprecated' warnings when compiling with 2.6.29, >> BTW), >> where the driver writes directly to i2c modules instead of adding a >> proper >> i2c module for them. And what are 'colibri', 'flatrion' and 'hammerhead' >> anyway? Are they integrated devices of the cx231xx? Can they be used >> separately in other products as well? >> >> So yes, I have objections. At the minimum it should be converted first >> to >> use v4l2_device/v4l2_subdev and I need more information on the new i2c >> devices so I can tell whether the code for those should be split off >> into >> separate i2c modules. Not to mention that I want to have the time to >> review >> this code more closely. >> >> Sorry Sri, this isn't your fault. > > Hans, > > I know that you're rushing to convert all drivers to the new model, but > you > should give time to time. Even with Kernel's fast development cycle, we > should > take care to not depreciate things faster than developers can track (btw, > lwn.net already complained that V4L subsystem changes their APIs faster > than > usual). Mauro, you did not answer the question why this driver was just merged without going through a public review? If I'd seen it beforehand I'd have worked together with Sri to get it fixed first. I don't expect him to know about this, but I didn't even get a chance to discuss it and help with it. Everyone else has to go through the normal review channels, but apparently this was just fast-tracked and merged. That's not the way to do it. Please back out this driver, put it in a separate tree and let me 1) review this driver first, and 2) help Sri implementing the v4l2_device/v4l2_subdev stuff. > First of all, except for ivtv drivers, the first conversion to the new > model > occurred just few weeks ago. The new model will bring some gains, but this > shouldn't stop the merge of the drivers whose development started before > we > port the drivers used as example by the developer. > > This is a new model, and we should give people some time to adapt to it. > This > is the way we worked in the past and it is the way we should keep working. It's not a new model. The I2C core changes went in in 2.6.22. Jean is no longer accepting new i2c drivers that use the old module, and neither should we. And definitely NOT without discussing it first. The old i2c API has been marked deprecated in 2.6.29, and that's for a reason. There are good alternatives for this and I'm available to help with the conversion. Not to mention that this will make Jean quite unhappy. And please note that the use of the old API isn't the only question I have, there are more oddities with the i2c handling that I'd like to have more information about. Writing i2c registers directly from the adapter driver doesn't look good to me at first sight. > For > example, video_ioctl2 were added several Kernel releases before merging > uvc > driver. Yet, we've accepted uvc driver without using the new model, > because its > development that occurred before video_ioctl2. > > The second point is that there's nothing at > Documentation/feature-removal-schedule.txt informing that those stuff is > deprecated. Yes it is, see this from the 2.6.29 kernel: What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client() When: 2.6.29 (ideally) or 2.6.30 (more likely) Why:Deprecated by the new (standard) device driver binding model. Use i2c_driver->probe() and ->remove() instead. Who:Jean Delvare > So, we should still accept new drivers without the conversion at least > until > the end of 2.6.30 window, and add some notice at > feature-removal-schedule.txt > on 2.6.30 clearly stating what's deprecated and when, before generating > penalty > over the developers that are using the current drivers as their model of > development. > > In the specific case of cx231xx driver, I've explained to Sri, there are > still > some issues to be fixed at the driver. Although the driver works, It is > not > ready for 2.6.30 yet. > > However, keeping this on a separate tree will just create more mess > (according > with Sri, he already had to rebase this driver 4 times during 2.6.29-rc > cycle, > due to the high speed of internal API changes). > > Since his driver seems to be based on em28xx, he had no sample on how to > convert it to > v4l2_device/v4l2_subdev/new_i2c model. Again, if I'd known about it I'd be happy to help with it. Why didn't you put me in contact with him? You know I'm spending a lot of time on this. > After committing Devin's Austek patches (also seemed to be based on > em28xx), it will > probably be easier for Uri to co
null pointer access in error path of lgdt3305 driver
Hi Michael! Looking at your new lgdt3305 driver, I noticed that the error path of lgdt3305_attach, that is also jumped to kzalloc errors, sets state->frontend.demodulator_priv to NULL. That will oops in case state is NULL. So you either need two goto labels for failures or just return in case kzalloc fails. 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: [linuxtv-commits] [hg:v4l-dvb] Add cx231xx USB driver
On Thu, 12 Mar 2009 08:38:59 +0100 Hans Verkuil wrote: > Mauro, > > What the hell??! > > Since when does a big addition like this get merged without undergoing a > public review? > > I've been working my ass off converting drivers to the new i2c API and > v4l2_subdev structures and here you merge a big driver that uses old-style > (which will lead to 'deprecated' warnings when compiling with 2.6.29, BTW), > where the driver writes directly to i2c modules instead of adding a proper > i2c module for them. And what are 'colibri', 'flatrion' and 'hammerhead' > anyway? Are they integrated devices of the cx231xx? Can they be used > separately in other products as well? > > So yes, I have objections. At the minimum it should be converted first to > use v4l2_device/v4l2_subdev and I need more information on the new i2c > devices so I can tell whether the code for those should be split off into > separate i2c modules. Not to mention that I want to have the time to review > this code more closely. > > Sorry Sri, this isn't your fault. Hans, I know that you're rushing to convert all drivers to the new model, but you should give time to time. Even with Kernel's fast development cycle, we should take care to not depreciate things faster than developers can track (btw, lwn.net already complained that V4L subsystem changes their APIs faster than usual). First of all, except for ivtv drivers, the first conversion to the new model occurred just few weeks ago. The new model will bring some gains, but this shouldn't stop the merge of the drivers whose development started before we port the drivers used as example by the developer. This is a new model, and we should give people some time to adapt to it. This is the way we worked in the past and it is the way we should keep working. For example, video_ioctl2 were added several Kernel releases before merging uvc driver. Yet, we've accepted uvc driver without using the new model, because its development that occurred before video_ioctl2. The second point is that there's nothing at Documentation/feature-removal-schedule.txt informing that those stuff is deprecated. So, we should still accept new drivers without the conversion at least until the end of 2.6.30 window, and add some notice at feature-removal-schedule.txt on 2.6.30 clearly stating what's deprecated and when, before generating penalty over the developers that are using the current drivers as their model of development. In the specific case of cx231xx driver, I've explained to Sri, there are still some issues to be fixed at the driver. Although the driver works, It is not ready for 2.6.30 yet. However, keeping this on a separate tree will just create more mess (according with Sri, he already had to rebase this driver 4 times during 2.6.29-rc cycle, due to the high speed of internal API changes). Since his driver seems to be based on em28xx, he had no sample on how to convert it to v4l2_device/v4l2_subdev/new_i2c model. After committing Devin's Austek patches (also seemed to be based on em28xx), it will probably be easier for Uri to convert his driver to the new approach. -- 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: [linuxtv-commits] [hg:v4l-dvb] Fix I2C bridge error in zl10353
Mauro Carvalho Chehab wrote: On Thu, 12 Mar 2009 12:35:40 +0900 Dmitri Belimov wrote: Hi Antti Antti Palosaari wrote: Dmitri Belimov wrote: Could one of you please do such patchset? I haven't a lot expirience with kernel programming. If Antti can it is good. I'll check it on our board. OK, I will do. For the first phase and as a bug fix I will do that (disable i2c-gate) like dtv5100 driver does. After that I will add new configuration switch for i2c-gate disable and also change .no_tuner name to better one. Here it is, please review and test. I kept changes as small as possible to prevent errors. Lets fix more later. http://linuxtv.org/hg/~anttip/zl10353/ This patch is good. All work is ok. Antti, since you said that this patch should go to 2.6.29, I've already merged from your tree, after having Dmitry ack. Thanks. Antti -- 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: [linuxtv-commits] [hg:v4l-dvb] Fix I2C bridge error in zl10353
On Thu, 12 Mar 2009 12:35:40 +0900 Dmitri Belimov wrote: > Hi Antti > > > Antti Palosaari wrote: > > > Dmitri Belimov wrote: > > >>> Could one of you please do such patchset? > > >> > > >> I haven't a lot expirience with kernel programming. If Antti can > > >> it is good. I'll check it > > >> on our board. > > > > > > OK, I will do. For the first phase and as a bug fix I will do that > > > (disable i2c-gate) like dtv5100 driver does. After that I will add > > > new configuration switch for i2c-gate disable and also > > > change .no_tuner name to better one. > > > > Here it is, please review and test. I kept changes as small as > > possible to prevent errors. Lets fix more later. > > > > http://linuxtv.org/hg/~anttip/zl10353/ > > This patch is good. All work is ok. Antti, since you said that this patch should go to 2.6.29, I've already merged from your tree, after having Dmitry ack. > > With my best regards, Dmitry. > > > > > regards > > Antti > > -- > > http://palosaari.fi/ 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: [PULL] http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Wed, 11 Mar 2009 21:00:19 -0400
Devin Heitmueller wrote:
> Hello Mauro,
>
> Please apply one additional patch for the series I sent this morning:
>
> - au0828: make sure v4l2_device name is unique
>
> Thanks,
>
> Devin
>
+static int vidioc_querycap(struct file *file, void *priv,
+ struct v4l2_capability *cap)
+{
+ struct au0828_fh *fh = priv;
+ struct au0828_dev *dev = fh->dev;
+
+ memset(cap, 0, sizeof(*cap));
Please remove all memsets for input/output arguments on vidioc_foo at
au0828-video.c.
The V4L2 core warrants that the non-input fields are zeroed.
+static int vidioc_enum_fmt_vid_cap(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
+{
+ if(f->index)
+ return -EINVAL;
+
+ memset(f, 0, sizeof(*f));
+ f->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ strcpy(f->description, "Packed YUV2");
+
+ f->flags = 0;
+ f->pixelformat = V4L2_PIX_FMT_UYVY;
+
+ memset(f->reserved, 0, sizeof(f->reserved));
+ return 0;
+}
hmm.. you are cleaning up f->reserved three times: at v4l2-ioctl, at the
memset(f) and at memset(f->reserved).
You really wanted to make sure that you've cleaned it, don't you? ;)
hmm...
+#ifdef VBI_NOT_YET_WORKING
+ .vidioc_g_fmt_vbi_cap = vidioc_g_fmt_vbi_cap,
+ .vidioc_try_fmt_vbi_cap = vidioc_s_fmt_vbi_cap,
+ .vidioc_s_fmt_vbi_cap = vidioc_s_fmt_vbi_cap,
+#endif
I don't see any reference of this macro. If VBI is working, please cleanup the
driver. Btw, your logic seems to be inverted on some cases. Why are you adding
VBI macros, if it is not working yet?
On the other hand, if VBI is broken we'll need some rules for removing vbi code
from upstream, at gentree.pl.
+enum au0828_itype {
+ AU0828_VMUX_UNDEFINED = 0,
+ AU0828_VMUX_COMPOSITE,
+ AU0828_VMUX_SVIDEO,
+ AU0828_VMUX_CABLE,
+ AU0828_VMUX_TELEVISION,
+ AU0828_VMUX_DVB,
+ AU0828_VMUX_DEBUG
+};
...
+static int vidioc_enum_input(struct file *file, void *priv,
+ struct v4l2_input *input)
+{
+ struct au0828_fh *fh = priv;
+ struct au0828_dev *dev = fh->dev;
+ unsigned int tmp;
+
+ static const char *inames[] = {
+ [AU0828_VMUX_COMPOSITE] = "Composite",
+ [AU0828_VMUX_SVIDEO] = "S-Video",
+ [AU0828_VMUX_CABLE] = "Cable TV",
+ [AU0828_VMUX_TELEVISION] = "Television",
+ [AU0828_VMUX_DVB] = "DVB",
+ [AU0828_VMUX_DEBUG] = "tv debug"
+ };
If the user enumerates an entry marked as UNDEFINED, it will print NULL. Is it
what you really wanted? I would, instead, assign another value for
AU0828_VMUX_UNDEFINED, like -1.
+ switch(AUVI_INPUT(index).type) {
+ case AU0828_VMUX_SVIDEO:
+ {
+ dev->input_type = AU0828_VMUX_SVIDEO;
+ break;
+ }
+ case AU0828_VMUX_COMPOSITE:
+ {
+ dev->input_type = AU0828_VMUX_COMPOSITE;
+ break;
+ }
+ case AU0828_VMUX_TELEVISION:
+ {
+ dev->input_type = AU0828_VMUX_TELEVISION;
+ break;
+ }
+ default:
+ ;
+ }
You don't need all those braces.
Also, the default rule is missing. I don't see why you would preserve the same
dev->input_type if the user selects an undefined entry, or a DVB or a debug.
Ah, finally, there are a number of CodingStyle fun. I've enclosed what it got,
from the final code. Please, always use make checkpatch before committing a
patch.
Cheers,
Mauro
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c: In '
printk(arg); \':
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c:40: warning:
suspect code indent for conditional statements (8, 17)
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c: In ' u8 buf
[] = { (reg >> 8) | 0x80, reg & 0xff, data };':
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c:48: ERROR:
space prohibited before open square bracket '['
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c: In ' u8 b0
[] = { (reg >> 8) | 0x40, reg & 0xff };':
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c:65: ERROR:
space prohibited before open square bracket '['
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c: In ' u8 b1
[] = { 0 };':
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c:66: ERROR:
space prohibited before open square bracket '['
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c: In ' struct
i2c_msg msg [] = {':
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c:68: ERROR:
space prohibited before open square bracket '['
/home/v4l/master/linux/drivers/media/video/au0828/au0828-cards.c: In '
}':
/home/v4l/master/linux/drivers/media/video/au0828/au0828-cards.c:205
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Mar 12 09:40:14 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10966:3392722cc5b6 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: OK linux-2.6.28-armv5: OK linux-2.6.29-rc7-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc7-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc7-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-rc7-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-rc7-m32r: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc7-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc7-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS 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-rc7-x86_64: WARNINGS fw/apps: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc7): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification from this daily build 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: disable v4l2-ctl logging --log-status in /var/log/messages
On Thu, Mar 12, 2009 at 10:28 AM, Hans Verkuil wrote: > >> Hello, >> >> Is it possible to disable v4l2-ctl aplication logging into >> /var/log/messages. >> I am using it to control and monitor my PVR 150 cards and every time I >> run v4l2-ctl -d /dev/video0 --log-status all output is logged into >> /var/log/messages and some other linux log files. > > All --log-status does is to tell the driver to show it's status in the > kernel log for debugging purposes. It cannot and should not be relied upon > for monitoring/controlling a driver. > > What do you need it for anyway? I am just monitoring if signal is present on tuner, and what signal format is detected. These two lines: cx25840 1-0044: Video signal: not present cx25840 1-0044: Detected format: PAL-Nc I run this every minute and it is really annoying to have all this in my system logs. Is it possible to modify v4l2-ctl source to disable system logging? Regards, Gregor -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] pcm990 baseboard: add camera bus width switch setting
On Thu, Mar 12, 2009 at 10:25:35AM +0100, Guennadi Liakhovetski wrote:
> On Thu, 12 Mar 2009, Sascha Hauer wrote:
>
> > On Thu, Mar 12, 2009 at 09:40:46AM +0100, Guennadi Liakhovetski wrote:
> > > One more thing I noticed while looking at your patch 3/4:
> > >
> > > > +static int pcm990_camera_set_bus_param(struct device *dev,
> > > > + unsigned long flags)
> > > > +{
> > > > + if (gpio_bus_switch <= 0)
> > > > + return 0;
> > > > +
> > > > + if (flags & SOCAM_DATAWIDTH_8)
> > > > + gpio_set_value(NR_BUILTIN_GPIO + 1, 1);
> > > > + else
> > > > + gpio_set_value(NR_BUILTIN_GPIO + 1, 0);
> > >
> > > Originally the logic here was "only if flags == SOCAM_DATAWIDTH_8, switch
> > > to 8 bits, otherwise do 10 bits. I.e., if flags == SOCAM_DATAWIDTH_8 |
> > > SOCAM_DATAWIDTH_10, it would still do the default (and wider) 10 bits. Do
> > > you have any reason to change that logic?
> >
> > I was not aware that I changed any logic. I thought I would get here
> > with only one of the SOCAM_DATAWIDTH_* set. Isn't it a bug when we get
> > here with more than one width flags set?
> >
> > The mt9v022 driver has this in set_bus_param:
> >
> > >
> > > /* Only one width bit may be set */
> > > if (!is_power_of_2(width_flag))
> > > return -EINVAL;
> > >
> >
> > And I think it makes sense.
>
> Ok, then, could you, please add the same test to mt9m001? And, as I
> mentioned in a comment to 3/4, please, return an error if switching is
> requested but unsupported.
Ok, will do.
It may be that we need a different approach to the bus width setting in
the longer term. For example the mt9m001 can support any thinkable bus
width of 1 to inf. bits. This depends on the hardware designer who wired
up the connection and not the physical count of data lines the chip has.
I have no idea how to implement this though.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mt9v022: allow setting of bus width from board code
On Wed, 11 Mar 2009, Sascha Hauer wrote:
> This patch removes the phytec specific setting of the bus width
> and switches to the more generic query_bus_param/set_bus_param
> hooks
>
> Signed-off-by: Sascha Hauer
> ---
> drivers/media/video/Kconfig |7 ---
> drivers/media/video/mt9v022.c | 97
> +
> 2 files changed, 11 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index 5fc1531..071d66f 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -747,13 +747,6 @@ config SOC_CAMERA_MT9V022
> help
> This driver supports MT9V022 cameras from Micron
>
> -config MT9V022_PCA9536_SWITCH
> - bool "pca9536 datawidth switch for mt9v022"
> - depends on SOC_CAMERA_MT9V022 && GENERIC_GPIO
> - help
> - Select this if your MT9V022 camera uses a PCA9536 I2C GPIO
> - extender to switch between 8 and 10 bit datawidth modes
> -
> config SOC_CAMERA_TW9910
> tristate "tw9910 support"
> depends on SOC_CAMERA && I2C
> diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
> index b04c8cb..26f97eb 100644
> --- a/drivers/media/video/mt9v022.c
> +++ b/drivers/media/video/mt9v022.c
> @@ -209,66 +209,6 @@ static int mt9v022_stop_capture(struct soc_camera_device
> *icd)
> return 0;
> }
>
> -static int bus_switch_request(struct mt9v022 *mt9v022, struct
> soc_camera_link *icl)
> -{
> -#ifdef CONFIG_MT9V022_PCA9536_SWITCH
> - int ret;
> - unsigned int gpio = icl->gpio;
> -
> - if (gpio_is_valid(gpio)) {
> - /* We have a data bus switch. */
> - ret = gpio_request(gpio, "mt9v022");
> - if (ret < 0) {
> - dev_err(&mt9v022->client->dev, "Cannot get GPIO %u\n",
> gpio);
> - return ret;
> - }
> -
> - ret = gpio_direction_output(gpio, 0);
> - if (ret < 0) {
> - dev_err(&mt9v022->client->dev,
> - "Cannot set GPIO %u to output\n", gpio);
> - gpio_free(gpio);
> - return ret;
> - }
> - }
> -
> - mt9v022->switch_gpio = gpio;
> -#else
> - mt9v022->switch_gpio = -EINVAL;
> -#endif
> - return 0;
> -}
> -
> -static void bus_switch_release(struct mt9v022 *mt9v022)
> -{
> -#ifdef CONFIG_MT9V022_PCA9536_SWITCH
> - if (gpio_is_valid(mt9v022->switch_gpio))
> - gpio_free(mt9v022->switch_gpio);
> -#endif
> -}
> -
> -static int bus_switch_act(struct mt9v022 *mt9v022, int go8bit)
> -{
> -#ifdef CONFIG_MT9V022_PCA9536_SWITCH
> - if (!gpio_is_valid(mt9v022->switch_gpio))
> - return -ENODEV;
> -
> - gpio_set_value_cansleep(mt9v022->switch_gpio, go8bit);
> - return 0;
> -#else
> - return -ENODEV;
> -#endif
> -}
> -
> -static int bus_switch_possible(struct mt9v022 *mt9v022)
> -{
> -#ifdef CONFIG_MT9V022_PCA9536_SWITCH
> - return gpio_is_valid(mt9v022->switch_gpio);
> -#else
> - return 0;
> -#endif
> -}
> -
> static int mt9v022_set_bus_param(struct soc_camera_device *icd,
>unsigned long flags)
> {
> @@ -282,19 +222,10 @@ static int mt9v022_set_bus_param(struct
> soc_camera_device *icd,
> if (!is_power_of_2(width_flag))
> return -EINVAL;
>
> - if ((mt9v022->datawidth != 10 && (width_flag == SOCAM_DATAWIDTH_10)) ||
> - (mt9v022->datawidth != 9 && (width_flag == SOCAM_DATAWIDTH_9)) ||
> - (mt9v022->datawidth != 8 && (width_flag == SOCAM_DATAWIDTH_8))) {
> - /* Well, we actually only can do 10 or 8 bits... */
> - if (width_flag == SOCAM_DATAWIDTH_9)
> - return -EINVAL;
> -
> - ret = bus_switch_act(mt9v022,
> - width_flag == SOCAM_DATAWIDTH_8);
> - if (ret < 0)
> + if (icl->set_bus_param) {
> + ret = icl->set_bus_param(&mt9v022->client->dev, width_flag);
> + if (ret)
> return ret;
> -
> - mt9v022->datawidth = width_flag == SOCAM_DATAWIDTH_8 ? 8 : 10;
> }
>
> flags = soc_camera_apply_sensor_flags(icl, flags);
> @@ -328,10 +259,14 @@ static int mt9v022_set_bus_param(struct
> soc_camera_device *icd,
> static unsigned long mt9v022_query_bus_param(struct soc_camera_device *icd)
> {
> struct mt9v022 *mt9v022 = container_of(icd, struct mt9v022, icd);
> - unsigned int width_flag = SOCAM_DATAWIDTH_10;
> + struct soc_camera_link *icl = mt9v022->client->dev.platform_data;
> + unsigned int width_flag;
>
> - if (bus_switch_possible(mt9v022))
> - width_flag |= SOCAM_DATAWIDTH_8;
> + if (icl->query_bus_param)
> + width_flag = icl->query_bus_param(&mt9v022->client->dev) &
> + SOCAM_DATAWIDTH_MASK;
> + else
> + width_flag = SOCAM_DATAWIDTH_10;
Re: EC168 support?!
> bloehei wrote: > >> 40 00 00 00 40 08 c5 03 >>> 12 0c 93 80 06 12 0d 43 74 83 f0 e5 48 30 e3 > >> 78 > > hmm, at least that last fw upload packet is wrong. It should look like > 40 00 00 00 00 18 c5 03 >>> 49 9f f5 > > I did yesterday many changes and fixed one bad bug that could be behind > that. Please test with latest tree at: > http://linuxtv.org/hg/~anttip/ec168/ > > regards > Antti Hi, GREAT! The firmware now gets uploaded and I can watch all channels in my region with the linux vdr. Thanks a lot! Here's my system log: > ec168_module_init: > usbcore: registered new interface driver dvb_usb_ec168 > usb 1-3: new high speed USB device using ehci_hcd and address 2 > usb 1-3: configuration #1 chosen from 1 choice > ec168_probe: interface:0 > ec168_identify_state: > c0 01 00 00 01 00 01 00 <<< 00 > ec168_identify_state: reply:00 > dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design' in cold state, > will try to load a firmware usb 1-3: firmware: requesting dvb-usb-ec168.fw > dvb-usb: downloading firmware from file 'dvb-usb-ec168.fw' > ec168_download_firmware: > 40 00 00 00 00 00 00 08 >>> 02 13 e4 02 0e d3 00 00 00 00 00 02 14 f7 00 00 > 00 00 00 <---cut---> > 40 00 00 00 00 08 00 08 >>> 4a 12 0c 5b 04 f0 02 08 4b 12 09 7f 12 0d 43 74 > 82 f0 12 <---cut---> > 40 00 00 00 00 10 00 08 >>> 9d ec 98 40 05 fc ee 9d fe 0f d5 f0 e9 e4 ce fd > 22 ed f8 <---cut---> > 40 00 00 00 00 18 c5 03 >>> 49 9f f5 49 e5 48 94 00 f5 48 80 b3 e4 f5 24 f5 > 25 22 af <---cut---> > 40 01 00 00 01 00 00 00 >>> > 40 04 01 00 08 00 00 00 >>> > ec168_rw_udev: usb_control_msg failed :-110 > 40 04 00 00 06 02 00 00 >>> > dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design' in warm state. > dvb-usb: will pass the complete MPEG2 transport stream to the software > demuxer. DVB: registering new adapter (E3C EC168 DVB-T USB2.0 reference > design) ec168_ec100_frontend_attach: > DVB: registering adapter 0 frontend 0 (E3C EC100 DVB-T)... > ec168_mxl5003s_tuner_attach: > MXL5005S: Attached at address 0xc6 > dvb-usb: E3C EC168 DVB-T USB2.0 reference design successfully initialized > and connected. ec168_probe: interface:1 > ec168_identify_state: > c0 01 00 00 01 00 01 00 <<< 01 > ec168_identify_state: reply:01 > dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design' in warm state. > dvb-usb: will pass the complete MPEG2 transport stream to the software > demuxer. DVB: registering new adapter (E3C EC168 DVB-T USB2.0 reference > design) ec168_ec100_frontend_attach: > DVB: registering adapter 1 frontend 0 (E3C EC100 DVB-T)... > ec168_mxl5003s_tuner_attach: > MXL5005S: Attached at address 0xc6 > dvb-usb: E3C EC168 DVB-T USB2.0 reference design successfully initialized > and connected. USB-Id: 18b4:1689 Card name: Sinovideo SV DVB-T 3420B If I can help with testing, just let me know. Regards, Jo -- 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: disable v4l2-ctl logging --log-status in /var/log/messages
> Hello, > > Is it possible to disable v4l2-ctl aplication logging into > /var/log/messages. > I am using it to control and monitor my PVR 150 cards and every time I > run v4l2-ctl -d /dev/video0 --log-status all output is logged into > /var/log/messages and some other linux log files. All --log-status does is to tell the driver to show it's status in the kernel log for debugging purposes. It cannot and should not be relied upon for monitoring/controlling a driver. What do you need it for anyway? 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 2/4] pcm990 baseboard: add camera bus width switch setting
On Thu, 12 Mar 2009, Sascha Hauer wrote:
> On Thu, Mar 12, 2009 at 09:40:46AM +0100, Guennadi Liakhovetski wrote:
> > One more thing I noticed while looking at your patch 3/4:
> >
> > > +static int pcm990_camera_set_bus_param(struct device *dev,
> > > + unsigned long flags)
> > > +{
> > > + if (gpio_bus_switch <= 0)
> > > + return 0;
> > > +
> > > + if (flags & SOCAM_DATAWIDTH_8)
> > > + gpio_set_value(NR_BUILTIN_GPIO + 1, 1);
> > > + else
> > > + gpio_set_value(NR_BUILTIN_GPIO + 1, 0);
> >
> > Originally the logic here was "only if flags == SOCAM_DATAWIDTH_8, switch
> > to 8 bits, otherwise do 10 bits. I.e., if flags == SOCAM_DATAWIDTH_8 |
> > SOCAM_DATAWIDTH_10, it would still do the default (and wider) 10 bits. Do
> > you have any reason to change that logic?
>
> I was not aware that I changed any logic. I thought I would get here
> with only one of the SOCAM_DATAWIDTH_* set. Isn't it a bug when we get
> here with more than one width flags set?
>
> The mt9v022 driver has this in set_bus_param:
>
> >
> > /* Only one width bit may be set */
> > if (!is_power_of_2(width_flag))
> > return -EINVAL;
> >
>
> And I think it makes sense.
Ok, then, could you, please add the same test to mt9m001? And, as I
mentioned in a comment to 3/4, please, return an error if switching is
requested but unsupported.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
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
disable v4l2-ctl logging --log-status in /var/log/messages
Hello, Is it possible to disable v4l2-ctl aplication logging into /var/log/messages. I am using it to control and monitor my PVR 150 cards and every time I run v4l2-ctl -d /dev/video0 --log-status all output is logged into /var/log/messages and some other linux log files. Best Regards, Gregor -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] mt9m001: allow setting of bus width from board code
On Wed, 11 Mar 2009, Sascha Hauer wrote:
> This patch removes the phytec specific setting of the bus width
> and switches to the more generic query_bus_param/set_bus_param
> hooks
>
> Signed-off-by: Sascha Hauer
> ---
> drivers/media/video/Kconfig |7 --
> drivers/media/video/mt9m001.c | 130 +---
> 2 files changed, 30 insertions(+), 107 deletions(-)
>
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index 19cf3b8..5fc1531 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -728,13 +728,6 @@ config SOC_CAMERA_MT9M001
> This driver supports MT9M001 cameras from Micron, monochrome
> and colour models.
>
> -config MT9M001_PCA9536_SWITCH
> - bool "pca9536 datawidth switch for mt9m001"
> - depends on SOC_CAMERA_MT9M001 && GENERIC_GPIO
> - help
> - Select this if your MT9M001 camera uses a PCA9536 I2C GPIO
> - extender to switch between 8 and 10 bit datawidth modes
> -
> config SOC_CAMERA_MT9M111
> tristate "mt9m111 and mt9m112 support"
> depends on SOC_CAMERA && I2C
> diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c
> index c1bf75e..112c612 100644
> --- a/drivers/media/video/mt9m001.c
> +++ b/drivers/media/video/mt9m001.c
> @@ -75,7 +75,6 @@ struct mt9m001 {
> int model; /* V4L2_IDENT_MT9M001* codes from v4l2-chip-ident.h */
> int switch_gpio;
> unsigned char autoexposure;
> - unsigned char datawidth;
> };
>
> static int reg_read(struct soc_camera_device *icd, const u8 reg)
> @@ -181,90 +180,17 @@ static int mt9m001_stop_capture(struct
> soc_camera_device *icd)
> return 0;
> }
>
> -static int bus_switch_request(struct mt9m001 *mt9m001,
> - struct soc_camera_link *icl)
> -{
> -#ifdef CONFIG_MT9M001_PCA9536_SWITCH
> - int ret;
> - unsigned int gpio = icl->gpio;
> -
> - if (gpio_is_valid(gpio)) {
> - /* We have a data bus switch. */
> - ret = gpio_request(gpio, "mt9m001");
> - if (ret < 0) {
> - dev_err(&mt9m001->client->dev, "Cannot get GPIO %u\n",
> - gpio);
> - return ret;
> - }
> -
> - ret = gpio_direction_output(gpio, 0);
> - if (ret < 0) {
> - dev_err(&mt9m001->client->dev,
> - "Cannot set GPIO %u to output\n", gpio);
> - gpio_free(gpio);
> - return ret;
> - }
> - }
> -
> - mt9m001->switch_gpio = gpio;
> -#else
> - mt9m001->switch_gpio = -EINVAL;
> -#endif
> - return 0;
> -}
> -
> -static void bus_switch_release(struct mt9m001 *mt9m001)
> -{
> -#ifdef CONFIG_MT9M001_PCA9536_SWITCH
> - if (gpio_is_valid(mt9m001->switch_gpio))
> - gpio_free(mt9m001->switch_gpio);
> -#endif
> -}
> -
> -static int bus_switch_act(struct mt9m001 *mt9m001, int go8bit)
> -{
> -#ifdef CONFIG_MT9M001_PCA9536_SWITCH
> - if (!gpio_is_valid(mt9m001->switch_gpio))
> - return -ENODEV;
> -
> - gpio_set_value_cansleep(mt9m001->switch_gpio, go8bit);
> - return 0;
> -#else
> - return -ENODEV;
> -#endif
> -}
> -
> -static int bus_switch_possible(struct mt9m001 *mt9m001)
> -{
> -#ifdef CONFIG_MT9M001_PCA9536_SWITCH
> - return gpio_is_valid(mt9m001->switch_gpio);
> -#else
> - return 0;
> -#endif
> -}
> -
> static int mt9m001_set_bus_param(struct soc_camera_device *icd,
>unsigned long flags)
> {
> struct mt9m001 *mt9m001 = container_of(icd, struct mt9m001, icd);
> - unsigned int width_flag = flags & SOCAM_DATAWIDTH_MASK;
> - int ret;
> + struct soc_camera_link *icl = mt9m001->client->dev.platform_data;
>
> /* Flags validity verified in test_bus_param */
>
> - if ((mt9m001->datawidth != 10 && (width_flag == SOCAM_DATAWIDTH_10)) ||
> - (mt9m001->datawidth != 9 && (width_flag == SOCAM_DATAWIDTH_9)) ||
> - (mt9m001->datawidth != 8 && (width_flag == SOCAM_DATAWIDTH_8))) {
> - /* Well, we actually only can do 10 or 8 bits... */
> - if (width_flag == SOCAM_DATAWIDTH_9)
> - return -EINVAL;
> - ret = bus_switch_act(mt9m001,
> - width_flag == SOCAM_DATAWIDTH_8);
> - if (ret < 0)
> - return ret;
> -
> - mt9m001->datawidth = width_flag == SOCAM_DATAWIDTH_8 ? 8 : 10;
> - }
> + if (icl->set_bus_param)
> + return icl->set_bus_param(&mt9m001->client->dev,
> + flags & SOCAM_DATAWIDTH_MASK);
Not quite. Look at the original code. If no change is requested - just
return 0. If a change is requested, but switching is impossible - return
an error - and this is not, what you are doing in 2/4, please fix. So, you
might still want to preserve ".d
Re: [PULL] http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
> On Wed, 11 Mar 2009 11:25:20 -0400 > Devin Heitmueller wrote: > >> Hello Mauro, >> >> Please pull from: >> >> http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2 >> >> for the following: >> >> xc5000: fix bug for hybrid xc5000 devices with IF other than 5380 >> au8522: rename the au8522.c source file >> au8522: move shared state and common functions into a separate header >> files >> au8522: fix register read/write high bits >> au8522: power down the digital demod when not in use >> au8522: make use of hybrid framework so analog/digital demod can share >> state >> au8522: add support for analog side of demodulator >> au0828: add support for analog functionality in bridge >> au0828: workaround a bug in the au0828 i2c handling >> au0828: add analog profile for the HVR-850 >> au8522: add mutex protecting use of hybrid state >> au0828: Rework the way the analog video binding occurs >> tveeprom: add the xc5000 tuner to the tveeprom definition >> au0828: advertise only NTSC-M (as opposed to all NTSC standards) >> au0828: disable VBI code since it doesn't yet work >> au0828: fix i2c enumeration bug >> au0828: make register debug lines easier to read >> au0828: make g_chip_ident call work properly >> au0828: properly handle missing analog USB endpoint >> au0828: properly handle non-existent analog inputs >> au0828: fix panic on disconnect if analog initialization failed >> au0828: Convert to use v4l2_device/subdev framework Hi Devin, Can you also do the last bit of the v4l2_device/subdev conversion by actually using the subdev callbacks (replace au0828_call_i2c_clients with v4l2_device_call_all), removing attach_inform and detach_inform (already deprecated in 2.6.29) and in au8522_decoder.c replacing v4l2-i2c-drv-legacy.h by v4l2-i2c-drv.h and removing the au8522_command. Basically, when you compile against 2.6.29 you shouldn't see any 'deprecated' warnings! I also suggest renaming au8522_decoder.c to just au8522.c, like all the other i2c modules. Regards, Hans >> >> Cheers, >> >> Devin >> > > > Hi Devin, > > There's a bug on your patch series: see this: > > Those are the locations of au8522 files at Kernel's tree: > drivers/media/dvb/frontends/au8522.h > drivers/media/dvb/frontends/au8522_dig.c > drivers/media/dvb/frontends/au8522_priv.h > drivers/media/video/au8522_decoder.c > > And those are the Makefile rules for au8522.h on > drivers/media/dvb/frontends/Makefile: > > au8522-objs = au8522_dig.o au8522_decoder.o > obj-$(CONFIG_DVB_AU8522) += au8522.o > > When you're compiling the out-of-tree version, everything works OK, but, > for > in-tree compilation, au8522_decoder won't be compiled, since the file will > be > in the wrong dir. > > If I'm understanding well, this chip has two functions: it is a dvb > frontend > and an analog video/audio demodulator, right? > > One solution would be to have all those files in the same directory. > However, > au8522_decoder doesn't fit well on dvb/frontends. It is also not a tuner, > otherwise common/tuners would be another better place. > > Another alternative would be to create two kconfig rules (and two separate > modules), being one for au8522_decoder and another for the frontend, since > they > are, in fact, two different things. > > I suspect,however, that compiling just one or another would break > compilation. > So, we need to create some sort of rules that will warrant that both > modules > will be compiled at the same time. This is not an easy task, since we > cannot > add "depends on", since frontends are compiled by using "select". So, we > will > need to re-design the Kconfig rules to use depends on instead of select > (well, > this is something good, anyway, since the usage of "select" is something > that > should be avoided, according with Kbuild docs). > > I'll keep reviewing the patch series. Maybe I'll merge it, but, in this > case, > I'll need to blacklist the module until we found a solution, or find a way > to > allow my -git trees to compile. > > 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 > -- 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: SDIO stack patch
On Thu, 12 Mar 2009 02:00:34 -0700 (PDT) Uri Shkolnik wrote: > > Hi, > > I have a question regarding patching kernel files which reside outside the > 'drivers/media' scope. > > The SMS device can use SPI and SDIO host interfaces (among others). > > Both those drivers' sources require some patching. > > The SDIO stack has been patched by Pierre Ossman himself (maintainer of > MMC/SD/SDIO stack) back in summer 2008. > Pierre asked that those patches will be committed via the LinuxTV's path. > > The SPP patches had been written in Siano (very small patch). > > > My questions: > > 1) When re-creating the patches (both are quite old, and probably outdated > regarding the kernel version which has been used back then), which kernel > version should I use for the diff? The last one: 2.6.29-rc*-git* > 2) Since the V4L hg does not contain those files, should I supply - > A) The entire updated sources files (only) > B) Only the patches (like it done with v4l's files) > C) Both The easiest way, is just to specify at v4l/versions.txt what's the minimal version for it to compile (2.6.29, for example). Then, you just send us the v4l stuff, and be sure that it will compile fine against that version. 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 2/4] pcm990 baseboard: add camera bus width switch setting
On Thu, Mar 12, 2009 at 09:40:46AM +0100, Guennadi Liakhovetski wrote:
> One more thing I noticed while looking at your patch 3/4:
>
> > +static int pcm990_camera_set_bus_param(struct device *dev,
> > + unsigned long flags)
> > +{
> > + if (gpio_bus_switch <= 0)
> > + return 0;
> > +
> > + if (flags & SOCAM_DATAWIDTH_8)
> > + gpio_set_value(NR_BUILTIN_GPIO + 1, 1);
> > + else
> > + gpio_set_value(NR_BUILTIN_GPIO + 1, 0);
>
> Originally the logic here was "only if flags == SOCAM_DATAWIDTH_8, switch
> to 8 bits, otherwise do 10 bits. I.e., if flags == SOCAM_DATAWIDTH_8 |
> SOCAM_DATAWIDTH_10, it would still do the default (and wider) 10 bits. Do
> you have any reason to change that logic?
I was not aware that I changed any logic. I thought I would get here
with only one of the SOCAM_DATAWIDTH_* set. Isn't it a bug when we get
here with more than one width flags set?
The mt9v022 driver has this in set_bus_param:
>
> /* Only one width bit may be set */
> if (!is_power_of_2(width_flag))
> return -EINVAL;
>
And I think it makes sense.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
SDIO stack patch
Hi, I have a question regarding patching kernel files which reside outside the 'drivers/media' scope. The SMS device can use SPI and SDIO host interfaces (among others). Both those drivers' sources require some patching. The SDIO stack has been patched by Pierre Ossman himself (maintainer of MMC/SD/SDIO stack) back in summer 2008. Pierre asked that those patches will be committed via the LinuxTV's path. The SPP patches had been written in Siano (very small patch). My questions: 1) When re-creating the patches (both are quite old, and probably outdated regarding the kernel version which has been used back then), which kernel version should I use for the diff? 2) Since the V4L hg does not contain those files, should I supply - A) The entire updated sources files (only) B) Only the patches (like it done with v4l's files) C) Both Best regard, Uri -- 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://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Wed, 11 Mar 2009 11:25:20 -0400 Devin Heitmueller wrote: > Hello Mauro, > > Please pull from: > > http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2 > > for the following: > > xc5000: fix bug for hybrid xc5000 devices with IF other than 5380 > au8522: rename the au8522.c source file > au8522: move shared state and common functions into a separate header files > au8522: fix register read/write high bits > au8522: power down the digital demod when not in use > au8522: make use of hybrid framework so analog/digital demod can share state > au8522: add support for analog side of demodulator > au0828: add support for analog functionality in bridge > au0828: workaround a bug in the au0828 i2c handling > au0828: add analog profile for the HVR-850 > au8522: add mutex protecting use of hybrid state > au0828: Rework the way the analog video binding occurs > tveeprom: add the xc5000 tuner to the tveeprom definition > au0828: advertise only NTSC-M (as opposed to all NTSC standards) > au0828: disable VBI code since it doesn't yet work > au0828: fix i2c enumeration bug > au0828: make register debug lines easier to read > au0828: make g_chip_ident call work properly > au0828: properly handle missing analog USB endpoint > au0828: properly handle non-existent analog inputs > au0828: fix panic on disconnect if analog initialization failed > au0828: Convert to use v4l2_device/subdev framework > > Cheers, > > Devin > Hi Devin, There's a bug on your patch series: see this: Those are the locations of au8522 files at Kernel's tree: drivers/media/dvb/frontends/au8522.h drivers/media/dvb/frontends/au8522_dig.c drivers/media/dvb/frontends/au8522_priv.h drivers/media/video/au8522_decoder.c And those are the Makefile rules for au8522.h on drivers/media/dvb/frontends/Makefile: au8522-objs = au8522_dig.o au8522_decoder.o obj-$(CONFIG_DVB_AU8522) += au8522.o When you're compiling the out-of-tree version, everything works OK, but, for in-tree compilation, au8522_decoder won't be compiled, since the file will be in the wrong dir. If I'm understanding well, this chip has two functions: it is a dvb frontend and an analog video/audio demodulator, right? One solution would be to have all those files in the same directory. However, au8522_decoder doesn't fit well on dvb/frontends. It is also not a tuner, otherwise common/tuners would be another better place. Another alternative would be to create two kconfig rules (and two separate modules), being one for au8522_decoder and another for the frontend, since they are, in fact, two different things. I suspect,however, that compiling just one or another would break compilation. So, we need to create some sort of rules that will warrant that both modules will be compiled at the same time. This is not an easy task, since we cannot add "depends on", since frontends are compiled by using "select". So, we will need to re-design the Kconfig rules to use depends on instead of select (well, this is something good, anyway, since the usage of "select" is something that should be avoided, according with Kbuild docs). I'll keep reviewing the patch series. Maybe I'll merge it, but, in this case, I'll need to blacklist the module until we found a solution, or find a way to allow my -git trees to compile. 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 2/4] pcm990 baseboard: add camera bus width switch setting
One more thing I noticed while looking at your patch 3/4:
> +static int pcm990_camera_set_bus_param(struct device *dev,
> + unsigned long flags)
> +{
> + if (gpio_bus_switch <= 0)
> + return 0;
> +
> + if (flags & SOCAM_DATAWIDTH_8)
> + gpio_set_value(NR_BUILTIN_GPIO + 1, 1);
> + else
> + gpio_set_value(NR_BUILTIN_GPIO + 1, 0);
Originally the logic here was "only if flags == SOCAM_DATAWIDTH_8, switch
to 8 bits, otherwise do 10 bits. I.e., if flags == SOCAM_DATAWIDTH_8 |
SOCAM_DATAWIDTH_10, it would still do the default (and wider) 10 bits. Do
you have any reason to change that logic?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] pcm990 baseboard: add camera bus width switch setting
On Thu, Mar 12, 2009 at 09:31:55AM +0100, Guennadi Liakhovetski wrote:
> On Wed, 11 Mar 2009, Sascha Hauer wrote:
>
> > Some Phytec cameras have a I2C GPIO expander which allows it to
> > switch between different sensor bus widths. This was previously
> > handled in the camera driver. Since handling of this switch
> > varies on several boards the cameras are used on, the board
> > support seems a better place to handle the switch
> >
> > Signed-off-by: Sascha Hauer
> > ---
> > arch/arm/mach-pxa/pcm990-baseboard.c | 50
> > +++--
> > 1 files changed, 41 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
> > b/arch/arm/mach-pxa/pcm990-baseboard.c
> > index 34841c7..e9feb89 100644
> > --- a/arch/arm/mach-pxa/pcm990-baseboard.c
> > +++ b/arch/arm/mach-pxa/pcm990-baseboard.c
> > @@ -381,14 +381,46 @@ static struct pca953x_platform_data pca9536_data = {
> > .gpio_base = NR_BUILTIN_GPIO + 1,
> > };
> >
> > -static struct soc_camera_link iclink[] = {
> > - {
> > - .bus_id = 0, /* Must match with the camera ID above */
> > - .gpio = NR_BUILTIN_GPIO + 1,
> > - }, {
> > - .bus_id = 0, /* Must match with the camera ID above */
> > - .gpio = -ENXIO,
> > +static int gpio_bus_switch;
> > +
> > +static int pcm990_camera_set_bus_param(struct device *dev,
>
> The prototype will change to use "struct soc_camera_link *"
OK
>
> > + unsigned long flags)
> > +{
> > + if (gpio_bus_switch <= 0)
> > + return 0;
> > +
> > + if (flags & SOCAM_DATAWIDTH_8)
> > + gpio_set_value(NR_BUILTIN_GPIO + 1, 1);
> > + else
> > + gpio_set_value(NR_BUILTIN_GPIO + 1, 0);
>
> You wanted to use gpio_bus_switch for these.
s/wanted to/should/?
OK
>
> > +
> > + return 0;
> > +}
> > +
> > +static unsigned long pcm990_camera_query_bus_param(struct device *dev)
> > +{
> > + int ret;
> > +
> > + if (!gpio_bus_switch) {
> > + ret = gpio_request(NR_BUILTIN_GPIO + 1, "camera");
> > + if (!ret) {
> > + gpio_bus_switch = NR_BUILTIN_GPIO + 1;
> > + gpio_direction_output(gpio_bus_switch, 0);
> > + } else
> > + gpio_bus_switch = -1;
>
> This is a purely internal variable, so, I won't insist if you disagree,
> but, I think, a scheme "non-negative for a valid value or a negative error
> code" looks better, cf.
>
> If you want to initialize a structure with an invalid GPIO number, use
> some negative number (perhaps "-EINVAL"); that will never be valid.
>
> (Documentation/gpio.txt). "-1" looks like you're going to perform
> calculations with it.
OK
>
> > }
> > +
> > + if (gpio_bus_switch > 0)
> > + return SOCAM_DATAWIDTH_8 | SOCAM_DATAWIDTH_10;
> > + else
> > + return SOCAM_DATAWIDTH_10;
> > +}
> > +
> > +static struct soc_camera_link iclink = {
> > + .bus_id = 0, /* Must match with the camera ID above */
> > + .query_bus_param = pcm990_camera_query_bus_param,
> > + .set_bus_param = pcm990_camera_set_bus_param,
> > + .gpio = NR_BUILTIN_GPIO + 1,
>
> There's one patch missing in your patch series:
>
> [PATCH 5/5] Remove the "gpio" member from the struct soc_camera_link
OK. I saw this member is unnecessary now and forgot it a minute later...
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] pcm990 baseboard: add camera bus width switch setting
On Wed, 11 Mar 2009, Sascha Hauer wrote:
> Some Phytec cameras have a I2C GPIO expander which allows it to
> switch between different sensor bus widths. This was previously
> handled in the camera driver. Since handling of this switch
> varies on several boards the cameras are used on, the board
> support seems a better place to handle the switch
>
> Signed-off-by: Sascha Hauer
> ---
> arch/arm/mach-pxa/pcm990-baseboard.c | 50 +++--
> 1 files changed, 41 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
> b/arch/arm/mach-pxa/pcm990-baseboard.c
> index 34841c7..e9feb89 100644
> --- a/arch/arm/mach-pxa/pcm990-baseboard.c
> +++ b/arch/arm/mach-pxa/pcm990-baseboard.c
> @@ -381,14 +381,46 @@ static struct pca953x_platform_data pca9536_data = {
> .gpio_base = NR_BUILTIN_GPIO + 1,
> };
>
> -static struct soc_camera_link iclink[] = {
> - {
> - .bus_id = 0, /* Must match with the camera ID above */
> - .gpio = NR_BUILTIN_GPIO + 1,
> - }, {
> - .bus_id = 0, /* Must match with the camera ID above */
> - .gpio = -ENXIO,
> +static int gpio_bus_switch;
> +
> +static int pcm990_camera_set_bus_param(struct device *dev,
The prototype will change to use "struct soc_camera_link *"
> + unsigned long flags)
> +{
> + if (gpio_bus_switch <= 0)
> + return 0;
> +
> + if (flags & SOCAM_DATAWIDTH_8)
> + gpio_set_value(NR_BUILTIN_GPIO + 1, 1);
> + else
> + gpio_set_value(NR_BUILTIN_GPIO + 1, 0);
You wanted to use gpio_bus_switch for these.
> +
> + return 0;
> +}
> +
> +static unsigned long pcm990_camera_query_bus_param(struct device *dev)
> +{
> + int ret;
> +
> + if (!gpio_bus_switch) {
> + ret = gpio_request(NR_BUILTIN_GPIO + 1, "camera");
> + if (!ret) {
> + gpio_bus_switch = NR_BUILTIN_GPIO + 1;
> + gpio_direction_output(gpio_bus_switch, 0);
> + } else
> + gpio_bus_switch = -1;
This is a purely internal variable, so, I won't insist if you disagree,
but, I think, a scheme "non-negative for a valid value or a negative error
code" looks better, cf.
If you want to initialize a structure with an invalid GPIO number, use
some negative number (perhaps "-EINVAL"); that will never be valid.
(Documentation/gpio.txt). "-1" looks like you're going to perform
calculations with it.
> }
> +
> + if (gpio_bus_switch > 0)
> + return SOCAM_DATAWIDTH_8 | SOCAM_DATAWIDTH_10;
> + else
> + return SOCAM_DATAWIDTH_10;
> +}
> +
> +static struct soc_camera_link iclink = {
> + .bus_id = 0, /* Must match with the camera ID above */
> + .query_bus_param = pcm990_camera_query_bus_param,
> + .set_bus_param = pcm990_camera_set_bus_param,
> + .gpio = NR_BUILTIN_GPIO + 1,
There's one patch missing in your patch series:
[PATCH 5/5] Remove the "gpio" member from the struct soc_camera_link
> };
>
> /* Board I2C devices. */
> @@ -399,10 +431,10 @@ static struct i2c_board_info __initdata
> pcm990_i2c_devices[] = {
> .platform_data = &pca9536_data,
> }, {
> I2C_BOARD_INFO("mt9v022", 0x48),
> - .platform_data = &iclink[0], /* With extender */
> + .platform_data = &iclink, /* With extender */
> }, {
> I2C_BOARD_INFO("mt9m001", 0x5d),
> - .platform_data = &iclink[0], /* With extender */
> + .platform_data = &iclink, /* With extender */
> },
> };
> #endif /* CONFIG_VIDEO_PXA27x ||CONFIG_VIDEO_PXA27x_MODULE */
> --
> 1.5.6.5
>
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
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/4] soc-camera: add board hook to specify the buswidth for camera sensors
On Wed, 11 Mar 2009, Sascha Hauer wrote:
> Camera sensors have a native bus width say support, but on some
> boards not all sensor data lines are connected to the image
> interface and thus support a different bus width than the sensors
> native one. Some boards even have a bus driver which dynamically
> switches between different bus widths with a GPIO.
>
> This patch adds a hook which board code can use to support different
> bus widths.
>
> Signed-off-by: Sascha Hauer
> ---
> include/media/soc_camera.h |6 ++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
> index 7440d92..d68959c 100644
> --- a/include/media/soc_camera.h
> +++ b/include/media/soc_camera.h
> @@ -100,6 +100,12 @@ struct soc_camera_link {
> /* Optional callbacks to power on or off and reset the sensor */
> int (*power)(struct device *, int);
> int (*reset)(struct device *);
> + /* some platforms may support different data widths than the sensors
> + * native ones due to different data line routing. Let the board code
> + * overwrite the width flags.
> + */
Please, format the comment according to CodingStyle:
/*
* some
* comment
*/
I know, I have some non-conforming (similar to yours) comments in
soc-camera .c files, but this header is "clean" so far:-) Let's keep it
that way.
> + int (*set_bus_param)(struct device *, unsigned long flags);
> + unsigned long (*query_bus_param)(struct device *);
Wouldn't the first parameter of type "struct soc_camera_link *" make more
sense? I'll also then change .power and .reset similarly.
> };
>
> static inline struct soc_camera_device *to_soc_camera_dev(struct device *dev)
> --
> 1.5.6.5
>
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
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: [linuxtv-commits] [hg:v4l-dvb] Add cx231xx USB driver
On Thursday 12 March 2009 02:40:09 Patch from Sri Deevi wrote: > The patch number 10954 was added via Mauro Carvalho Chehab > to http://linuxtv.org/hg/v4l-dvb master development > tree. > > Kernel patches in this development tree may be modified to be backward > compatible with older kernels. Compatibility modifications will be > removed before inclusion into the mainstream Kernel > > If anyone has any objections, please let us know by sending a message to: > Linux Media Mailing List Mauro, What the hell??! Since when does a big addition like this get merged without undergoing a public review? I've been working my ass off converting drivers to the new i2c API and v4l2_subdev structures and here you merge a big driver that uses old-style (which will lead to 'deprecated' warnings when compiling with 2.6.29, BTW), where the driver writes directly to i2c modules instead of adding a proper i2c module for them. And what are 'colibri', 'flatrion' and 'hammerhead' anyway? Are they integrated devices of the cx231xx? Can they be used separately in other products as well? So yes, I have objections. At the minimum it should be converted first to use v4l2_device/v4l2_subdev and I need more information on the new i2c devices so I can tell whether the code for those should be split off into separate i2c modules. Not to mention that I want to have the time to review this code more closely. Sorry Sri, this isn't your fault. Regards, Hans > > -- > > From: Sri Deevi > Add cx231xx USB driver > > > Signed-off-by: Srinivasa Deevi > Signed-off-by: Mauro Carvalho Chehab > > > --- > > linux/drivers/media/video/Kconfig|2 > linux/drivers/media/video/Makefile |1 > linux/drivers/media/video/cx231xx/Kconfig| 35 > linux/drivers/media/video/cx231xx/Makefile | 15 > linux/drivers/media/video/cx231xx/cx231xx-audio.c| 664 ++ > linux/drivers/media/video/cx231xx/cx231xx-avcore.c | 2289 ++ > linux/drivers/media/video/cx231xx/cx231xx-cards.c| 947 > linux/drivers/media/video/cx231xx/cx231xx-conf-reg.h | 491 ++ > linux/drivers/media/video/cx231xx/cx231xx-core.c | 1197 + > linux/drivers/media/video/cx231xx/cx231xx-dvb.c | 566 ++ > linux/drivers/media/video/cx231xx/cx231xx-i2c.c | 580 ++ > linux/drivers/media/video/cx231xx/cx231xx-input.c| 267 + > linux/drivers/media/video/cx231xx/cx231xx-reg.h | 1574 +++ > linux/drivers/media/video/cx231xx/cx231xx-vbi.c | 697 +++ > linux/drivers/media/video/cx231xx/cx231xx-vbi.h | 61 > linux/drivers/media/video/cx231xx/cx231xx-video.c| 2440 +++ > linux/drivers/media/video/cx231xx/cx231xx.h | 771 +++ > linux/include/linux/i2c-id.h |1 > 18 files changed, 12598 insertions(+) > > > > --- > > Patch is available at: > http://linuxtv.org/hg/v4l-dvb/rev/1d836224ecbf5ce6cf60696b4590630a92a4587 >5 > > ___ > linuxtv-commits mailing list > linuxtv-comm...@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linuxtv-commits -- 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
