Re: How to use saa7134 gpio via gpio-sysfs?
Hi!
Am Montag, den 11.01.2010, 11:59 -0700 schrieb Gordon Smith:
> I need to bit twiddle saa7134 gpio pins from userspace.
> To use gpio-sysfs, I need a "GPIO number" to export each pin, but I
> do not know how to find such a number.
>
> Card is RTD Embedded Technologies VFG7350 [card=72,autodetected].
> GPIO uses pcf8574 chip.
> Kernel is 2.6.30.
>
> gpio-sysfs creates
> /sys/class/gpio/export
> /sys/class/gpio/import
> but no gpio entries so far.
>
> >From dmesg ("gpiotracking=1")
> saa7133[0]: board init: gpio is 1
> saa7133[0]: gpio: mode=0x000 in=0x4011000 out=0x000 [pre-init]
> saa7133[1]: board init: gpio is 1
> saa7133[1]: gpio: mode=0x000 in=0x4010f00 out=0x000 [pre-init]
>
> How may I find each "GPIO number" for this board?
>
> Thanks in advance for any help.
There are 28 (0-27) gpio pins on each saa713x chip.
Documentation about possible use cases is publicly available via
nxp.com.
You can do what ever you want with them, but to export them to userland
seems to be a very bad idea to me.
Likely soon some "advanced hackers" will damage ;) all kind of hardware
around and others will claim it as being a GNU/Linux problem within the
same time such stuff appears, and of course it will.
In fact these days, only one to three users are involved hacking on a
board. It is much cheaper for all involved to give the serial number of
those than to imagine every day, what all could happen.
For all others not yet active, avoiding any worst case through
contributing is the way to go.
For the rest, we likely should have some fund, for worst cases, payed by
themselves.
Cheers,
Hermann
--
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 00/11] add linux driver for chip TLG2300
Em Wed, 09 Dec 2009 17:08:27 -0200 Mauro Carvalho Chehab escreveu: Huang Shijie wrote: The TLG2300 is a chip of Telegent System. It support analog tv,DVB-T and radio in a single chip. The chip has been used in several dongles, such as aeromax DH-9000: http://www.b2bdvb.com/dh-9000.htm You can get more info from: [1] http://www.telegent.com/ [2] http://www.telegent.com/press/2009Sept14_CSI.html Huang Shijie (10): add maitainers for tlg2300 add readme file for tlg2300 add Kconfig and Makefile for tlg2300 add header files for tlg2300 add the generic file add video file for tlg2300 add vbi code for tlg2300 add audio support for tlg2300 add DVB-T support for tlg2300 add FM support for tlg2300 Ok, finished reviewing it. Patches 01, 02 and 04 seems ok to me. You didn't sent a patch 03. Patch 05 will likely need some changes (the headers) due to some reviews I did on the other patches. The other patches need some adjustments, as commented on separate emails. Hi Huang, Happy new year! Happy new year :) Had you finish fixing the pointed issues? My email system had a little problem, and losted some important emails. I missed your email unfortunately. :( I will do the change according your email as soon as possible. I will sent out the new version when i finish it. Cheers, Mauro best regards Huang Shijie -- 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
system hangs when loading b2c2-flexcop-pci.ko
Hello, Steps to reproduce with dmesg output: # echo "7 4 1 7" > /proc/sys/kernel/printk # modprobe b2c2-flexcop b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully # insmod b2c2-flexcop-pci.ko debug=0x1f flexcop-pci: will use the HW PID filter flexcop-pci: card revision 2 b2c2_flexcop_pci :04:00.0: PCI INT A -> GSI 21 (level, low) -> IRQ 21 new wr: 208: new wr: 210: c259b2ff Then it hangs and I have to reset the machine. This seems to be the beginning of the communication with the Flexcop chip. The commands are executed in flexcop_reset(). System: DVB PCI card: TechniSat DIGITAL SkyStar 2 Rev. 2.8B with Chip FLEXCOP IIB Is there a difference between Rev. 2.8 and 2.8B? Only 2.8 is referenced in the sources. Mainboard: D945GCLF2 with Intel Atom 330 OS: Gentoo Linux 64-Bit Kernel: Linus' git tree (after 2.6.33-rc3), but it didn't work at my first try, which is some time ago, with a Gentoo Kernel based on the stable 2.6.27.12. # lspci -vnn 04:00.0 Network controller [0280]: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card [13d0:2103] (rev 02) Subsystem: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card [13d0:2103] Flags: bus master, slow devsel, latency 32, IRQ 10 Memory at 5010 (32-bit, non-prefetchable) [size=64K] I/O ports at 1000 [size=32] Kernel modules: b2c2-flexcop-pci I hope someone has an idea or can give me a tip how to find the problem. Markus -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - v4 4/4] DaVinci-vpfe-capture-converting-ccdc-drivers-to-platform-drivers
m-kariche...@ti.com writes:
> From: Muralidharan Karicheri
>
> Following are the changes from v3 :-
>
> - added ccdc clocks through clk_add_alias() calls
All the 'changes from vN' comments are not really relevant to the
final git history. Please add them after the '---' as well. Thanks.
> This combines the two patches sent earlier to change the clock configuration
> and converting ccdc drivers to platform drivers. This has updated comments
> against v2 of these patches. Two new clocks "master" and "slave" are defined
> for ccdc driver
> as per comments from Kevin Hilman.
This also isn't really relevant for the final git history.
> This adds platform code for ccdc driver on DM355 and DM6446.
And this isn't an adequate description of all the things happening in
this patch. You need to describe not only what is happening but why
for all of the below:
- new CCDC platform_devices
- new clock aliases for CCDC clocks
- pin-mux setup hook now in platform_data
Kevin
> Reviewed-by: Vaibhav Hiremath
> Reviewed-by: Kevin Hilman
> Reviewed-by: Hans Verkuil
>
> Signed-off-by: Muralidharan Karicheri
> ---
> Re-sending the patches based on Kevin's comments.
> Applies to Linus tree
> arch/arm/mach-davinci/dm355.c | 43 +++
> arch/arm/mach-davinci/dm644x.c | 21 ++-
> 2 files changed, 50 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
> index dedf4d4..d84e854 100644
> --- a/arch/arm/mach-davinci/dm355.c
> +++ b/arch/arm/mach-davinci/dm355.c
> @@ -125,7 +125,6 @@ static struct clk vpss_slave_clk = {
> .lpsc = DAVINCI_LPSC_VPSSSLV,
> };
>
> -
> static struct clk clkout1_clk = {
> .name = "clkout1",
> .parent = &pll1_aux_clk,
> @@ -665,6 +664,17 @@ static struct platform_device dm355_asp1_device = {
> .resource = dm355_asp1_resources,
> };
>
> +static void dm355_ccdc_setup_pinmux(void)
> +{
> + davinci_cfg_reg(DM355_VIN_PCLK);
> + davinci_cfg_reg(DM355_VIN_CAM_WEN);
> + davinci_cfg_reg(DM355_VIN_CAM_VD);
> + davinci_cfg_reg(DM355_VIN_CAM_HD);
> + davinci_cfg_reg(DM355_VIN_YIN_EN);
> + davinci_cfg_reg(DM355_VIN_CINL_EN);
> + davinci_cfg_reg(DM355_VIN_CINH_EN);
> +}
> +
> static struct resource dm355_vpss_resources[] = {
> {
> /* VPSS BL Base address */
> @@ -701,6 +711,10 @@ static struct resource vpfe_resources[] = {
> .end= IRQ_VDINT1,
> .flags = IORESOURCE_IRQ,
> },
> +};
> +
> +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
> +static struct resource dm355_ccdc_resource[] = {
> /* CCDC Base address */
> {
> .flags = IORESOURCE_MEM,
> @@ -708,8 +722,18 @@ static struct resource vpfe_resources[] = {
> .end= 0x01c70600 + 0x1ff,
> },
> };
> +static struct platform_device dm355_ccdc_dev = {
> + .name = "dm355_ccdc",
> + .id = -1,
> + .num_resources = ARRAY_SIZE(dm355_ccdc_resource),
> + .resource = dm355_ccdc_resource,
> + .dev = {
> + .dma_mask = &vpfe_capture_dma_mask,
> + .coherent_dma_mask = DMA_BIT_MASK(32),
> + .platform_data = dm355_ccdc_setup_pinmux,
> + },
> +};
>
> -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
> static struct platform_device vpfe_capture_dev = {
> .name = CAPTURE_DRV_NAME,
> .id = -1,
> @@ -857,20 +881,13 @@ static int __init dm355_init_devices(void)
> if (!cpu_is_davinci_dm355())
> return 0;
>
> + /* Add ccdc clock aliases */
> + clk_add_alias("master", dm355_ccdc_dev.name, "vpss_master", NULL);
> + clk_add_alias("slave", dm355_ccdc_dev.name, "vpss_master", NULL);
> davinci_cfg_reg(DM355_INT_EDMA_CC);
> platform_device_register(&dm355_edma_device);
> platform_device_register(&dm355_vpss_device);
> - /*
> - * setup Mux configuration for vpfe input and register
> - * vpfe capture platform device
> - */
> - davinci_cfg_reg(DM355_VIN_PCLK);
> - davinci_cfg_reg(DM355_VIN_CAM_WEN);
> - davinci_cfg_reg(DM355_VIN_CAM_VD);
> - davinci_cfg_reg(DM355_VIN_CAM_HD);
> - davinci_cfg_reg(DM355_VIN_YIN_EN);
> - davinci_cfg_reg(DM355_VIN_CINL_EN);
> - davinci_cfg_reg(DM355_VIN_CINH_EN);
> + platform_device_register(&dm355_ccdc_dev);
> platform_device_register(&vpfe_capture_dev);
>
> return 0;
> diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
> index 2cd0081..92aeb56 100644
> --- a/arch/arm/mach-davinci/dm644x.c
> +++ b/arch/arm/mach-davinci/dm644x.c
> @@ -612,6 +612,11 @@ static struct resource vpfe_resources[] = {
> .end= IRQ_VDINT1,
> .flags = IORESOURCE_IRQ,
> },
> +};
> +
> +static u64 vpfe_capture_dma_mask = DMA
Re: [PATCH - v4 2/4] V4L-vpfe-capture-converting dm355 ccdc driver to a platform driver
m-kariche...@ti.com writes:
> From: Muralidharan Karicheri
>
> Updated based on Kevin's comments on clock configuration.
This part belongs after the '---'
> The ccdc now uses a generic name for clocks. "master" and "slave". On
> individual platforms
> these clocks will inherit from the platform specific clock. This will allow
> re-use of
> the driver for the same IP across different SoCs.
>
> Following are the changes done:-
> 1) clocks are configured using generic clock names
> 2) converting the driver to a platform driver
> 3) cleanup - consolidate all static variables inside a structure,
> ccdc_cfg
>
> Reviewed-by: Kevin Hilman
> Reviewed-by: Vaibhav Hiremath
> Reviewed-by: Hans Verkuil
>
> Signed-off-by: Hans Verkuil
> Signed-off-by: Muralidharan Karicheri
> ---
> Rebased to latest linux-next tree
> Applies to linux-next branch of v4l-dvb
> drivers/media/video/davinci/dm355_ccdc.c | 409
> +++---
> 1 files changed, 256 insertions(+), 153 deletions(-)
>
[...]
> -static int __init dm355_ccdc_init(void)
> +static int __init dm355_ccdc_probe(struct platform_device *pdev)
> {
> - printk(KERN_NOTICE "dm355_ccdc_init\n");
> - if (vpfe_register_ccdc_device(&ccdc_hw_dev) < 0)
> - return -1;
> - printk(KERN_NOTICE "%s is registered with vpfe.\n",
> - ccdc_hw_dev.name);
> + void (*setup_pinmux)(void);
> + struct resource *res;
> + int status = 0;
> +
> + /*
> + * first try to register with vpfe. If not correct platform, then we
> + * don't have to iomap
> + */
> + status = vpfe_register_ccdc_device(&ccdc_hw_dev);
> + if (status < 0)
> + return status;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res) {
> + status = -ENODEV;
> + goto fail_nores;
> + }
> +
> + res = request_mem_region(res->start, resource_size(res), res->name);
> + if (!res) {
> + status = -EBUSY;
> + goto fail_nores;
> + }
> +
> + ccdc_cfg.base_addr = ioremap_nocache(res->start, resource_size(res));
> + if (!ccdc_cfg.base_addr) {
> + status = -ENOMEM;
> + goto fail_nomem;
> + }
> +
> + /* Get and enable Master clock */
> + ccdc_cfg.mclk = clk_get(&pdev->dev, "master");
> + if (NULL == ccdc_cfg.mclk) {
This should be an IS_ERR() check, not a NULL pointer check.
> + status = -ENODEV;
> + goto fail_nomap;
> + }
> + if (clk_enable(ccdc_cfg.mclk)) {
> + status = -ENODEV;
> + goto fail_mclk;
> + }
> +
> + /* Get and enable Slave clock */
> + ccdc_cfg.sclk = clk_get(&pdev->dev, "slave");
> + if (NULL == ccdc_cfg.sclk) {
IS_ERR()
All the same comments for the dm644x version.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - v4 1/4] V4L-vpfe_capture-remove-clock and platform code
m-kariche...@ti.com writes:
> From: Muralidharan Karicheri
>
> This combines the two patches sent earlier to change the clock configuration
> and converting ccdc drivers to platform drivers. This has updated comments
> against v1 of these patches.
This part is also not relevant to the git history, and should be after the '---'
> In this patch, the clock configuration is moved to ccdc driver since clocks
> are configured for ccdc. Also adding proper error codes for ccdc register
> function and removing the ccdc memory resource handling.
Also, this doesn't accuratly reflect the changes done in the patch.
Here the clock configuration isn't moved, it's removed. You should
mention it being removed here and added to platform-specific code in
subsequent patches.
Sorry to be so nit-picky about the comments, but having a well-written
and descriptive changelog is extremely importanty. For the benefit of
reading the git history later, and also for those of us less familiar
with the details of these drivers, we rely heavily on a good changelog.
Kevin
> Reviewed-by: Vaibhav Hiremath
> Reviewed-by: Kevin Hilman
> Reviewed-by: Hans Verkuil
>
> Signed-off-by: Hans Verkuil
> Signed-off-by: Muralidharan Karicheri
> ---
> Rebased to latest linux-next tree
> Applies to linux-next tree of v4l-dvb
> drivers/media/video/davinci/vpfe_capture.c | 131
> +++-
> 1 files changed, 13 insertions(+), 118 deletions(-)
>
> diff --git a/drivers/media/video/davinci/vpfe_capture.c
> b/drivers/media/video/davinci/vpfe_capture.c
> index de22bc9..885cd54 100644
> --- a/drivers/media/video/davinci/vpfe_capture.c
> +++ b/drivers/media/video/davinci/vpfe_capture.c
> @@ -107,9 +107,6 @@ struct ccdc_config {
> int vpfe_probed;
> /* name of ccdc device */
> char name[32];
> - /* for storing mem maps for CCDC */
> - int ccdc_addr_size;
> - void *__iomem ccdc_addr;
> };
>
> /* data structures */
> @@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
> BUG_ON(!dev->hw_ops.set_image_window);
> BUG_ON(!dev->hw_ops.get_image_window);
> BUG_ON(!dev->hw_ops.get_line_length);
> - BUG_ON(!dev->hw_ops.setfbaddr);
> BUG_ON(!dev->hw_ops.getfid);
>
> mutex_lock(&ccdc_lock);
> @@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
> *dev)
>* walk through it during vpfe probe
>*/
> printk(KERN_ERR "vpfe capture not initialized\n");
> - ret = -1;
> + ret = -EFAULT;
> goto unlock;
> }
>
> if (strcmp(dev->name, ccdc_cfg->name)) {
> /* ignore this ccdc */
> - ret = -1;
> + ret = -EINVAL;
> goto unlock;
> }
>
> if (ccdc_dev) {
> printk(KERN_ERR "ccdc already registered\n");
> - ret = -1;
> + ret = -EINVAL;
> goto unlock;
> }
>
> ccdc_dev = dev;
> - dev->hw_ops.set_ccdc_base(ccdc_cfg->ccdc_addr,
> - ccdc_cfg->ccdc_addr_size);
> unlock:
> mutex_unlock(&ccdc_lock);
> return ret;
> @@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
> return vpfe_dev;
> }
>
> -static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
> -{
> - struct vpfe_config *vpfe_cfg = vpfe_dev->cfg;
> -
> - clk_disable(vpfe_cfg->vpssclk);
> - clk_put(vpfe_cfg->vpssclk);
> - clk_disable(vpfe_cfg->slaveclk);
> - clk_put(vpfe_cfg->slaveclk);
> - v4l2_info(vpfe_dev->pdev->driver,
> - "vpfe vpss master & slave clocks disabled\n");
> -}
> -
> -static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
> -{
> - struct vpfe_config *vpfe_cfg = vpfe_dev->cfg;
> - int ret = -ENOENT;
> -
> - vpfe_cfg->vpssclk = clk_get(vpfe_dev->pdev, "vpss_master");
> - if (NULL == vpfe_cfg->vpssclk) {
> - v4l2_err(vpfe_dev->pdev->driver, "No clock defined for"
> - "vpss_master\n");
> - return ret;
> - }
> -
> - if (clk_enable(vpfe_cfg->vpssclk)) {
> - v4l2_err(vpfe_dev->pdev->driver,
> - "vpfe vpss master clock not enabled\n");
> - goto out;
> - }
> - v4l2_info(vpfe_dev->pdev->driver,
> - "vpfe vpss master clock enabled\n");
> -
> - vpfe_cfg->slaveclk = clk_get(vpfe_dev->pdev, "vpss_slave");
> - if (NULL == vpfe_cfg->slaveclk) {
> - v4l2_err(vpfe_dev->pdev->driver,
> - "No clock defined for vpss slave\n");
> - goto out;
> - }
> -
> - if (clk_enable(vpfe_cfg->slaveclk)) {
> - v4l2_err(vpfe_dev->pdev->driver,
> - "vpfe vpss slave clock not enabled\n");
> - goto out;
> - }
> - v4l2_info(vpfe_dev->pdev->driver, "vpfe vpss slave clock enabled\n");
> - return 0;
> -out:
> - if (vpfe_cfg->vp
Re: [PULL] http://linuxtv.org/hg/~awalls/v4l-dvb-misc
On Sun, 2010-01-10 at 11:52 -0200, Mauro Carvalho Chehab wrote:
> Andy Walls wrote:
> > On Sun, 2010-01-10 at 09:35 -0200, Mauro Carvalho Chehab wrote:
> >> Andy Walls wrote:
> >>> Mauro,
> >>>
> >>> If no one has any objections, please pull from
> >>>
> >>> http://linuxtv.org/hg/~awalls/v4l-dvb-misc
> >>>
> >>> for the following 12 changesets.
> >>>
> >>> Of note:
> >>> 02-04 are from Jean Delvare and fix up the cx23885 i2c routines
> >>> 05-17 and 12 add and use a new v4l2_subdev core op for configuring I/O
> >>> pin muxes
> >>> 08-10 are some minor cx23885 ir fixes noted when trying to get the TeVii
> >>> S470 working
> >>>
> >>> 10/12: cx23885: Convert from struct card_ir to struct cx23885_ir_input
> >>> for IR Rx
> >>> http://linuxtv.org/hg/~awalls/v4l-dvb-misc?cmd=changeset;node=aa62944baa92
> >> Hmm... This doesn't sound right:
> >>
> >> +struct cx23885_ir_input {
> >> + struct input_dev*dev;
> >> + struct ir_input_state ir;
> >> + charname[48];
> >> + charphys[48];
> >> +
> >> + /* Cooked code processing */
> >> + int start; /* Allowed start symbols */
> >> + u32 addr;/* Expected remote address */
> >> + u32 last_code; /* last good cooked code seen
> >> */
> >> + int key_timeout; /* ms until we force a key up
> >> */
> >> + struct timer_list timer_keyup; /* timer for key release */
> >> +
> >> + /* Raw code collection and construction */
> >> + int active; /* building code */
> >> + int last_bit; /* last bit seen */
> >> + u32 code; /* code under construction */
> >> +};
> >>
> >> Why are you creating a name[] and phys[] chars here? It should be using
> >> the names already
> >> defined at struct input_dev.
> >
> > Well two reasons:
> >
> > 1. That's what the previous, common "card ir" struct did. (Not a good
> > reason of course.) When I needed to reimplement specific fields (in
> > anticipation of NEC decoding for the TeVii S470) I just carried them
> > over.
> >
> > 2. The strings in the old card ir struct were too short: the card names
> > in cx23885-cards.c are pretty long and would get truncated.
> >
> >
> > I'll reexamine if the strings in input_dev are long enough to do the
> > job, and get back to you.
>
> The better is to rely on input_dev stuff, since they can easily be used by
> ir-core
> sysfs to provide device naming for loading keytables from userspace during
> udev
> handling.
OK. Hold off on that whole pull request. That whole pull request was
the stable/ready part of what is in my cx23885-ir tree.
However, I just found what was wrong with my cx23885-ir tree code for IR
from an actual CX23885 chip. I'll just rework and update the whole
series, once I also get a change prepared and tested for the TeVii S470.
Regards,
Andy
> 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] media: video/cx18, fix potential null dereference
On Sun, 2010-01-10 at 09:56 +0100, Jiri Slaby wrote:
> Stanse found a potential null dereference in cx18_dvb_start_feed
> and cx18_dvb_stop_feed. There is a check for stream being NULL,
> but it is dereferenced earlier. Move the dereference after the
> check.
>
> Signed-off-by: Jiri Slaby
Reviewed-by: Andy Walls
Acked-by: Andy Walls
Regards,
Andy
> ---
> drivers/media/video/cx18/cx18-dvb.c | 18 ++
> 1 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/video/cx18/cx18-dvb.c
> b/drivers/media/video/cx18/cx18-dvb.c
> index 71ad2d1..0ad5b63 100644
> --- a/drivers/media/video/cx18/cx18-dvb.c
> +++ b/drivers/media/video/cx18/cx18-dvb.c
> @@ -213,10 +213,14 @@ static int cx18_dvb_start_feed(struct dvb_demux_feed
> *feed)
> {
> struct dvb_demux *demux = feed->demux;
> struct cx18_stream *stream = (struct cx18_stream *) demux->priv;
> - struct cx18 *cx = stream->cx;
> + struct cx18 *cx;
> int ret;
> u32 v;
>
> + if (!stream)
> + return -EINVAL;
> +
> + cx = stream->cx;
> CX18_DEBUG_INFO("Start feed: pid = 0x%x index = %d\n",
> feed->pid, feed->index);
>
> @@ -253,9 +257,6 @@ static int cx18_dvb_start_feed(struct dvb_demux_feed
> *feed)
> if (!demux->dmx.frontend)
> return -EINVAL;
>
> - if (!stream)
> - return -EINVAL;
> -
> mutex_lock(&stream->dvb.feedlock);
> if (stream->dvb.feeding++ == 0) {
> CX18_DEBUG_INFO("Starting Transport DMA\n");
> @@ -279,13 +280,14 @@ static int cx18_dvb_stop_feed(struct dvb_demux_feed
> *feed)
> {
> struct dvb_demux *demux = feed->demux;
> struct cx18_stream *stream = (struct cx18_stream *)demux->priv;
> - struct cx18 *cx = stream->cx;
> + struct cx18 *cx;
> int ret = -EINVAL;
>
> - CX18_DEBUG_INFO("Stop feed: pid = 0x%x index = %d\n",
> - feed->pid, feed->index);
> -
> if (stream) {
> + cx = stream->cx;
> + CX18_DEBUG_INFO("Stop feed: pid = 0x%x index = %d\n",
> + feed->pid, feed->index);
> +
> mutex_lock(&stream->dvb.feedlock);
> if (--stream->dvb.feeding == 0) {
> CX18_DEBUG_INFO("Stopping Transport DMA\n");
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v4 4/4] DaVinci-vpfe-capture-converting-ccdc-drivers-to-platform-drivers
Kevin,
Reworked the patches and sent it again.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
>-Original Message-
>From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
>Sent: Monday, January 11, 2010 4:36 PM
>To: Karicheri, Muralidharan
>Cc: linux-media@vger.kernel.org; mche...@infradead.org; hverk...@xs4all.nl;
>davinci-linux-open-sou...@linux.davincidsp.com
>Subject: Re: [PATCH - v4 4/4] DaVinci-vpfe-capture-converting-ccdc-drivers-
>to-platform-drivers
>
>m-kariche...@ti.com writes:
>
>> From: Muralidharan Karicheri
>>
>> Re-sending the patches based on Kevin's comments.
>> Following are the changes from v3 :-
>>
>> - replaced CLK entries with clk_add_alias() calls
>> - removed unused vpss_master and vpss_slave entries
>>
>> This combines the two patches sent earlier to change the clock
>configuration
>> and converting ccdc drivers to platform drivers. This has updated
>comments
>> against v2 of these patches. Two new clocks "master" and "slave" are
>defined for ccdc driver
>> as per comments from Kevin Hilman.
>>
>> This adds platform code for ccdc driver on DM355 and DM6446.
>>
>> Reviewed-by: Vaibhav Hiremath
>> Reviewed-by: Kevin Hilman
>> Reviewed-by: Hans Verkuil
>>
>> Signed-off-by: Muralidharan Karicheri
>> ---
>> Applies to Linus tree
>> arch/arm/mach-davinci/dm355.c | 58 --
>-
>> arch/arm/mach-davinci/dm644x.c | 36 ++---
>> 2 files changed, 50 insertions(+), 44 deletions(-)
>>
>> diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-
>davinci/dm355.c
>> index dedf4d4..b4d0396 100644
>> --- a/arch/arm/mach-davinci/dm355.c
>> +++ b/arch/arm/mach-davinci/dm355.c
>> @@ -112,20 +112,6 @@ static struct clk vpss_dac_clk = {
>> .lpsc = DM355_LPSC_VPSS_DAC,
>> };
>>
>> -static struct clk vpss_master_clk = {
>> -.name = "vpss_master",
>> -.parent = &pll1_sysclk4,
>> -.lpsc = DAVINCI_LPSC_VPSSMSTR,
>> -.flags = CLK_PSC,
>> -};
>> -
>> -static struct clk vpss_slave_clk = {
>> -.name = "vpss_slave",
>> -.parent = &pll1_sysclk4,
>> -.lpsc = DAVINCI_LPSC_VPSSSLV,
>> -};
>
>I suggested removing the duplicate, not removing them both.
>
>These nodes should stay, and the clock aliases should be created as
>aliaes of these nodes (which can be enabled/disabled) and not the PLL
>outputs directly.
>
>> static struct clk clkout1_clk = {
>> .name = "clkout1",
>> .parent = &pll1_aux_clk,
>> @@ -345,8 +331,6 @@ static struct davinci_clk dm355_clks[] = {
>> CLK(NULL, "pll1_aux", &pll1_aux_clk),
>> CLK(NULL, "pll1_sysclkbp", &pll1_sysclkbp),
>> CLK(NULL, "vpss_dac", &vpss_dac_clk),
>> -CLK(NULL, "vpss_master", &vpss_master_clk),
>> -CLK(NULL, "vpss_slave", &vpss_slave_clk),
>> CLK(NULL, "clkout1", &clkout1_clk),
>> CLK(NULL, "clkout2", &clkout2_clk),
>> CLK(NULL, "pll2", &pll2_clk),
>> @@ -665,6 +649,17 @@ static struct platform_device dm355_asp1_device = {
>> .resource = dm355_asp1_resources,
>> };
>>
>> +static void dm355_ccdc_setup_pinmux(void)
>> +{
>> +davinci_cfg_reg(DM355_VIN_PCLK);
>> +davinci_cfg_reg(DM355_VIN_CAM_WEN);
>> +davinci_cfg_reg(DM355_VIN_CAM_VD);
>> +davinci_cfg_reg(DM355_VIN_CAM_HD);
>> +davinci_cfg_reg(DM355_VIN_YIN_EN);
>> +davinci_cfg_reg(DM355_VIN_CINL_EN);
>> +davinci_cfg_reg(DM355_VIN_CINH_EN);
>> +}
>> +
>> static struct resource dm355_vpss_resources[] = {
>> {
>> /* VPSS BL Base address */
>> @@ -701,6 +696,10 @@ static struct resource vpfe_resources[] = {
>> .end= IRQ_VDINT1,
>> .flags = IORESOURCE_IRQ,
>> },
>> +};
>> +
>> +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
>> +static struct resource dm355_ccdc_resource[] = {
>> /* CCDC Base address */
>> {
>> .flags = IORESOURCE_MEM,
>> @@ -708,8 +707,18 @@ static struct resource vpfe_resources[] = {
>> .end= 0x01c70600 + 0x1ff,
>> },
>> };
>> +static struct platform_device dm355_ccdc_dev = {
>> +.name = "dm355_ccdc",
>> +.id = -1,
>> +.num_resources = ARRAY_SIZE(dm355_ccdc_resource),
>> +.resource = dm355_ccdc_resource,
>> +.dev = {
>> +.dma_mask = &vpfe_capture_dma_mask,
>> +.coherent_dma_mask = DMA_BIT_MASK(32),
>> +.platform_data = dm355_ccdc_setup_pinmux,
>> +},
>> +};
>>
>> -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
>> static struct platform_device vpfe_capture_dev = {
>> .name = CAPTURE_DRV_NAME,
>> .id = -1,
>> @@ -857,20 +866,13 @@ static int __init dm355_init_devices(void)
>> if (!cpu_is_davinci_dm355())
>> return 0;
>>
>> +/* Add ccdc clock aliases */
>> +clk_add_alias("master", dm355_ccdc_dev.name, "pll1_sysclk4", NUL
[PATCH - v4 3/4] V4L-vpfe-capture-converting-dm644x-driver to a platform driver
From: Muralidharan Karicheri
Updated based on Kevin's comments on clock configuration.
The ccdc now uses a generic name for clocks. master and slave. On individual
platforms
these clocks will inherit from the platform specific clock. This will allow
re-use of
the driver for the same IP across different SoCs.
Following are the changes done:-
1) clocks are configured using generic clock names
2) converting the driver to a platform driver
3) cleanup - consolidate all static variables inside a structure,
ccdc_cfg
Reviewed-by: Kevin Hilman
Reviewed-by: Vaibhav Hiremath
Reviewed-by: Hans Verkuil
Signed-off-by: Hans Verkuil
Signed-off-by: Muralidharan Karicheri
---
Rebased to latest linux-next tree
Applies to linux-next tree of v4l-dvb
drivers/media/video/davinci/dm644x_ccdc.c | 360 ++---
1 files changed, 224 insertions(+), 136 deletions(-)
diff --git a/drivers/media/video/davinci/dm644x_ccdc.c
b/drivers/media/video/davinci/dm644x_ccdc.c
index d5fa193..7e35269 100644
--- a/drivers/media/video/davinci/dm644x_ccdc.c
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -37,8 +37,11 @@
#include
#include
#include
+#include
+
#include
#include
+
#include "dm644x_ccdc_regs.h"
#include "ccdc_hw_device.h"
@@ -46,32 +49,44 @@ MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("CCDC Driver for DM6446");
MODULE_AUTHOR("Texas Instruments");
-static struct device *dev;
-
-/* Object for CCDC raw mode */
-static struct ccdc_params_raw ccdc_hw_params_raw = {
- .pix_fmt = CCDC_PIXFMT_RAW,
- .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
- .win = CCDC_WIN_VGA,
- .fid_pol = VPFE_PINPOL_POSITIVE,
- .vd_pol = VPFE_PINPOL_POSITIVE,
- .hd_pol = VPFE_PINPOL_POSITIVE,
- .config_params = {
- .data_sz = CCDC_DATA_10BITS,
+static struct ccdc_oper_config {
+ struct device *dev;
+ /* CCDC interface type */
+ enum vpfe_hw_if_type if_type;
+ /* Raw Bayer configuration */
+ struct ccdc_params_raw bayer;
+ /* YCbCr configuration */
+ struct ccdc_params_ycbcr ycbcr;
+ /* Master clock */
+ struct clk *mclk;
+ /* slave clock */
+ struct clk *sclk;
+ /* ccdc base address */
+ void __iomem *base_addr;
+} ccdc_cfg = {
+ /* Raw configurations */
+ .bayer = {
+ .pix_fmt = CCDC_PIXFMT_RAW,
+ .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+ .win = CCDC_WIN_VGA,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .config_params = {
+ .data_sz = CCDC_DATA_10BITS,
+ },
+ },
+ .ycbcr = {
+ .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+ .frm_fmt = CCDC_FRMFMT_INTERLACED,
+ .win = CCDC_WIN_PAL,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .bt656_enable = 1,
+ .pix_order = CCDC_PIXORDER_CBYCRY,
+ .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
},
-};
-
-/* Object for CCDC ycbcr mode */
-static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
- .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
- .frm_fmt = CCDC_FRMFMT_INTERLACED,
- .win = CCDC_WIN_PAL,
- .fid_pol = VPFE_PINPOL_POSITIVE,
- .vd_pol = VPFE_PINPOL_POSITIVE,
- .hd_pol = VPFE_PINPOL_POSITIVE,
- .bt656_enable = 1,
- .pix_order = CCDC_PIXORDER_CBYCRY,
- .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
};
#define CCDC_MAX_RAW_YUV_FORMATS 2
@@ -84,25 +99,15 @@ static u32 ccdc_raw_bayer_pix_formats[] =
static u32 ccdc_raw_yuv_pix_formats[] =
{V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YUYV};
-static void *__iomem ccdc_base_addr;
-static int ccdc_addr_size;
-static enum vpfe_hw_if_type ccdc_if_type;
-
/* register access routines */
static inline u32 regr(u32 offset)
{
- return __raw_readl(ccdc_base_addr + offset);
+ return __raw_readl(ccdc_cfg.base_addr + offset);
}
static inline void regw(u32 val, u32 offset)
{
- __raw_writel(val, ccdc_base_addr + offset);
-}
-
-static void ccdc_set_ccdc_base(void *addr, int size)
-{
- ccdc_base_addr = addr;
- ccdc_addr_size = size;
+ __raw_writel(val, ccdc_cfg.base_addr + offset);
}
static void ccdc_enable(int flag)
@@ -132,7 +137,7 @@ void ccdc_setwin(struct v4l2_rect *image_win,
int vert_start, vert_nr_lines;
int val = 0, mid_img = 0;
- dev_dbg(dev, "\nStarting ccdc_setwin...");
+ dev_dbg(ccdc_cfg.dev, "\nStarting ccdc_setwin...");
/*
* ppc - per pixel count. indicates how many pixels per cell
* output to SDRAM. example, for ycbcr, it is one y and one c, so 2.
@@ -171,7 +176,7 @@ void ccdc_setwin(struct v4l2_rect *image_win,
regw((vert_start << CCDC_VERT_STAR
[PATCH - v4 2/4] V4L-vpfe-capture-converting dm355 ccdc driver to a platform driver
From: Muralidharan Karicheri
Updated based on Kevin's comments on clock configuration.
The ccdc now uses a generic name for clocks. "master" and "slave". On
individual platforms
these clocks will inherit from the platform specific clock. This will allow
re-use of
the driver for the same IP across different SoCs.
Following are the changes done:-
1) clocks are configured using generic clock names
2) converting the driver to a platform driver
3) cleanup - consolidate all static variables inside a structure,
ccdc_cfg
Reviewed-by: Kevin Hilman
Reviewed-by: Vaibhav Hiremath
Reviewed-by: Hans Verkuil
Signed-off-by: Hans Verkuil
Signed-off-by: Muralidharan Karicheri
---
Rebased to latest linux-next tree
Applies to linux-next branch of v4l-dvb
drivers/media/video/davinci/dm355_ccdc.c | 409 +++---
1 files changed, 256 insertions(+), 153 deletions(-)
diff --git a/drivers/media/video/davinci/dm355_ccdc.c
b/drivers/media/video/davinci/dm355_ccdc.c
index 3143900..fc716ed 100644
--- a/drivers/media/video/davinci/dm355_ccdc.c
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -37,8 +37,11 @@
#include
#include
#include
+#include
+
#include
#include
+
#include "dm355_ccdc_regs.h"
#include "ccdc_hw_device.h"
@@ -46,67 +49,75 @@ MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("CCDC Driver for DM355");
MODULE_AUTHOR("Texas Instruments");
-static struct device *dev;
-
-/* Object for CCDC raw mode */
-static struct ccdc_params_raw ccdc_hw_params_raw = {
- .pix_fmt = CCDC_PIXFMT_RAW,
- .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
- .win = CCDC_WIN_VGA,
- .fid_pol = VPFE_PINPOL_POSITIVE,
- .vd_pol = VPFE_PINPOL_POSITIVE,
- .hd_pol = VPFE_PINPOL_POSITIVE,
- .gain = {
- .r_ye = 256,
- .gb_g = 256,
- .gr_cy = 256,
- .b_mg = 256
- },
- .config_params = {
- .datasft = 2,
- .data_sz = CCDC_DATA_10BITS,
- .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
- .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
- .alaw = {
- .gama_wd = 2,
+static struct ccdc_oper_config {
+ struct device *dev;
+ /* CCDC interface type */
+ enum vpfe_hw_if_type if_type;
+ /* Raw Bayer configuration */
+ struct ccdc_params_raw bayer;
+ /* YCbCr configuration */
+ struct ccdc_params_ycbcr ycbcr;
+ /* Master clock */
+ struct clk *mclk;
+ /* slave clock */
+ struct clk *sclk;
+ /* ccdc base address */
+ void __iomem *base_addr;
+} ccdc_cfg = {
+ /* Raw configurations */
+ .bayer = {
+ .pix_fmt = CCDC_PIXFMT_RAW,
+ .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+ .win = CCDC_WIN_VGA,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .gain = {
+ .r_ye = 256,
+ .gb_g = 256,
+ .gr_cy = 256,
+ .b_mg = 256
},
- .blk_clamp = {
- .sample_pixel = 1,
- .dc_sub = 25
- },
- .col_pat_field0 = {
- .olop = CCDC_GREEN_BLUE,
- .olep = CCDC_BLUE,
- .elop = CCDC_RED,
- .elep = CCDC_GREEN_RED
- },
- .col_pat_field1 = {
- .olop = CCDC_GREEN_BLUE,
- .olep = CCDC_BLUE,
- .elop = CCDC_RED,
- .elep = CCDC_GREEN_RED
+ .config_params = {
+ .datasft = 2,
+ .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
+ .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
+ .alaw = {
+ .gama_wd = 2,
+ },
+ .blk_clamp = {
+ .sample_pixel = 1,
+ .dc_sub = 25
+ },
+ .col_pat_field0 = {
+ .olop = CCDC_GREEN_BLUE,
+ .olep = CCDC_BLUE,
+ .elop = CCDC_RED,
+ .elep = CCDC_GREEN_RED
+ },
+ .col_pat_field1 = {
+ .olop = CCDC_GREEN_BLUE,
+ .olep = CCDC_BLUE,
+ .elop = CCDC_RED,
+ .elep = CCDC_GREEN_RED
+ },
},
},
+ /* YCbCr configuration */
+ .ycbcr = {
+ .win = CCDC_WIN_PAL,
+ .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+ .frm_fmt = CCDC_FRMFMT_INTERLACED,
[PATCH - v4 1/4] V4L-vpfe_capture-remove-clock and platform code
From: Muralidharan Karicheri
This combines the two patches sent earlier to change the clock configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v1 of these patches.
In this patch, the clock configuration is moved to ccdc driver since clocks
are configured for ccdc. Also adding proper error codes for ccdc register
function and removing the ccdc memory resource handling.
Reviewed-by: Vaibhav Hiremath
Reviewed-by: Kevin Hilman
Reviewed-by: Hans Verkuil
Signed-off-by: Hans Verkuil
Signed-off-by: Muralidharan Karicheri
---
Rebased to latest linux-next tree
Applies to linux-next tree of v4l-dvb
drivers/media/video/davinci/vpfe_capture.c | 131 +++-
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
- /* for storing mem maps for CCDC */
- int ccdc_addr_size;
- void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
BUG_ON(!dev->hw_ops.set_image_window);
BUG_ON(!dev->hw_ops.get_image_window);
BUG_ON(!dev->hw_ops.get_line_length);
- BUG_ON(!dev->hw_ops.setfbaddr);
BUG_ON(!dev->hw_ops.getfid);
mutex_lock(&ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR "vpfe capture not initialized\n");
- ret = -1;
+ ret = -EFAULT;
goto unlock;
}
if (strcmp(dev->name, ccdc_cfg->name)) {
/* ignore this ccdc */
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR "ccdc already registered\n");
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
ccdc_dev = dev;
- dev->hw_ops.set_ccdc_base(ccdc_cfg->ccdc_addr,
- ccdc_cfg->ccdc_addr_size);
unlock:
mutex_unlock(&ccdc_lock);
return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
- struct vpfe_config *vpfe_cfg = vpfe_dev->cfg;
-
- clk_disable(vpfe_cfg->vpssclk);
- clk_put(vpfe_cfg->vpssclk);
- clk_disable(vpfe_cfg->slaveclk);
- clk_put(vpfe_cfg->slaveclk);
- v4l2_info(vpfe_dev->pdev->driver,
-"vpfe vpss master & slave clocks disabled\n");
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
- struct vpfe_config *vpfe_cfg = vpfe_dev->cfg;
- int ret = -ENOENT;
-
- vpfe_cfg->vpssclk = clk_get(vpfe_dev->pdev, "vpss_master");
- if (NULL == vpfe_cfg->vpssclk) {
- v4l2_err(vpfe_dev->pdev->driver, "No clock defined for"
-"vpss_master\n");
- return ret;
- }
-
- if (clk_enable(vpfe_cfg->vpssclk)) {
- v4l2_err(vpfe_dev->pdev->driver,
- "vpfe vpss master clock not enabled\n");
- goto out;
- }
- v4l2_info(vpfe_dev->pdev->driver,
-"vpfe vpss master clock enabled\n");
-
- vpfe_cfg->slaveclk = clk_get(vpfe_dev->pdev, "vpss_slave");
- if (NULL == vpfe_cfg->slaveclk) {
- v4l2_err(vpfe_dev->pdev->driver,
- "No clock defined for vpss slave\n");
- goto out;
- }
-
- if (clk_enable(vpfe_cfg->slaveclk)) {
- v4l2_err(vpfe_dev->pdev->driver,
-"vpfe vpss slave clock not enabled\n");
- goto out;
- }
- v4l2_info(vpfe_dev->pdev->driver, "vpfe vpss slave clock enabled\n");
- return 0;
-out:
- if (vpfe_cfg->vpssclk)
- clk_put(vpfe_cfg->vpssclk);
- if (vpfe_cfg->slaveclk)
- clk_put(vpfe_cfg->slaveclk);
-
- return -1;
-}
-
/*
* vpfe_probe : This function creates device entries by register
* itself to the V4L2 driver and initializes fields of each
@@ -1870,7 +1809,7 @@ static __init int vpfe_probe(struct platform_device *pdev)
if (NULL == pdev->dev.platform_data) {
v4l2_err(pdev->dev.driver, "Unable to get vpfe config\n");
- ret = -ENOENT;
+ ret = -ENODEV;
goto probe_free_dev_mem;
}
@@ -1884,18 +1823,13 @@ static __init int vpfe_probe(struct platform_device
*pdev)
goto probe_free_dev_mem;
[PATCH - v4 4/4] DaVinci-vpfe-capture-converting-ccdc-drivers-to-platform-drivers
From: Muralidharan Karicheri
Following are the changes from v3 :-
- added ccdc clocks through clk_add_alias() calls
This combines the two patches sent earlier to change the clock configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v2 of these patches. Two new clocks "master" and "slave" are defined
for ccdc driver
as per comments from Kevin Hilman.
This adds platform code for ccdc driver on DM355 and DM6446.
Reviewed-by: Vaibhav Hiremath
Reviewed-by: Kevin Hilman
Reviewed-by: Hans Verkuil
Signed-off-by: Muralidharan Karicheri
---
Re-sending the patches based on Kevin's comments.
Applies to Linus tree
arch/arm/mach-davinci/dm355.c | 43 +++
arch/arm/mach-davinci/dm644x.c | 21 ++-
2 files changed, 50 insertions(+), 14 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index dedf4d4..d84e854 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -125,7 +125,6 @@ static struct clk vpss_slave_clk = {
.lpsc = DAVINCI_LPSC_VPSSSLV,
};
-
static struct clk clkout1_clk = {
.name = "clkout1",
.parent = &pll1_aux_clk,
@@ -665,6 +664,17 @@ static struct platform_device dm355_asp1_device = {
.resource = dm355_asp1_resources,
};
+static void dm355_ccdc_setup_pinmux(void)
+{
+ davinci_cfg_reg(DM355_VIN_PCLK);
+ davinci_cfg_reg(DM355_VIN_CAM_WEN);
+ davinci_cfg_reg(DM355_VIN_CAM_VD);
+ davinci_cfg_reg(DM355_VIN_CAM_HD);
+ davinci_cfg_reg(DM355_VIN_YIN_EN);
+ davinci_cfg_reg(DM355_VIN_CINL_EN);
+ davinci_cfg_reg(DM355_VIN_CINH_EN);
+}
+
static struct resource dm355_vpss_resources[] = {
{
/* VPSS BL Base address */
@@ -701,6 +711,10 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm355_ccdc_resource[] = {
/* CCDC Base address */
{
.flags = IORESOURCE_MEM,
@@ -708,8 +722,18 @@ static struct resource vpfe_resources[] = {
.end= 0x01c70600 + 0x1ff,
},
};
+static struct platform_device dm355_ccdc_dev = {
+ .name = "dm355_ccdc",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm355_ccdc_resource),
+ .resource = dm355_ccdc_resource,
+ .dev = {
+ .dma_mask = &vpfe_capture_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = dm355_ccdc_setup_pinmux,
+ },
+};
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
static struct platform_device vpfe_capture_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
@@ -857,20 +881,13 @@ static int __init dm355_init_devices(void)
if (!cpu_is_davinci_dm355())
return 0;
+ /* Add ccdc clock aliases */
+ clk_add_alias("master", dm355_ccdc_dev.name, "vpss_master", NULL);
+ clk_add_alias("slave", dm355_ccdc_dev.name, "vpss_master", NULL);
davinci_cfg_reg(DM355_INT_EDMA_CC);
platform_device_register(&dm355_edma_device);
platform_device_register(&dm355_vpss_device);
- /*
-* setup Mux configuration for vpfe input and register
-* vpfe capture platform device
-*/
- davinci_cfg_reg(DM355_VIN_PCLK);
- davinci_cfg_reg(DM355_VIN_CAM_WEN);
- davinci_cfg_reg(DM355_VIN_CAM_VD);
- davinci_cfg_reg(DM355_VIN_CAM_HD);
- davinci_cfg_reg(DM355_VIN_YIN_EN);
- davinci_cfg_reg(DM355_VIN_CINL_EN);
- davinci_cfg_reg(DM355_VIN_CINH_EN);
+ platform_device_register(&dm355_ccdc_dev);
platform_device_register(&vpfe_capture_dev);
return 0;
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 2cd0081..92aeb56 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -612,6 +612,11 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm644x_ccdc_resource[] = {
+ /* CCDC Base address */
{
.start = 0x01c70400,
.end= 0x01c70400 + 0xff,
@@ -619,7 +624,17 @@ static struct resource vpfe_resources[] = {
},
};
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct platform_device dm644x_ccdc_dev = {
+ .name = "dm644x_ccdc",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_ccdc_resource),
+ .resource = dm644x_ccdc_resource,
+ .dev = {
+ .dma_mask
Re: [PATCH - v4 2/4] V4L-vpfe-capture-converting dm355 ccdc driver to a platform driver
m-kariche...@ti.com writes:
> From: Muralidharan Karicheri
>
> Rebased to latest linux-next tree
>
> Updated based on Kevin's comments on clock configuration.
Since the above comments are useful for reviewers but not for the git
history, the should come after the '---' separator. That way they
are not included in the git history.
Kevin
> The ccdc now uses a generic name for clocks. "master" and "slave". On
> individual platforms
> these clocks will inherit from the platform specific clock. This will allow
> re-use of
> the driver for the same IP across different SoCs.
>
> Following are the changes done:-
> 1) clocks are configured using generic clock names
> 2) converting the driver to a platform driver
> 3) cleanup - consolidate all static variables inside a structure,
> ccdc_cfg
>
> Reviewed-by: Kevin Hilman
> Reviewed-by: Vaibhav Hiremath
> Reviewed-by: Hans Verkuil
>
> Signed-off-by: Hans Verkuil
> Signed-off-by: Muralidharan Karicheri
> ---
> Applies to linux-next branch of v4l-dvb
> drivers/media/video/davinci/dm355_ccdc.c | 409
> +++---
> 1 files changed, 256 insertions(+), 153 deletions(-)
>
> diff --git a/drivers/media/video/davinci/dm355_ccdc.c
> b/drivers/media/video/davinci/dm355_ccdc.c
> index 3143900..fc716ed 100644
> --- a/drivers/media/video/davinci/dm355_ccdc.c
> +++ b/drivers/media/video/davinci/dm355_ccdc.c
> @@ -37,8 +37,11 @@
> #include
> #include
> #include
> +#include
> +
> #include
> #include
> +
> #include "dm355_ccdc_regs.h"
> #include "ccdc_hw_device.h"
>
> @@ -46,67 +49,75 @@ MODULE_LICENSE("GPL");
> MODULE_DESCRIPTION("CCDC Driver for DM355");
> MODULE_AUTHOR("Texas Instruments");
>
> -static struct device *dev;
> -
> -/* Object for CCDC raw mode */
> -static struct ccdc_params_raw ccdc_hw_params_raw = {
> - .pix_fmt = CCDC_PIXFMT_RAW,
> - .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
> - .win = CCDC_WIN_VGA,
> - .fid_pol = VPFE_PINPOL_POSITIVE,
> - .vd_pol = VPFE_PINPOL_POSITIVE,
> - .hd_pol = VPFE_PINPOL_POSITIVE,
> - .gain = {
> - .r_ye = 256,
> - .gb_g = 256,
> - .gr_cy = 256,
> - .b_mg = 256
> - },
> - .config_params = {
> - .datasft = 2,
> - .data_sz = CCDC_DATA_10BITS,
> - .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
> - .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
> - .alaw = {
> - .gama_wd = 2,
> +static struct ccdc_oper_config {
> + struct device *dev;
> + /* CCDC interface type */
> + enum vpfe_hw_if_type if_type;
> + /* Raw Bayer configuration */
> + struct ccdc_params_raw bayer;
> + /* YCbCr configuration */
> + struct ccdc_params_ycbcr ycbcr;
> + /* Master clock */
> + struct clk *mclk;
> + /* slave clock */
> + struct clk *sclk;
> + /* ccdc base address */
> + void __iomem *base_addr;
> +} ccdc_cfg = {
> + /* Raw configurations */
> + .bayer = {
> + .pix_fmt = CCDC_PIXFMT_RAW,
> + .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
> + .win = CCDC_WIN_VGA,
> + .fid_pol = VPFE_PINPOL_POSITIVE,
> + .vd_pol = VPFE_PINPOL_POSITIVE,
> + .hd_pol = VPFE_PINPOL_POSITIVE,
> + .gain = {
> + .r_ye = 256,
> + .gb_g = 256,
> + .gr_cy = 256,
> + .b_mg = 256
> },
> - .blk_clamp = {
> - .sample_pixel = 1,
> - .dc_sub = 25
> - },
> - .col_pat_field0 = {
> - .olop = CCDC_GREEN_BLUE,
> - .olep = CCDC_BLUE,
> - .elop = CCDC_RED,
> - .elep = CCDC_GREEN_RED
> - },
> - .col_pat_field1 = {
> - .olop = CCDC_GREEN_BLUE,
> - .olep = CCDC_BLUE,
> - .elop = CCDC_RED,
> - .elep = CCDC_GREEN_RED
> + .config_params = {
> + .datasft = 2,
> + .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
> + .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
> + .alaw = {
> + .gama_wd = 2,
> + },
> + .blk_clamp = {
> + .sample_pixel = 1,
> + .dc_sub = 25
> + },
> + .col_pat_field0 = {
> + .olop = CCDC_GREEN_BLUE,
> + .olep = CCDC_BLUE,
> + .elop = CCDC_RED,
> + .elep = CCDC_GREEN_RED
> + },
> + .col_pat_field1 = {
> + .olop = CCDC_GREEN_BLUE,
> + .olep = CCDC_BLUE,
> + .elop =
FM radio problem with HVR1120
Hello, I am user of Huappuage HVR1120, and I have problem with radio FM use in linux mode. Distribution OpenSuse11.2 Kernel 2.6.31.8-0.1-desktop Firmware dvb-fe-tda10048-1.0.fw loaded Analog and Digital Television are OK in both Windows and Linux. Windows is using Hauppauge WinTV7 v7.027313 Linux is using Kaffeine v1.0-pre2 for Digital Television Linux is using mplayer for analog TV like: mplayer tv:// -tv driver=v4l2:freq=495.750:norm=SECAM- L:input=0:audiorate=32000:immediatemode=0:alsa:forceaudio:adevice=hw.1,0:width=720:height=576:amode=1 The problem is to listen radio. One radio station is OK at 91.5MHz stereo using WintTV7 in Windows. With Linux, the command used is /usr/bin/radio -c /dev/radio0 in association with sox -t ossdsp -r 32000 -c 2 /dev/dsp1 -t ossdsp /dev/dsp to listen the sound. The result is an unstable frecuency. The station is not tuned. Stereo is permanently switching to mono. The 91.5MHz station is mixed permanently with other stations. How can I check v4l2 ? Do you need dmesg output ? Is this mailing list the right place to solve this problem ? Thank you for your help. Regards, ftape-jlc -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH - v4 4/4] DaVinci-vpfe-capture-converting-ccdc-drivers-to-platform-drivers
m-kariche...@ti.com writes:
> From: Muralidharan Karicheri
>
> Re-sending the patches based on Kevin's comments.
> Following are the changes from v3 :-
>
> - replaced CLK entries with clk_add_alias() calls
> - removed unused vpss_master and vpss_slave entries
>
> This combines the two patches sent earlier to change the clock configuration
> and converting ccdc drivers to platform drivers. This has updated comments
> against v2 of these patches. Two new clocks "master" and "slave" are defined
> for ccdc driver
> as per comments from Kevin Hilman.
>
> This adds platform code for ccdc driver on DM355 and DM6446.
>
> Reviewed-by: Vaibhav Hiremath
> Reviewed-by: Kevin Hilman
> Reviewed-by: Hans Verkuil
>
> Signed-off-by: Muralidharan Karicheri
> ---
> Applies to Linus tree
> arch/arm/mach-davinci/dm355.c | 58 ---
> arch/arm/mach-davinci/dm644x.c | 36 ++---
> 2 files changed, 50 insertions(+), 44 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
> index dedf4d4..b4d0396 100644
> --- a/arch/arm/mach-davinci/dm355.c
> +++ b/arch/arm/mach-davinci/dm355.c
> @@ -112,20 +112,6 @@ static struct clk vpss_dac_clk = {
> .lpsc = DM355_LPSC_VPSS_DAC,
> };
>
> -static struct clk vpss_master_clk = {
> - .name = "vpss_master",
> - .parent = &pll1_sysclk4,
> - .lpsc = DAVINCI_LPSC_VPSSMSTR,
> - .flags = CLK_PSC,
> -};
> -
> -static struct clk vpss_slave_clk = {
> - .name = "vpss_slave",
> - .parent = &pll1_sysclk4,
> - .lpsc = DAVINCI_LPSC_VPSSSLV,
> -};
I suggested removing the duplicate, not removing them both.
These nodes should stay, and the clock aliases should be created as
aliaes of these nodes (which can be enabled/disabled) and not the PLL
outputs directly.
> static struct clk clkout1_clk = {
> .name = "clkout1",
> .parent = &pll1_aux_clk,
> @@ -345,8 +331,6 @@ static struct davinci_clk dm355_clks[] = {
> CLK(NULL, "pll1_aux", &pll1_aux_clk),
> CLK(NULL, "pll1_sysclkbp", &pll1_sysclkbp),
> CLK(NULL, "vpss_dac", &vpss_dac_clk),
> - CLK(NULL, "vpss_master", &vpss_master_clk),
> - CLK(NULL, "vpss_slave", &vpss_slave_clk),
> CLK(NULL, "clkout1", &clkout1_clk),
> CLK(NULL, "clkout2", &clkout2_clk),
> CLK(NULL, "pll2", &pll2_clk),
> @@ -665,6 +649,17 @@ static struct platform_device dm355_asp1_device = {
> .resource = dm355_asp1_resources,
> };
>
> +static void dm355_ccdc_setup_pinmux(void)
> +{
> + davinci_cfg_reg(DM355_VIN_PCLK);
> + davinci_cfg_reg(DM355_VIN_CAM_WEN);
> + davinci_cfg_reg(DM355_VIN_CAM_VD);
> + davinci_cfg_reg(DM355_VIN_CAM_HD);
> + davinci_cfg_reg(DM355_VIN_YIN_EN);
> + davinci_cfg_reg(DM355_VIN_CINL_EN);
> + davinci_cfg_reg(DM355_VIN_CINH_EN);
> +}
> +
> static struct resource dm355_vpss_resources[] = {
> {
> /* VPSS BL Base address */
> @@ -701,6 +696,10 @@ static struct resource vpfe_resources[] = {
> .end= IRQ_VDINT1,
> .flags = IORESOURCE_IRQ,
> },
> +};
> +
> +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
> +static struct resource dm355_ccdc_resource[] = {
> /* CCDC Base address */
> {
> .flags = IORESOURCE_MEM,
> @@ -708,8 +707,18 @@ static struct resource vpfe_resources[] = {
> .end= 0x01c70600 + 0x1ff,
> },
> };
> +static struct platform_device dm355_ccdc_dev = {
> + .name = "dm355_ccdc",
> + .id = -1,
> + .num_resources = ARRAY_SIZE(dm355_ccdc_resource),
> + .resource = dm355_ccdc_resource,
> + .dev = {
> + .dma_mask = &vpfe_capture_dma_mask,
> + .coherent_dma_mask = DMA_BIT_MASK(32),
> + .platform_data = dm355_ccdc_setup_pinmux,
> + },
> +};
>
> -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
> static struct platform_device vpfe_capture_dev = {
> .name = CAPTURE_DRV_NAME,
> .id = -1,
> @@ -857,20 +866,13 @@ static int __init dm355_init_devices(void)
> if (!cpu_is_davinci_dm355())
> return 0;
>
> + /* Add ccdc clock aliases */
> + clk_add_alias("master", dm355_ccdc_dev.name, "pll1_sysclk4", NULL);
> + clk_add_alias("slave", dm355_ccdc_dev.name, "pll1_sysclk4", NULL);
Not quite, see above...
The aliases should be of the vpss nodes, not the PLL outputs which
cannot be enabled/disabled.
Same problem with dm644x below.
Kevin
> davinci_cfg_reg(DM355_INT_EDMA_CC);
> platform_device_register(&dm355_edma_device);
> platform_device_register(&dm355_vpss_device);
> - /*
> - * setup Mux configuration for vpfe input and register
> - * vpfe capture platform device
> - */
> - davinci_cfg_reg(DM355_VIN_PCLK);
> - davinci_cfg_reg(DM355_VIN_CAM_WEN);
> - davinci_cfg_reg(D
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: OK
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Mon Jan 11 19:00:04 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13915:82bbb3bd0f0a gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.30-armv5: OK linux-2.6.31-armv5: OK linux-2.6.32-armv5: OK linux-2.6.33-rc2-armv5: OK linux-2.6.32-armv5-davinci: OK linux-2.6.33-rc2-armv5-davinci: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-armv5-ixp: OK linux-2.6.32-armv5-ixp: OK linux-2.6.33-rc2-armv5-ixp: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-armv5-omap2: OK linux-2.6.32-armv5-omap2: OK linux-2.6.33-rc2-armv5-omap2: OK linux-2.6.22.19-i686: OK 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.1-i686: WARNINGS linux-2.6.30-i686: OK linux-2.6.31-i686: WARNINGS linux-2.6.32-i686: WARNINGS linux-2.6.33-rc2-i686: ERRORS linux-2.6.30-m32r: OK linux-2.6.31-m32r: OK linux-2.6.32-m32r: OK linux-2.6.33-rc2-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: OK linux-2.6.32-mips: OK linux-2.6.33-rc2-mips: OK linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: OK linux-2.6.32-powerpc64: WARNINGS linux-2.6.33-rc2-powerpc64: ERRORS linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: OK linux-2.6.31-x86_64: WARNINGS linux-2.6.32-x86_64: WARNINGS linux-2.6.33-rc2-x86_64: ERRORS spec: OK sparse (linux-2.6.32): ERRORS sparse (linux-2.6.33-rc2): ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.kernellabs.com/hg/~dheitmueller/dib0700_ir
Hello Mauro, Please PULL from http://www.kernellabs.com/hg/~dheitmueller/dib0700_ir for the following: dib0700: rework IR logic for firmware 1.20 You had mentioned that you intended to do some porting of the dib0700 to use your new backend, so please do me a favor and merge this *before* you start your work. Thanks, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH - v4 1/4] V4L-vpfe_capture-remove-clock and platform code
Hi Mauro & Kevin,
I am re-sending these patches to do following:-
1) arch patches are re-created based on Linus tree
2) V4l patches are rebased to latest linux-next tree
These patches will override the pull request from Hans.
I am trying to setup mercurial to send the pull request, but
will take few more days to be fully functional. Meanwhile
please merge the attached patches.
The kernel upstream tree is at 2.6.33.rc3. We have a bunch of
patches planned for 2.6.34. So please start merging these patches
to the linux-next so that they can make to 2.6.34. You might
have seen a bunch of patches from Vaibhav as well that is being
reviewed on the list.
Regarding the merge of arch patches, I would let Kevin to
comment on how to handle the merge. I have re-created the arch
patches against the Linus tree as per Kevin's suggestion.
Thanks.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
>-Original Message-
>From: Karicheri, Muralidharan
>Sent: Monday, January 11, 2010 2:23 PM
>To: linux-media@vger.kernel.org; khil...@deeprootsystems.com;
>mche...@infradead.org
>Cc: hverk...@xs4all.nl; davinci-linux-open-sou...@linux.davincidsp.com;
>Karicheri, Muralidharan
>Subject: [PATCH - v4 1/4] V4L-vpfe_capture-remove-clock and platform code
>
>From: Muralidharan Karicheri
>
>Rebased to latest linux-next tree
>
>This combines the two patches sent earlier to change the clock
>configuration
>and converting ccdc drivers to platform drivers. This has updated comments
>against v1 of these patches.
>
>In this patch, the clock configuration is moved to ccdc driver since clocks
>are configured for ccdc. Also adding proper error codes for ccdc register
>function and removing the ccdc memory resource handling.
>
>Reviewed-by: Vaibhav Hiremath
>Reviewed-by: Kevin Hilman
>Reviewed-by: Hans Verkuil
>
>Signed-off-by: Hans Verkuil
>Signed-off-by: Muralidharan Karicheri
>---
>Applies to linux-next tree of v4l-dvb
> drivers/media/video/davinci/vpfe_capture.c | 131 +++-
>
> 1 files changed, 13 insertions(+), 118 deletions(-)
>
>diff --git a/drivers/media/video/davinci/vpfe_capture.c
>b/drivers/media/video/davinci/vpfe_capture.c
>index de22bc9..885cd54 100644
>--- a/drivers/media/video/davinci/vpfe_capture.c
>+++ b/drivers/media/video/davinci/vpfe_capture.c
>@@ -107,9 +107,6 @@ struct ccdc_config {
> int vpfe_probed;
> /* name of ccdc device */
> char name[32];
>- /* for storing mem maps for CCDC */
>- int ccdc_addr_size;
>- void *__iomem ccdc_addr;
> };
>
> /* data structures */
>@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
>*dev)
> BUG_ON(!dev->hw_ops.set_image_window);
> BUG_ON(!dev->hw_ops.get_image_window);
> BUG_ON(!dev->hw_ops.get_line_length);
>- BUG_ON(!dev->hw_ops.setfbaddr);
> BUG_ON(!dev->hw_ops.getfid);
>
> mutex_lock(&ccdc_lock);
>@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
>*dev)
>* walk through it during vpfe probe
>*/
> printk(KERN_ERR "vpfe capture not initialized\n");
>- ret = -1;
>+ ret = -EFAULT;
> goto unlock;
> }
>
> if (strcmp(dev->name, ccdc_cfg->name)) {
> /* ignore this ccdc */
>- ret = -1;
>+ ret = -EINVAL;
> goto unlock;
> }
>
> if (ccdc_dev) {
> printk(KERN_ERR "ccdc already registered\n");
>- ret = -1;
>+ ret = -EINVAL;
> goto unlock;
> }
>
> ccdc_dev = dev;
>- dev->hw_ops.set_ccdc_base(ccdc_cfg->ccdc_addr,
>-ccdc_cfg->ccdc_addr_size);
> unlock:
> mutex_unlock(&ccdc_lock);
> return ret;
>@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
> return vpfe_dev;
> }
>
>-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
>-{
>- struct vpfe_config *vpfe_cfg = vpfe_dev->cfg;
>-
>- clk_disable(vpfe_cfg->vpssclk);
>- clk_put(vpfe_cfg->vpssclk);
>- clk_disable(vpfe_cfg->slaveclk);
>- clk_put(vpfe_cfg->slaveclk);
>- v4l2_info(vpfe_dev->pdev->driver,
>- "vpfe vpss master & slave clocks disabled\n");
>-}
>-
>-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
>-{
>- struct vpfe_config *vpfe_cfg = vpfe_dev->cfg;
>- int ret = -ENOENT;
>-
>- vpfe_cfg->vpssclk = clk_get(vpfe_dev->pdev, "vpss_master");
>- if (NULL == vpfe_cfg->vpssclk) {
>- v4l2_err(vpfe_dev->pdev->driver, "No clock defined for"
>- "vpss_master\n");
>- return ret;
>- }
>-
>- if (clk_enable(vpfe_cfg->vpssclk)) {
>- v4l2_err(vpfe_dev->pdev->driver,
>- "vpfe vpss master clock not enabled\n");
>- goto out;
>- }
>- v4l2_info(vp
Re: WinTV Radio rev-c121 remote support
On Fri, 08 Jan 2010 13:59:14 +0100, Samuel Rakitnican wrote: On Tue, 05 Jan 2010 21:11:59 +0100, Samuel Rakitničan wrote: Hi, I have an old bt878 based analog card. It's 'Hauppauge WinTV Radio' model 44914, rev C121. I'm trying to workout support for this shipped remote control. I have [...] Card: http://linuxtv.org/wiki/index.php/File:Wintv-radio-C121.jpg Remote: http://linuxtv.org/wiki/index.php/File:Wintv-radio-remote.jpg Did some investigation, maybe this can help to clarify some things. Still didn't get any response in dmesg from remote. [...] i2c_scan: bttv0: i2c scan: found device @ 0x30 [IR (hauppauge)] bttv0: i2c scan: found device @ 0xa0 [eeprom] bttv0: i2c scan: found device @ 0xc2 [tuner (analog)] [...] modprobe ir-kbd-i2c debug=1 ir-kbd-i2c: probe 0x1a @ bt878 #0 [sw]: no ir-kbd-i2c: probe 0x18 @ bt878 #0 [sw]: yes [...] OK, patch http://patchwork.kernel.org/patch/70126/ did the trick for kernel oops and segfault. However there is still something wrong in the filtering code for hauppauge remotes that prevents my remote codes for passing through: drivers/media/video/ir-kbd-i2c.c 99 /* 100 * Hauppauge remotes (black/silver) always use 101 * specific device ids. If we do not filter the 102 * device ids then messages destined for devices 103 * such as TVs (id=0) will get through causing 104 * mis-fired events. 105 * 106 * We also filter out invalid key presses which 107 * produce annoying debug log entries. 108 */ 109 ircode= (start << 12) | (toggle << 11) | (dev << 6) | code; 110 if ((ircode & 0x1fff)==0x1fff) 111 /* invalid key press */ 112 return 0; 113 114 if (dev!=0x1e && dev!=0x1f) 115 /* not a hauppauge remote */ 116 return 0; 117 118 if (!range) 119 code += 64; When I comment in this part: if (dev!=0x1e && dev!=0x1f), my remote works with a hauppage=1 parameter, althought a few buttons are not mapped correctly. dmesg example with an empty table (buttons CH+ and CH-): : unknown key: key=0x20 down=1 : unknown key for scancode 0x0020 : unknown key: key=0x20 down=0 : unknown key for scancode 0x0021 : unknown key: key=0x21 down=1 : unknown key for scancode 0x0021 : unknown key: key=0x21 down=0 Can someone please take a look at this and perhaps fix the code. Thanks in advance. Regards, Samuel -- 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 - v4 2/4] V4L-vpfe-capture-converting dm355 ccdc driver to a platform driver
From: Muralidharan Karicheri
Rebased to latest linux-next tree
Updated based on Kevin's comments on clock configuration.
The ccdc now uses a generic name for clocks. "master" and "slave". On
individual platforms
these clocks will inherit from the platform specific clock. This will allow
re-use of
the driver for the same IP across different SoCs.
Following are the changes done:-
1) clocks are configured using generic clock names
2) converting the driver to a platform driver
3) cleanup - consolidate all static variables inside a structure,
ccdc_cfg
Reviewed-by: Kevin Hilman
Reviewed-by: Vaibhav Hiremath
Reviewed-by: Hans Verkuil
Signed-off-by: Hans Verkuil
Signed-off-by: Muralidharan Karicheri
---
Applies to linux-next branch of v4l-dvb
drivers/media/video/davinci/dm355_ccdc.c | 409 +++---
1 files changed, 256 insertions(+), 153 deletions(-)
diff --git a/drivers/media/video/davinci/dm355_ccdc.c
b/drivers/media/video/davinci/dm355_ccdc.c
index 3143900..fc716ed 100644
--- a/drivers/media/video/davinci/dm355_ccdc.c
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -37,8 +37,11 @@
#include
#include
#include
+#include
+
#include
#include
+
#include "dm355_ccdc_regs.h"
#include "ccdc_hw_device.h"
@@ -46,67 +49,75 @@ MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("CCDC Driver for DM355");
MODULE_AUTHOR("Texas Instruments");
-static struct device *dev;
-
-/* Object for CCDC raw mode */
-static struct ccdc_params_raw ccdc_hw_params_raw = {
- .pix_fmt = CCDC_PIXFMT_RAW,
- .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
- .win = CCDC_WIN_VGA,
- .fid_pol = VPFE_PINPOL_POSITIVE,
- .vd_pol = VPFE_PINPOL_POSITIVE,
- .hd_pol = VPFE_PINPOL_POSITIVE,
- .gain = {
- .r_ye = 256,
- .gb_g = 256,
- .gr_cy = 256,
- .b_mg = 256
- },
- .config_params = {
- .datasft = 2,
- .data_sz = CCDC_DATA_10BITS,
- .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
- .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
- .alaw = {
- .gama_wd = 2,
+static struct ccdc_oper_config {
+ struct device *dev;
+ /* CCDC interface type */
+ enum vpfe_hw_if_type if_type;
+ /* Raw Bayer configuration */
+ struct ccdc_params_raw bayer;
+ /* YCbCr configuration */
+ struct ccdc_params_ycbcr ycbcr;
+ /* Master clock */
+ struct clk *mclk;
+ /* slave clock */
+ struct clk *sclk;
+ /* ccdc base address */
+ void __iomem *base_addr;
+} ccdc_cfg = {
+ /* Raw configurations */
+ .bayer = {
+ .pix_fmt = CCDC_PIXFMT_RAW,
+ .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+ .win = CCDC_WIN_VGA,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .gain = {
+ .r_ye = 256,
+ .gb_g = 256,
+ .gr_cy = 256,
+ .b_mg = 256
},
- .blk_clamp = {
- .sample_pixel = 1,
- .dc_sub = 25
- },
- .col_pat_field0 = {
- .olop = CCDC_GREEN_BLUE,
- .olep = CCDC_BLUE,
- .elop = CCDC_RED,
- .elep = CCDC_GREEN_RED
- },
- .col_pat_field1 = {
- .olop = CCDC_GREEN_BLUE,
- .olep = CCDC_BLUE,
- .elop = CCDC_RED,
- .elep = CCDC_GREEN_RED
+ .config_params = {
+ .datasft = 2,
+ .mfilt1 = CCDC_NO_MEDIAN_FILTER1,
+ .mfilt2 = CCDC_NO_MEDIAN_FILTER2,
+ .alaw = {
+ .gama_wd = 2,
+ },
+ .blk_clamp = {
+ .sample_pixel = 1,
+ .dc_sub = 25
+ },
+ .col_pat_field0 = {
+ .olop = CCDC_GREEN_BLUE,
+ .olep = CCDC_BLUE,
+ .elop = CCDC_RED,
+ .elep = CCDC_GREEN_RED
+ },
+ .col_pat_field1 = {
+ .olop = CCDC_GREEN_BLUE,
+ .olep = CCDC_BLUE,
+ .elop = CCDC_RED,
+ .elep = CCDC_GREEN_RED
+ },
},
},
+ /* YCbCr configuration */
+ .ycbcr = {
+ .win = CCDC_WIN_PAL,
+ .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+ .frm_fmt = CCDC_FRMFMT_INTERLACED,
[PATCH - v4 1/4] V4L-vpfe_capture-remove-clock and platform code
From: Muralidharan Karicheri
Rebased to latest linux-next tree
This combines the two patches sent earlier to change the clock configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v1 of these patches.
In this patch, the clock configuration is moved to ccdc driver since clocks
are configured for ccdc. Also adding proper error codes for ccdc register
function and removing the ccdc memory resource handling.
Reviewed-by: Vaibhav Hiremath
Reviewed-by: Kevin Hilman
Reviewed-by: Hans Verkuil
Signed-off-by: Hans Verkuil
Signed-off-by: Muralidharan Karicheri
---
Applies to linux-next tree of v4l-dvb
drivers/media/video/davinci/vpfe_capture.c | 131 +++-
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
- /* for storing mem maps for CCDC */
- int ccdc_addr_size;
- void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
BUG_ON(!dev->hw_ops.set_image_window);
BUG_ON(!dev->hw_ops.get_image_window);
BUG_ON(!dev->hw_ops.get_line_length);
- BUG_ON(!dev->hw_ops.setfbaddr);
BUG_ON(!dev->hw_ops.getfid);
mutex_lock(&ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR "vpfe capture not initialized\n");
- ret = -1;
+ ret = -EFAULT;
goto unlock;
}
if (strcmp(dev->name, ccdc_cfg->name)) {
/* ignore this ccdc */
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR "ccdc already registered\n");
- ret = -1;
+ ret = -EINVAL;
goto unlock;
}
ccdc_dev = dev;
- dev->hw_ops.set_ccdc_base(ccdc_cfg->ccdc_addr,
- ccdc_cfg->ccdc_addr_size);
unlock:
mutex_unlock(&ccdc_lock);
return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
- struct vpfe_config *vpfe_cfg = vpfe_dev->cfg;
-
- clk_disable(vpfe_cfg->vpssclk);
- clk_put(vpfe_cfg->vpssclk);
- clk_disable(vpfe_cfg->slaveclk);
- clk_put(vpfe_cfg->slaveclk);
- v4l2_info(vpfe_dev->pdev->driver,
-"vpfe vpss master & slave clocks disabled\n");
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
- struct vpfe_config *vpfe_cfg = vpfe_dev->cfg;
- int ret = -ENOENT;
-
- vpfe_cfg->vpssclk = clk_get(vpfe_dev->pdev, "vpss_master");
- if (NULL == vpfe_cfg->vpssclk) {
- v4l2_err(vpfe_dev->pdev->driver, "No clock defined for"
-"vpss_master\n");
- return ret;
- }
-
- if (clk_enable(vpfe_cfg->vpssclk)) {
- v4l2_err(vpfe_dev->pdev->driver,
- "vpfe vpss master clock not enabled\n");
- goto out;
- }
- v4l2_info(vpfe_dev->pdev->driver,
-"vpfe vpss master clock enabled\n");
-
- vpfe_cfg->slaveclk = clk_get(vpfe_dev->pdev, "vpss_slave");
- if (NULL == vpfe_cfg->slaveclk) {
- v4l2_err(vpfe_dev->pdev->driver,
- "No clock defined for vpss slave\n");
- goto out;
- }
-
- if (clk_enable(vpfe_cfg->slaveclk)) {
- v4l2_err(vpfe_dev->pdev->driver,
-"vpfe vpss slave clock not enabled\n");
- goto out;
- }
- v4l2_info(vpfe_dev->pdev->driver, "vpfe vpss slave clock enabled\n");
- return 0;
-out:
- if (vpfe_cfg->vpssclk)
- clk_put(vpfe_cfg->vpssclk);
- if (vpfe_cfg->slaveclk)
- clk_put(vpfe_cfg->slaveclk);
-
- return -1;
-}
-
/*
* vpfe_probe : This function creates device entries by register
* itself to the V4L2 driver and initializes fields of each
@@ -1870,7 +1809,7 @@ static __init int vpfe_probe(struct platform_device *pdev)
if (NULL == pdev->dev.platform_data) {
v4l2_err(pdev->dev.driver, "Unable to get vpfe config\n");
- ret = -ENOENT;
+ ret = -ENODEV;
goto probe_free_dev_mem;
}
@@ -1884,18 +1823,13 @@ static __init int vpfe_probe(struct platform_device
*pdev)
goto probe_free_dev_mem;
[PATCH - v4 3/4] V4L-vpfe-capture-converting-dm644x-driver to a platform driver
From: Muralidharan Karicheri
Rebased to latest linux-next tree
Updated based on Kevin's comments on clock configuration.
The ccdc now uses a generic name for clocks. master and slave. On individual
platforms
these clocks will inherit from the platform specific clock. This will allow
re-use of
the driver for the same IP across different SoCs.
Following are the changes done:-
1) clocks are configured using generic clock names
2) converting the driver to a platform driver
3) cleanup - consolidate all static variables inside a structure,
ccdc_cfg
Reviewed-by: Kevin Hilman
Reviewed-by: Vaibhav Hiremath
Reviewed-by: Hans Verkuil
Signed-off-by: Hans Verkuil
Signed-off-by: Muralidharan Karicheri
---
Applies to linux-next tree of v4l-dvb
drivers/media/video/davinci/dm644x_ccdc.c | 360 ++---
1 files changed, 224 insertions(+), 136 deletions(-)
diff --git a/drivers/media/video/davinci/dm644x_ccdc.c
b/drivers/media/video/davinci/dm644x_ccdc.c
index d5fa193..7e35269 100644
--- a/drivers/media/video/davinci/dm644x_ccdc.c
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -37,8 +37,11 @@
#include
#include
#include
+#include
+
#include
#include
+
#include "dm644x_ccdc_regs.h"
#include "ccdc_hw_device.h"
@@ -46,32 +49,44 @@ MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("CCDC Driver for DM6446");
MODULE_AUTHOR("Texas Instruments");
-static struct device *dev;
-
-/* Object for CCDC raw mode */
-static struct ccdc_params_raw ccdc_hw_params_raw = {
- .pix_fmt = CCDC_PIXFMT_RAW,
- .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
- .win = CCDC_WIN_VGA,
- .fid_pol = VPFE_PINPOL_POSITIVE,
- .vd_pol = VPFE_PINPOL_POSITIVE,
- .hd_pol = VPFE_PINPOL_POSITIVE,
- .config_params = {
- .data_sz = CCDC_DATA_10BITS,
+static struct ccdc_oper_config {
+ struct device *dev;
+ /* CCDC interface type */
+ enum vpfe_hw_if_type if_type;
+ /* Raw Bayer configuration */
+ struct ccdc_params_raw bayer;
+ /* YCbCr configuration */
+ struct ccdc_params_ycbcr ycbcr;
+ /* Master clock */
+ struct clk *mclk;
+ /* slave clock */
+ struct clk *sclk;
+ /* ccdc base address */
+ void __iomem *base_addr;
+} ccdc_cfg = {
+ /* Raw configurations */
+ .bayer = {
+ .pix_fmt = CCDC_PIXFMT_RAW,
+ .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
+ .win = CCDC_WIN_VGA,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .config_params = {
+ .data_sz = CCDC_DATA_10BITS,
+ },
+ },
+ .ycbcr = {
+ .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
+ .frm_fmt = CCDC_FRMFMT_INTERLACED,
+ .win = CCDC_WIN_PAL,
+ .fid_pol = VPFE_PINPOL_POSITIVE,
+ .vd_pol = VPFE_PINPOL_POSITIVE,
+ .hd_pol = VPFE_PINPOL_POSITIVE,
+ .bt656_enable = 1,
+ .pix_order = CCDC_PIXORDER_CBYCRY,
+ .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
},
-};
-
-/* Object for CCDC ycbcr mode */
-static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
- .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
- .frm_fmt = CCDC_FRMFMT_INTERLACED,
- .win = CCDC_WIN_PAL,
- .fid_pol = VPFE_PINPOL_POSITIVE,
- .vd_pol = VPFE_PINPOL_POSITIVE,
- .hd_pol = VPFE_PINPOL_POSITIVE,
- .bt656_enable = 1,
- .pix_order = CCDC_PIXORDER_CBYCRY,
- .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED
};
#define CCDC_MAX_RAW_YUV_FORMATS 2
@@ -84,25 +99,15 @@ static u32 ccdc_raw_bayer_pix_formats[] =
static u32 ccdc_raw_yuv_pix_formats[] =
{V4L2_PIX_FMT_UYVY, V4L2_PIX_FMT_YUYV};
-static void *__iomem ccdc_base_addr;
-static int ccdc_addr_size;
-static enum vpfe_hw_if_type ccdc_if_type;
-
/* register access routines */
static inline u32 regr(u32 offset)
{
- return __raw_readl(ccdc_base_addr + offset);
+ return __raw_readl(ccdc_cfg.base_addr + offset);
}
static inline void regw(u32 val, u32 offset)
{
- __raw_writel(val, ccdc_base_addr + offset);
-}
-
-static void ccdc_set_ccdc_base(void *addr, int size)
-{
- ccdc_base_addr = addr;
- ccdc_addr_size = size;
+ __raw_writel(val, ccdc_cfg.base_addr + offset);
}
static void ccdc_enable(int flag)
@@ -132,7 +137,7 @@ void ccdc_setwin(struct v4l2_rect *image_win,
int vert_start, vert_nr_lines;
int val = 0, mid_img = 0;
- dev_dbg(dev, "\nStarting ccdc_setwin...");
+ dev_dbg(ccdc_cfg.dev, "\nStarting ccdc_setwin...");
/*
* ppc - per pixel count. indicates how many pixels per cell
* output to SDRAM. example, for ycbcr, it is one y and one c, so 2.
@@ -171,7 +176,7 @@ void ccdc_setwin(struct v4l2_rect *image_win,
regw((vert_start << CCDC_VERT_STA
[PATCH - v4 4/4] DaVinci-vpfe-capture-converting-ccdc-drivers-to-platform-drivers
From: Muralidharan Karicheri
Re-sending the patches based on Kevin's comments.
Following are the changes from v3 :-
- replaced CLK entries with clk_add_alias() calls
- removed unused vpss_master and vpss_slave entries
This combines the two patches sent earlier to change the clock configuration
and converting ccdc drivers to platform drivers. This has updated comments
against v2 of these patches. Two new clocks "master" and "slave" are defined
for ccdc driver
as per comments from Kevin Hilman.
This adds platform code for ccdc driver on DM355 and DM6446.
Reviewed-by: Vaibhav Hiremath
Reviewed-by: Kevin Hilman
Reviewed-by: Hans Verkuil
Signed-off-by: Muralidharan Karicheri
---
Applies to Linus tree
arch/arm/mach-davinci/dm355.c | 58 ---
arch/arm/mach-davinci/dm644x.c | 36 ++---
2 files changed, 50 insertions(+), 44 deletions(-)
diff --git a/arch/arm/mach-davinci/dm355.c b/arch/arm/mach-davinci/dm355.c
index dedf4d4..b4d0396 100644
--- a/arch/arm/mach-davinci/dm355.c
+++ b/arch/arm/mach-davinci/dm355.c
@@ -112,20 +112,6 @@ static struct clk vpss_dac_clk = {
.lpsc = DM355_LPSC_VPSS_DAC,
};
-static struct clk vpss_master_clk = {
- .name = "vpss_master",
- .parent = &pll1_sysclk4,
- .lpsc = DAVINCI_LPSC_VPSSMSTR,
- .flags = CLK_PSC,
-};
-
-static struct clk vpss_slave_clk = {
- .name = "vpss_slave",
- .parent = &pll1_sysclk4,
- .lpsc = DAVINCI_LPSC_VPSSSLV,
-};
-
-
static struct clk clkout1_clk = {
.name = "clkout1",
.parent = &pll1_aux_clk,
@@ -345,8 +331,6 @@ static struct davinci_clk dm355_clks[] = {
CLK(NULL, "pll1_aux", &pll1_aux_clk),
CLK(NULL, "pll1_sysclkbp", &pll1_sysclkbp),
CLK(NULL, "vpss_dac", &vpss_dac_clk),
- CLK(NULL, "vpss_master", &vpss_master_clk),
- CLK(NULL, "vpss_slave", &vpss_slave_clk),
CLK(NULL, "clkout1", &clkout1_clk),
CLK(NULL, "clkout2", &clkout2_clk),
CLK(NULL, "pll2", &pll2_clk),
@@ -665,6 +649,17 @@ static struct platform_device dm355_asp1_device = {
.resource = dm355_asp1_resources,
};
+static void dm355_ccdc_setup_pinmux(void)
+{
+ davinci_cfg_reg(DM355_VIN_PCLK);
+ davinci_cfg_reg(DM355_VIN_CAM_WEN);
+ davinci_cfg_reg(DM355_VIN_CAM_VD);
+ davinci_cfg_reg(DM355_VIN_CAM_HD);
+ davinci_cfg_reg(DM355_VIN_YIN_EN);
+ davinci_cfg_reg(DM355_VIN_CINL_EN);
+ davinci_cfg_reg(DM355_VIN_CINH_EN);
+}
+
static struct resource dm355_vpss_resources[] = {
{
/* VPSS BL Base address */
@@ -701,6 +696,10 @@ static struct resource vpfe_resources[] = {
.end= IRQ_VDINT1,
.flags = IORESOURCE_IRQ,
},
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct resource dm355_ccdc_resource[] = {
/* CCDC Base address */
{
.flags = IORESOURCE_MEM,
@@ -708,8 +707,18 @@ static struct resource vpfe_resources[] = {
.end= 0x01c70600 + 0x1ff,
},
};
+static struct platform_device dm355_ccdc_dev = {
+ .name = "dm355_ccdc",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm355_ccdc_resource),
+ .resource = dm355_ccdc_resource,
+ .dev = {
+ .dma_mask = &vpfe_capture_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = dm355_ccdc_setup_pinmux,
+ },
+};
-static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
static struct platform_device vpfe_capture_dev = {
.name = CAPTURE_DRV_NAME,
.id = -1,
@@ -857,20 +866,13 @@ static int __init dm355_init_devices(void)
if (!cpu_is_davinci_dm355())
return 0;
+ /* Add ccdc clock aliases */
+ clk_add_alias("master", dm355_ccdc_dev.name, "pll1_sysclk4", NULL);
+ clk_add_alias("slave", dm355_ccdc_dev.name, "pll1_sysclk4", NULL);
davinci_cfg_reg(DM355_INT_EDMA_CC);
platform_device_register(&dm355_edma_device);
platform_device_register(&dm355_vpss_device);
- /*
-* setup Mux configuration for vpfe input and register
-* vpfe capture platform device
-*/
- davinci_cfg_reg(DM355_VIN_PCLK);
- davinci_cfg_reg(DM355_VIN_CAM_WEN);
- davinci_cfg_reg(DM355_VIN_CAM_VD);
- davinci_cfg_reg(DM355_VIN_CAM_HD);
- davinci_cfg_reg(DM355_VIN_YIN_EN);
- davinci_cfg_reg(DM355_VIN_CINL_EN);
- davinci_cfg_reg(DM355_VIN_CINH_EN);
+ platform_device_register(&dm355_ccdc_dev);
platform_device_register(&vpfe_capture_dev);
return 0;
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 2cd0081..569c541 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -149,19 +149,6 @@ static
Re: Fwd: Compro S300 - ZL10313
On Samstag, 9. Januar 2010, JD Louw wrote: > On Wed, 2010-01-06 at 22:17 +0200, Theunis Potgieter wrote: > > 2010/1/2 JD Louw : > > > On Sat, 2010-01-02 at 09:39 +0200, Theunis Potgieter wrote: > > >> 2010/1/1 JD Louw : > > >> > On Tue, 2009-12-29 at 23:23 +0200, Theunis Potgieter wrote: > > >> >> Hi mailing list, > > >> >> > > >> >> I have a problem with my Compro S300 pci card under Linux 2.6.32. > > >> >> > > >> >> I cannot tune with this card and STR/SNRA is very bad compared to > > >> >> my Technisat SkyStar 2 pci card, connected to the same dish. > > >> >> > > >> >> I have this card and are willing to run tests, tested drivers etc > > >> >> to make this work. > > >> >> > > >> >> I currently load the module saa7134 with options: card=169 > > >> >> > > >> >> I enabled some debug parameters on the saa7134, not sure what else > > >> >> I should enable. Please find my dmesg log attached. > > >> >> > > >> >> lsmod shows : > > >> >> > > >> >> # lsmod > > >> >> Module Size Used by > > >> >> zl10039 6268 2 > > >> >> mt312 12048 2 > > >> >> saa7134_dvb41549 11 > > >> >> saa7134 195664 1 saa7134_dvb > > >> >> nfsd 416819 11 > > >> >> videobuf_dvb8187 1 saa7134_dvb > > >> >> dvb_core 148140 1 videobuf_dvb > > >> >> ir_common 40625 1 saa7134 > > >> >> v4l2_common21544 1 saa7134 > > >> >> videodev 58341 2 saa7134,v4l2_common > > >> >> v4l1_compat24473 1 videodev > > >> >> videobuf_dma_sg17830 2 saa7134_dvb,saa7134 > > >> >> videobuf_core 26534 3 > > >> >> saa7134,videobuf_dvb,videobuf_dma_sg tveeprom 12550 > > >> >> 1 saa7134 > > >> >> thermal20547 0 > > >> >> processor 54638 1 > > >> >> > > >> >> # uname -a > > >> >> Linux vbox 2.6.32-gentoo #4 Sat Dec 19 00:54:19 SAST 2009 i686 > > >> >> Pentium III (Coppermine) GenuineIntel GNU/Linux > > >> >> > > >> >> Thanks, > > >> >> Theunis > > >> > > > >> > Hi, > > >> > > > >> > It's probably the GPIO settings that are wrong for your SAA7133 > > >> > based card revision. See > > >> > http://osdir.com/ml/linux-media/2009-06/msg01256.html for an > > >> > explanation. For quick confirmation check if you have 12V - 20V DC > > >> > going to your LNB. The relevant lines of code is in > > >> > ~/v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c: > > >> > > > >> > case SAA7134_BOARD_VIDEOMATE_S350: > > >> > dev->has_remote = SAA7134_REMOTE_GPIO; > > >> > saa_andorl(SAA7134_GPIO_GPMODE0 >> 2, 0x8000, 0x8000); > > >> > saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0x8000, 0x8000); > > >> > break; > > >> > > >> Hi thanks for the hint. I changed it to the following: > > >> > > >> case SAA7134_BOARD_VIDEOMATE_S350: > > >> dev->has_remote = SAA7134_REMOTE_GPIO; > > >> saa_andorl(SAA7134_GPIO_GPMODE0 >> 2, 0xc000, 0xc000); > > >> saa_andorl(SAA7134_GPIO_GPSTATUS0 >> 2, 0xc000, 0xc000); > > >> break; > > >> > > >> I now get the same SNR as on my skystar2 card, signal is still > > >> indicating 17% where as the skystar2 would show 68%. At least I'm > > >> getting a LOCK on channels :) > > >> > > >> Thanks! > > >> > > >> > Looking at your log, at least the demodulator and tuner is > > >> > responding correctly. You can see this by looking at the i2c traffic > > >> > addressed to 0x1c (demodulator) and 0xc0 (tuner). Attached is a > > >> > dmesg trace from my working SAA7130 based card. > > >> > > > >> > Regards > > >> > JD > > > > > > Hi, > > > > > > Just to clarify, can you now watch channels? > > > > > > At the moment the signal strength measurement is a bit whacked, so > > > don't worry too much about it. I also get the 75%/17% figures you > > > mentioned when tuning to strong signals. The figure is simply reported > > > wrongly: even weaker signals should tune fine. If you want you can have > > > a look in ~/v4l-dvb/linux/drivers/media/dvb/frontends/mt312.c at > > > mt312_read_signal_strength(). > > > > > > Also, if you have a multimeter handy, can you confirm that the > > > 0xc000 GPIO fix enables LNB voltage? I'd like to issue a patch for > > > this. I've already tested this on my older card with no ill effect. > > > > This is what happened when I started vdr. > > > > Vertical gave a Volt reading between 13.9 and 14.1, Horizontal Gave > > 19.4 ~ 19.5. When I stopped vdr, the Voltage went back to 14V. I > > thought that it would read 0V. What is suppose to happen? > > > > Theunis > > > > > Regards > > > JD > > Hi, > > The newer revision cards should be able to shut down LNB power when the > card is closed. This is what the Windows driver does; not yet > implemented in Linux. Do you know how this is done hardware-wise? Is this a gpio connected circuit? If yes, I think it can be enabled in software by saving original pointer to set_voltage and overwriting it by some routine switching gpio and ca
How to use saa7134 gpio via gpio-sysfs?
I need to bit twiddle saa7134 gpio pins from userspace.
To use gpio-sysfs, I need a "GPIO number" to export each pin, but I
do not know how to find such a number.
Card is RTD Embedded Technologies VFG7350 [card=72,autodetected].
GPIO uses pcf8574 chip.
Kernel is 2.6.30.
gpio-sysfs creates
/sys/class/gpio/export
/sys/class/gpio/import
but no gpio entries so far.
>From dmesg ("gpiotracking=1")
saa7133[0]: board init: gpio is 1
saa7133[0]: gpio: mode=0x000 in=0x4011000 out=0x000 [pre-init]
saa7133[1]: board init: gpio is 1
saa7133[1]: gpio: mode=0x000 in=0x4010f00 out=0x000 [pre-init]
How may I find each "GPIO number" for this board?
Thanks in advance for any help.
--
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
Writing udev reuls for dual tuner devices
Hello,
I use a Media-Pointer MP-S2 Dual DVB-S2 PCIe card with the latest drivers from
the git-Repository
http://projects.vdr-developer.org/repositories/show/mediapointer-dvb-s2 .
I tried to write udev rules to define the adapter names of the tuner to avoid
that the device names could change at boot. It seems not to be possible to
write a udev rule for this dual DVB-S2 device, because there are no attributes
to differentiate between tuner 0 and tuner 1. Attached is the output of
udevinfo.
The following udev rule allows only to define the adapter name of a single
tuner:
SUBSYSTEM=="dvb", ATTRS{vendor}=="0x18c3", ATTRS{device}=="0x0720",
KERNELS==":02:00.0",
PROGRAM="/bin/sh -c 'K=%k; K=$${K#dvb}; printf dvb/adapter0/%%s $${K#*.}'",
SYMLINK+="%c"
How can this issue be solved in general? I think the driver should provide an
attribute for each tuner, so that it is possible to write udev rules. How this
has been solved for other Dual Tuner devices like Pinnacle PCTV Dual DVB-T
Diversity, DViCO FusionHDTV DVB-T Dual Express?
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device
'/devices/pci:00/:00:01.0/:01:00.0/dvb/dvb0.frontend0':
KERNEL=="dvb0.frontend0"
SUBSYSTEM=="dvb"
DRIVER==""
ATTR{dev}=="212:2"
looking at parent device '/devices/pci:00/:00:01.0/:01:00.0/dvb':
KERNELS=="dvb"
SUBSYSTEMS==""
DRIVERS==""
looking at parent device '/devices/pci:00/:00:01.0/:01:00.0':
KERNELS==":01:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="ngene"
ATTRS{vendor}=="0x18c3"
ATTRS{device}=="0x0720"
ATTRS{subsystem_vendor}=="0x18c3"
ATTRS{subsystem_device}=="0xabc4"
ATTRS{class}=="0x04"
ATTRS{irq}=="16"
ATTRS{local_cpus}==",,,"
ATTRS{modalias}=="pci:v18C3d0720sv18C3sdABC4bc04sc00i00"
ATTRS{enable}=="1"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""
looking at parent device '/devices/pci:00/:00:01.0':
KERNELS==":00:01.0"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport-driver"
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x2771"
ATTRS{subsystem_vendor}=="0x"
ATTRS{subsystem_device}=="0x"
ATTRS{class}=="0x060400"
ATTRS{irq}=="223"
ATTRS{local_cpus}==",,,"
ATTRS{modalias}=="pci:v8086d2771svsdbc06sc04i00"
ATTRS{enable}=="2"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}=="1"
looking at parent device '/devices/pci:00':
KERNELS=="pci:00"
SUBSYSTEMS==""
DRIVERS==""
Udevinfo starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device
'/devices/pci:00/:00:01.0/:01:00.0/dvb/dvb1.frontend0':
KERNEL=="dvb1.frontend0"
SUBSYSTEM=="dvb"
DRIVER==""
ATTR{dev}=="212:5"
looking at parent device '/devices/pci:00/:00:01.0/:01:00.0/dvb':
KERNELS=="dvb"
SUBSYSTEMS==""
DRIVERS==""
looking at parent device '/devices/pci:00/:00:01.0/:01:00.0':
KERNELS==":01:00.0"
SUBSYSTEMS=="pci"
DRIVERS=="ngene"
ATTRS{vendor}=="0x18c3"
ATTRS{device}=="0x0720"
ATTRS{subsystem_vendor}=="0x18c3"
ATTRS{subsystem_device}=="0xabc4"
ATTRS{class}=="0x04"
ATTRS{irq}=="16"
ATTRS{local_cpus}==",,,"
ATTRS{modalias}=="pci:v18C3d0720sv18C3sdABC4bc04sc00i00"
ATTRS{enable}=="1"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}==""
looking at parent device '/devices/pci:00/:00:01.0':
KERNELS==":00:01.0"
SUBSYSTEMS=="pci"
DRIVERS=="pcieport-driver"
ATTRS{vendor}=="0x8086"
ATTRS{device}=="0x2771"
ATTRS{subsystem_vendor}=="0x"
ATTRS{subsystem_device}=="0x"
ATTRS{class}=="0x060400"
ATTRS{irq}=="223"
ATTRS{local_cpus}==",,,"
ATTRS{modalias}=="pci:v8086d2771svsdbc06sc04i00"
ATTRS{enable}=="2"
ATTRS{broken_parity_status}=="0"
ATTRS{msi_bus}=="1"
looking at parent device '/devices/pci:00':
KERNELS=="pci:00"
SUBSYSTEMS==""
DRIVERS==""
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb for the following 11 changesets: 01/11: gspca - ov534/ov534_9: Split the ov534 subdriver. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=b3b5fdea85f9 02/11: gspca - zc3xx: Cleanup code. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=88b763c4059e 03/11: gspca - zc3xx: Rename the USB sequences. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=2f95fe18d345 04/11: gspca - zc3xx: Fix hdcs2020 probe. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=5fa0a60e8b87 05/11: gspca - zc3xx: Let default sharpness for sensor pas202b. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=7135f9402c0d 06/11: gspca - zc3xx: Remove unuseful register write. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=6d982f8d5472 07/11: gspca - zc3xx: Switch off the LED on resume. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=be00fd76345f 08/11: gspca - zc3xx: Simplify code. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=e57ed5ad2d90 09/11: gspca - sunplus: Optimize and remove unused sequences. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=40901861f5d0 10/11: gspca - main: Change the check of the USB video interface. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=09a30227151c 11/11: gspca - pac7302: Fix a random USB error. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=ea88b3abee04 b/linux/drivers/media/video/gspca/ov534_9.c | 1477 linux/Documentation/video4linux/gspca.txt |3 linux/drivers/media/video/gspca/Kconfig | 16 linux/drivers/media/video/gspca/Makefile|2 linux/drivers/media/video/gspca/gspca.c |9 linux/drivers/media/video/gspca/ov534.c | 1242 +-- linux/drivers/media/video/gspca/pac7302.c |2 linux/drivers/media/video/gspca/sunplus.c | 63 - linux/drivers/media/video/gspca/zc3xx.c | 352 +++--- 9 files changed, 1787 insertions(+), 1379 deletions(-) Thanks. -- 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: gspca_sunplus problem: more than one device is created
On Mon, 11 Jan 2010 01:22:50 +0100 Hans de Goede wrote: > You did not mark this as high priority, still it should go into > 2.6.33. can you please send a mail to Mauro asking for this ? The previous change (test of the interface class) had not a high priority, so, it will not go into 2.6.33. Then, both changes will go into 2.6.34. I hope you did not mark a high priority to the cpia1 port to gspca... Regards. -- 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: gspca_pac7302: sporatdic problem when plugging the device
Jean-Francois Moine írta: > Sorry, I forgot to attach the patch. > >> In some usbsnoop files I have, the index 0x48 is not loaded. May you >> try the attached patch (skip the index 0x48 and remove the delay). 100 plug-ins out of 100 OK, no errors: I say go for this patch. I applied the patch on top of rev 14000:bc5737e0e757 from http://linuxtv.org/hg/~jfrancois/gspca/ . I tested the driver on top of 2.6.32 with Labtec Webcam 2200 (0x093a:0x2626). Tested-by: Márton Németh Thanks for the fix. Regards, Márton Németh -- 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/9] Feature enhancement of VPFE/CCDC Capture driver
Vaibhav, Hans already merged my dm365 patches. So you have rebase this to that before merging. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 email: m-kariche...@ti.com >-Original Message- >From: Hiremath, Vaibhav >Sent: Monday, January 11, 2010 1:29 AM >To: Hiremath, Vaibhav; linux-media@vger.kernel.org >Cc: linux-o...@vger.kernel.org; hverk...@xs4all.nl; davinci-linux-open- >sou...@linux.davincidsp.com; Karicheri, Muralidharan >Subject: RE: [PATCH 0/9] Feature enhancement of VPFE/CCDC Capture driver > > >> -Original Message- >> From: Hiremath, Vaibhav >> Sent: Monday, January 04, 2010 7:33 PM >> To: linux-media@vger.kernel.org >> Cc: linux-o...@vger.kernel.org; hverk...@xs4all.nl; davinci-linux- >> open-sou...@linux.davincidsp.com; Karicheri, Muralidharan; Hiremath, >> Vaibhav >> Subject: [PATCH 0/9] Feature enhancement of VPFE/CCDC Capture driver >> >> From: Vaibhav Hiremath >> >> While adding support for AM3517/05 devices I have implemented/came- >> across >> these features/enhancement/bug-fixes for VPFE-Capture driver. >> >> Also the important change added is, to introduced "ti-media" >> directory for all TI devices. >> >> Vaibhav Hiremath (9): >> Makfile:Removed duplicate entry of davinci >> TVP514x:Switch to automode for querystd >> tvp514x: add YUYV format support >> Introducing ti-media directory >> DMx:Update board files for ti-media directory change >> Davinci VPFE Capture:Return 0 from suspend/resume >> DM644x CCDC : Add Suspend/Resume Support >> VPFE Capture: Add call back function for interrupt clear to >> vpfe_cfg >> DM644x CCDC: Add 10bit BT support >> >> arch/arm/mach-davinci/include/mach/dm355.h |2 +- >> arch/arm/mach-davinci/include/mach/dm644x.h |2 +- >> drivers/media/video/Kconfig | 84 +- >> drivers/media/video/Makefile|4 +- >> drivers/media/video/davinci/Makefile| 17 - >> drivers/media/video/davinci/ccdc_hw_device.h| 110 -- >> drivers/media/video/davinci/dm355_ccdc.c| 1081 --- >> drivers/media/video/davinci/dm355_ccdc_regs.h | 310 >> drivers/media/video/davinci/dm644x_ccdc.c | 966 -- >> drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 -- >> drivers/media/video/davinci/vpfe_capture.c | 2055 >> - >> drivers/media/video/davinci/vpif.c | 296 --- >> drivers/media/video/davinci/vpif.h | 642 --- >> drivers/media/video/davinci/vpif_capture.c | 2168 >> --- >> drivers/media/video/davinci/vpif_capture.h | 165 -- >> drivers/media/video/davinci/vpif_display.c | 1654 >> - >> drivers/media/video/davinci/vpif_display.h | 175 -- >> drivers/media/video/davinci/vpss.c | 301 >> drivers/media/video/ti-media/Kconfig| 88 + >> drivers/media/video/ti-media/Makefile | 17 + >> drivers/media/video/ti-media/ccdc_hw_device.h | 110 ++ >> drivers/media/video/ti-media/dm355_ccdc.c | 1081 +++ >> drivers/media/video/ti-media/dm355_ccdc_regs.h | 310 >> drivers/media/video/ti-media/dm644x_ccdc.c | 1090 >> drivers/media/video/ti-media/dm644x_ccdc_regs.h | 153 ++ >> drivers/media/video/ti-media/vpfe_capture.c | 2067 >> + >> drivers/media/video/ti-media/vpif.c | 296 +++ >> drivers/media/video/ti-media/vpif.h | 642 +++ >> drivers/media/video/ti-media/vpif_capture.c | 2168 >> +++ >> drivers/media/video/ti-media/vpif_capture.h | 165 ++ >> drivers/media/video/ti-media/vpif_display.c | 1654 >> + >> drivers/media/video/ti-media/vpif_display.h | 175 ++ >> drivers/media/video/ti-media/vpss.c | 301 >> drivers/media/video/tvp514x.c | 15 + >> include/media/davinci/ccdc_types.h | 43 - >> include/media/davinci/dm355_ccdc.h | 321 >> include/media/davinci/dm644x_ccdc.h | 184 -- >> include/media/davinci/vpfe_capture.h| 200 --- >> include/media/davinci/vpfe_types.h | 51 - >> include/media/davinci/vpss.h| 69 - >> include/media/ti-media/ccdc_types.h | 43 + >> include/media/ti-media/dm355_ccdc.h | 321 >> include/media/ti-media/dm644x_ccdc.h| 184 ++ >> include/media/ti-media/vpfe_capture.h | 202 +++ >> include/media/ti-media/vpfe_types.h | 51 + >> include/media/ti-media/vpss.h | 69 + >> 46 files changed, 11207 insertions(+), 11040 deletions(-) >> delete mode 100644 drivers/media/video/davinci/Makefile >> delete mode 100644 drivers/media/video/davinci/ccdc_hw_device.h >> delete mode 100644 drivers/media/video/davinci/dm355_ccdc.c >> delete mode 10
Re: Problem with gspca and zc3xx
El Lunes, 11 de Enero de 2010, Jean-Francois Moine escribió: > On Mon, 11 Jan 2010 09:37:29 +0100 > > Hans de Goede wrote: > > This is the infamous zc3xx bottom of the image is missing in 320x240 > > problem, with several sensors the register settings we took from the > > windows driver will only give you 320x232 (iirc), we tried changing > > them to get 320x240, but then the camera would not stream. Most > > likely some timing issue between bridge and sensor. > > > > I once had a patch fixing this by actually reporting the broken modes > > as 320x232, but that never got applied as it breaks app which are > > hardcoded to ask for 320x240. libv4l has had the ability to extend > > the 320x232 image to 320x240 for a while now (by adding a few black > > lines at the top + bottom), fixing the hardcoded apps problem. > > > > So I think such a patch can and should be applied now. This will get > > rid of the jpeg decompression errors reported by libv4l and in case > > if yuv mode the ugly green bar with some random noise in it at the > > bottom. > > > > I'm afraid my patch is most likely lost, but I can create a new one > > if you want, I have access to quite a few zc3xx camera's, and more > > over what resolution they are actually streaming at can be deducted > > from the register settings in the driver. > > Hi Hans, > > As you may see in Jose Alberto's message, the problem occurs with > 640x480 and, yes, the image bottom is lacking, but also the right side. > > I did not lose your patch, but I did not apply it because most of the > time, the webcams work in the best resolution (VGA) and the associated > problem has not found yet a good resolution... > > Regards. > I take another image with 640x480 and the bad bottom lines are 8. The right side look right this time. The good sizes are: 320x240->320x232 640x480->640x472 Jose Alberto <>
Re: [PATCH 00/11] add linux driver for chip TLG2300
Em Wed, 09 Dec 2009 17:08:27 -0200 Mauro Carvalho Chehab escreveu: > Huang Shijie wrote: > > The TLG2300 is a chip of Telegent System. > > It support analog tv,DVB-T and radio in a single chip. > > The chip has been used in several dongles, such as aeromax DH-9000: > > http://www.b2bdvb.com/dh-9000.htm > > > > You can get more info from: > > [1] http://www.telegent.com/ > > [2] http://www.telegent.com/press/2009Sept14_CSI.html > > > > Huang Shijie (10): > > add maitainers for tlg2300 > > add readme file for tlg2300 > > add Kconfig and Makefile for tlg2300 > > add header files for tlg2300 > > add the generic file > > add video file for tlg2300 > > add vbi code for tlg2300 > > add audio support for tlg2300 > > add DVB-T support for tlg2300 > > add FM support for tlg2300 > > > > Ok, finished reviewing it. > > Patches 01, 02 and 04 seems ok to me. You didn't sent a patch 03. > Patch 05 will likely need some changes (the headers) due to some reviews I did > on the other patches. > > The other patches need some adjustments, as commented on separate emails. > Hi Huang, Happy new year! Had you finish fixing the pointed issues? 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: Problem with gspca and zc3xx
On Mon, 11 Jan 2010 09:37:29 +0100 Hans de Goede wrote: > This is the infamous zc3xx bottom of the image is missing in 320x240 > problem, with several sensors the register settings we took from the > windows driver will only give you 320x232 (iirc), we tried changing > them to get 320x240, but then the camera would not stream. Most > likely some timing issue between bridge and sensor. > > I once had a patch fixing this by actually reporting the broken modes > as 320x232, but that never got applied as it breaks app which are > hardcoded to ask for 320x240. libv4l has had the ability to extend > the 320x232 image to 320x240 for a while now (by adding a few black > lines at the top + bottom), fixing the hardcoded apps problem. > > So I think such a patch can and should be applied now. This will get > rid of the jpeg decompression errors reported by libv4l and in case > if yuv mode the ugly green bar with some random noise in it at the > bottom. > > I'm afraid my patch is most likely lost, but I can create a new one > if you want, I have access to quite a few zc3xx camera's, and more > over what resolution they are actually streaming at can be deducted > from the register settings in the driver. Hi Hans, As you may see in Jose Alberto's message, the problem occurs with 640x480 and, yes, the image bottom is lacking, but also the right side. I did not lose your patch, but I did not apply it because most of the time, the webcams work in the best resolution (VGA) and the associated problem has not found yet a good resolution... Regards. -- 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: Problem with gspca and zc3xx
Hi, On 01/10/2010 09:37 AM, Jean-Francois Moine wrote: On Sat, 9 Jan 2010 00:15:31 +0100 Jose Alberto Reguero wrote: When capturing with mplayer I have this erros and the bottom of the image is black. [mjpeg @ 0xd2f300]error y=29 x=0 [mjpeg @ 0xd2f300]mjpeg_decode_dc: bad vlc: 0:0 (0x2c565b0) [snip] gspca: main v2.8.0 registered gspca: probing 046d:08dd zc3xx: Sensor MC501CB gspca: video0 created gspca: probing 046d:08dd gspca: intf != 0 gspca: probing 046d:08dd gspca: intf != 0 usbcore: registered new interface driver zc3xx zc3xx: registered Hello Jose Alberto, May you send me a raw image done by my program svv? (look in my web page below - run it by 'svv -rg' and send me the generated image.dat) JF, This is the infamous zc3xx bottom of the image is missing in 320x240 problem, with several sensors the register settings we took from the windows driver will only give you 320x232 (iirc), we tried changing them to get 320x240, but then the camera would not stream. Most likely some timing issue between bridge and sensor. I once had a patch fixing this by actually reporting the broken modes as 320x232, but that never got applied as it breaks app which are hardcoded to ask for 320x240. libv4l has had the ability to extend the 320x232 image to 320x240 for a while now (by adding a few black lines at the top + bottom), fixing the hardcoded apps problem. So I think such a patch can and should be applied now. This will get rid of the jpeg decompression errors reported by libv4l and in case if yuv mode the ugly green bar with some random noise in it at the bottom. I'm afraid my patch is most likely lost, but I can create a new one if you want, I have access to quite a few zc3xx camera's, and more over what resolution they are actually streaming at can be deducted from the register settings in the driver. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gspca_sunplus problem: more than one device is created
Hi, On 01/10/2010 08:35 PM, Jean-Francois Moine wrote: On Sun, 10 Jan 2010 17:38:00 +0100 Németh Márton wrote: I tried the gspca_sunplus driver from http://linuxtv.org/hg/~jfrancois/gspca/ rev 13915 on top of Linux kernel 2.6.32. When I plug the Trust 610 LCD pow...@m Zoom device in webcam mode (0x06d6:0x0031) then two devices are created: /dev/video0 and /dev/video1: [snip] OK, this is a bug. I did not imagine that some webcams had the same interface class for two different devices. I am fixing it. JF, You did not mark this as high priority, still it should go into 2.6.33. can you please send a mail to Mauro asking for this ? Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull request: http://linuxtv.org/hg/~hgoede/gspca
Hi, On 01/10/2010 12:53 PM, Mauro Carvalho Chehab wrote: Hans de Goede wrote: Hi Mauro, Please pull from: http://linuxtv.org/hg/~hgoede/gspca For: 1) A high priority (should go to 2.6.33) mr97310a driver fix 2) A new driver for streaming from sn9c2028 cams 3) Some gspca documentation updates Hmm... your tree has 10 patches instead of 3.: /tmp/newpatches/hg_gspca_01.patch with cs=47d5a57b0183 First patch. /tmp/newpatches/hg_gspca_02.patch with cs=04eee693d37b Ok. /tmp/newpatches/hg_gspca_03.patch with cs=c7f961161530 Ok. /tmp/newpatches/hg_gspca_04.patch with cs=da3d3538b4c4 Ok. /tmp/newpatches/hg_gspca_05.patch with cs=98cecfa3c4f1 Ok. /tmp/newpatches/hg_gspca_06.patch with cs=bfe405de18aa Ok. /tmp/newpatches/hg_gspca_07.patch with cs=325c97ecffd2 Ok. /tmp/newpatches/hg_gspca_08.patch with cs=2e531e32ca6f Ok. /tmp/newpatches/hg_gspca_09.patch with cs=3563e7b617fe Ok. /tmp/newpatches/hg_gspca_10.patch with cs=21d70b6ed9f6 Ok. As I'm not sure if all of them are ready for merging, the better is to wait for a new pull request. Next time, please avoid add newer patches on a tree you've asked me to pull, or reply your pull email warning me that you've added more patches on your tree. Sorry, I wanted to send a new pull request yesterday, telling you to pull all 10 changes, 9 of time are marked as high priority, iow are meant for 2.6.33, the 10th one is a new driver so could go to 2.6.33 too, but does not has to. Summary of the changes: gspca_ov519: Several fixes related to ov519 + ov7648 gscpa_stv0680: Fix cam not streaming on hotplug gscpa_stv0680: Fix VGA cams not streaming gspca_sn9c2028: New gspca subdriver gscpa_sonixb:Fix hstart of tas5110d sensor Thanks & Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Pinnacle Pctv Hybrid Pro Stick 330E and DVB
Good morning. I have a Pinnacle Pctv Hybrid Pro Stick 330E. Downloaded, compiled and install last drivers from v4l-dvb via mercurial. - Downloaded the windows driver fromt http://www.steventoth.net/linux/xc5000/HVR-12x0-14x0-17x0_1_25_25271_WHQL.zip - Extracted the firmware xc3028-v27.fw into /lib/firmware Analog TV works, but what about dvb? I see /dev/vbi0 in /dev, but it seems not to be enough to have neither kdetv nor klear nor dvbscan work... They are probably looking for something inside /dev/dvb/adapter... Is this card supported? I remember, maybe about one year ago, I had watched DVB-T tv with the Pctv Hybrid Pro Stick... Thanks in advance. Giacomo. -- Giacomo S. http://www.giacomos.it - - - - - - - - - - - - - - - - - - - - - - * Aprile 2008: iqfire-wall, un progetto open source che implementa un filtro di pacchetti di rete per Linux, e` disponibile per il download qui: http://sourceforge.net/projects/ipfire-wall * Informazioni e pagina web ufficiale: http://www.giacomos.it/iqfire/index.html - - - - - - - - - - - - - - - - - - - - - - . '' `. : :': `. ` ' `- Debian GNU/Linux -- The power of freedom http://www.debian.org -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: gspca_pac7302: sporatdic problem when plugging the device
Sorry, I forgot to attach the patch. > In some usbsnoop files I have, the index 0x48 is not loaded. May you > try the attached patch (skip the index 0x48 and remove the delay). > > (Stéphane, est-ce que tu peux voir aussi ce que ça donne chez toi?) Regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ pac7302.pat Description: Binary data
Re: gspca_pac7302: sporatdic problem when plugging the device
On Sun, 10 Jan 2010 21:28:29 +0100 Németh Márton wrote: > I tested the behaviour a little bit more. Out of 100 plug-ins: > > OK: 81 times > "pac7302: reg_w_page(): Failed to write register to index 0x49, value > 0x0, error -71": 19 times > > Other error message I haven't got, so 19% of the time writing to > register index 0x49 fails in reg_w_page(). So let's try doing fixing > the way you described. If you send me a patch I can test it. In some usbsnoop files I have, the index 0x48 is not loaded. May you try the attached patch (skip the index 0x48 and remove the delay). (Stéphane, est-ce que tu peux voir aussi ce que ça donne chez toi?) Regards. -- 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
