does vpfe driver support select or poll sys call?
dear all:
I want to use select method to query data in capture buffer(ioctl VIDIOC_DQBUF
),but when i look up the driver in davinci_vpfe.c,I cann't find it realized it:
static struct file_operations vpfe_fops = {
.owner = THIS_MODULE,
.open = vpfe_open,
.release = vpfe_release,
.ioctl = vpfe_ioctl,
.mmap = vpfe_mmap
};
It has not realized poll() function in the file_operations set! so it is
uselessly for sys_call select i thinked! but the v4l2 interface support the
system call!
2009-08-17
zuowenping
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Regarding increase in Sever Thread stack size
Thanks for your reply. I am looking for the same. Is there any max limit for
this segment?
Many Thanks,
Sandeep.Yedire
From: Tivy, Robert rt...@ti.com
To: Sandeep YEDIRE sandee...@yahoo.co.in;
davinci-linux-open-source@linux.davincidsp.com
davinci-linux-open-source@linux.davincidsp.com
Cc: Sandeep Yedire sande...@acmet.com
Sent: Saturday, 15 August, 2009 5:09:38 AM
Subject: RE: Regarding increase in Sever Thread stack size
Is this what you're looking
for?:
var Server =
xdc.useModule('ti.sdo.ce.Server');
Server.algs =
[
{name: viddec_copy, mod: VIDDEC_COPY, threadAttrs:
{
stackSize: 0x4096, stackMemId: 0, priority: Server.MINPRI + 2}, groupId
:
0,
},
{name: videnc_copy, mod:
VIDENC_COPY, threadAttrs: {
stackMemId: 0, priority: Server.MINPRI + 2}, groupId : 0,
}
];
The max limit is dictated by your available memory for BIOS
TSK stacks.
- Rob
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf
Of Sandeep YEDIRE
Sent: Tuesday, August 11, 2009 10:34
PM
To: davinci-linux-open-source@linux.davincidsp.com
Cc: Sandeep Yedire
Subject: Regarding increase in Sever Thread stack
size
Hello all,
is there anyway to increase server thread stack size for one
particular codec? What is max limit ?
Many
Thanks,
Sandeep.Yedire
See the Web's breaking stories, chosen by people like you. Check out Yahoo!
Buzz.
Yahoo! recommends that you upgrade to the new and safer Internet Explorer
8. http://downloads.yahoo.com/in/internetexplorer/___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
davinci_enc_mngr for git 2.6.31 kernel?
To pick up some later bug fixes, I'm moving from MV 2.6.18 to git kernel 2.6.31-rc5. I see that the davinci_enc_mngr driver is not present in the git tree. Is this driver no longer necessary, not yet supported, or what? If this driver isn't available, what are the ramifications? Thanks, --jc ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v2] SPI: DaVinci: Adding SPI driver for DaVinci
This patch adds support for SPI in DaVinci DM6446
(and tries to keep support for DM355/DM365/DM6467 and DA8xx).
Mostly the same as the patch by Sandeep Paulraj.
This has been tested on the DM6446 by defining a spidev device and using a
scope (to check correctness) and a hardware loopback.
This was NOT tested on DM355, DM365 and DM6467 - in fact, it will probably
not work as is because its default mode is CS low-inactive (default mode
of SPI in kernel) - need to set CS_HIGH mode to work as in the previous patch.
Changes from the patch by Sandeep Paulraj:
Bug fixes:
* Additional word written with chip select up after each transfer.
Particulary problematic with NO_CS mode where this word can't be
distiguished from correct words. Problem was in davinci_chip_select.
* setup() for one chip select may interfere with transfer for another
* Small nitpicks (bits that can be changed only on VERSION_2)
Features added:
* Support DM6446
* Support CS_HIGH mode (using SPIDEF register). Note that CS low is default.
Other:
* Less accesses to registers used.
* Once-per-device configuration is done only in probe(), not each transfer.
Uglyness still there:
* VERSION_X definitions for different SPI controllers - added VERSION_3
for the dm6446, which is ugly.
NOTE:
This patch is based on following patches:
SPI: DaVinci: Adding SPI driver for DM3xx/DM6467/DA8xx
The patch adds support for SPI in DaVinci
DM355/DM365/DM6467 and DA8xx.
This has been tested on the DM355, DM365 and DM6467 EVMs using
the EEPROM connected to SPI0
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
DaVinci: DM646x: Adding Support for SPI
The patch does the following
1) Adds a clock for SPI
2) Defines resources specific to DM646x SOC
Signed-off-by: Sandeep Paulraj s-paul...@ti.com
Signed-off-by: Pablo Bitton pablo.bit...@gmail.com
---
arch/arm/mach-davinci/dm644x.c | 50 ++-
arch/arm/mach-davinci/dm646x.c | 53 ++
arch/arm/mach-davinci/include/mach/dm644x.h |3 +
arch/arm/mach-davinci/include/mach/dm646x.h |2 +
arch/arm/mach-davinci/include/mach/spi.h| 46 ++
drivers/spi/Kconfig |7 +
drivers/spi/Makefile|1 +
drivers/spi/davinci_spi.c | 771 +++
drivers/spi/davinci_spi.h | 178 ++
12 files changed, 1149 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/mach-davinci/include/mach/spi.h
create mode 100644 drivers/spi/davinci_spi.c
create mode 100644 drivers/spi/davinci_spi.h
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 55317b1..d395354 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -14,6 +14,7 @@
#include linux/serial_8250.h
#include linux/platform_device.h
#include linux/gpio.h
+#include linux/spi/spi.h
#include asm/mach/map.h
@@ -28,6 +29,7 @@
#include mach/serial.h
#include mach/common.h
#include mach/asp.h
+#include mach/spi.h
#include clock.h
#include mux.h
@@ -306,7 +308,7 @@ struct davinci_clk dm644x_clks[] = {
CLK(palm_bk3710, NULL, ide_clk),
CLK(davinci-asp, NULL, asp_clk),
CLK(davinci_mmc.0, NULL, mmcsd_clk),
- CLK(NULL, spi, spi_clk),
+ CLK(spi_davinci.0, NULL, spi_clk),
CLK(NULL, gpio, gpio_clk),
CLK(NULL, usb, usb_clk),
CLK(NULL, vlynq, vlynq_clk),
@@ -320,6 +322,52 @@ struct davinci_clk dm644x_clks[] = {
CLK(NULL, NULL, NULL),
};
+
+static u64 dm644x_spi_dma_mask = DMA_BIT_MASK(32);
+
+static struct davinci_spi_platform_data dm644x_spi_pdata = {
+ .version= SPI_VERSION_3,
+ .num_chipselect = 2,
+ .clk_internal = 1,
+ .cs_hold= 0,
+ .intr_level = 0,
+ .poll_mode = 1,
+ .c2tdelay = 8,
+ .t2cdelay = 8,
+};
+
+static struct resource dm644x_spi_resources[] = {
+ {
+ .start = 0x01c66800,
+ .end = 0x01c66fff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = IRQ_SPINT0,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct platform_device dm644x_spi_device = {
+ .name = spi_davinci,
+ .id = 0,
+ .dev = {
+ .dma_mask = dm644x_spi_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = dm644x_spi_pdata,
+ },
+ .num_resources = ARRAY_SIZE(dm644x_spi_resources),
+ .resource = dm644x_spi_resources,
+};
+
+void __init dm644x_init_spi(struct spi_board_info *info, unsigned len)
+{
+ spi_register_board_info(info, len);
+
+ platform_device_register(dm644x_spi_device);
+}
+
+
static struct emac_platform_data dm644x_emac_pdata = {
.ctrl_reg_offset= DM644X_EMAC_CNTRL_OFFSET,
.ctrl_mod_reg_offset= DM644X_EMAC_CNTRL_MOD_OFFSET,
diff --git a/arch/arm/mach-davinci/dm646x.c
Building Encode/Decode demo application for DVSDK2.0
Hi, I have recently migrated to DVSDK version 2.00.00.22 from 1.20 for DM6446. I am trying to build decode and encode demo application but am encountering error. I figured out that it is on the very first step, that is --à xs xdc.tools.configuro The reason for the same is that, I don’t have ‘xdc’ folder in xdctools_3_10_03/packages. Thus, xs is not able to find xdc.tools.configuro script at all. Can somebody tell me how I can overcome the same ? I tried using xdc_3_10_00_08 pacakge as it had ‘xdc/tools/configuro’ folder within the external folder. However, it got me stuck with the error “Cannot find function : findSuffix’”. Your response will be highly appreciated: My environment has following components: bios_5_33_03 xdc_3_10_03 CG_tools_6_0_21 biosutils_1_01_00 ceutils_1_06 cg_xml_2_12_00 codec_engine_2_23_01 dm6446_dvsdk_combos_2_05 dmai_1_20_00_06 dsplink-1_61_03-prebuilt dvsdk_demos_2_00_00_07 dvtb_4_00_08 edma3_lld_1_05_00 framework_components_2_23_01 linuxutils_2_23_01 PSP_02_00_00_140 xdais_6_23 Regards, -- Bhushan ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: does vpfe driver support select or poll sys call?
Hi,
Poll() is not supported, but you could do select() call. Please try it. It had
worked for us.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
zuowenping
Sent: Monday, August 17, 2009 2:41 AM
To: davinci-linux-open-source
Subject: does vpfe driver support select or poll sys call?
dear all:
I want to use select method to query data in capture buffer(ioctl VIDIOC_DQBUF
),but when i look up the driver in davinci_vpfe.c,I cann't find it realized it:
static struct file_operations vpfe_fops = {
.owner = THIS_MODULE,
.open = vpfe_open,
.release = vpfe_release,
.ioctl = vpfe_ioctl,
.mmap = vpfe_mmap
};
It has not realized poll() function in the file_operations set! so it is
uselessly for sys_call select i thinked! but the v4l2 interface support the
system call!
2009-08-17
zuowenping
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: does vpfe driver support select or poll sys call?
Hi, On Monday 17 August 2009 16:46:07 Karicheri, Muralidharan wrote: Hi, Poll() is not supported, but you could do select() call. Please try it. It had worked for us. That's quite weird, as the select syscall uses the poll file operation internally. I suppose the original poster was referring to the LSP 2.6.18 kernel, while you might be referring to the public patches sent for inclusion in the mainline kernel. Implementing poll support in the LSP kernel shouldn't be difficult, it seems to just be a matter of calling videobuf_poll_stream(). -- Regards, Laurent Pinchart ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
Hans, They are applied against davinci tree (also mentioned in the patch). General procedure what I follow is to create platform code against davinci tree and v4l patches against v4l-dvb linux-next tree. The architecture part of linux-next is not up to date. Davinci tree is at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Saturday, August 15, 2009 8:10 AM To: Karicheri, Muralidharan Cc: linux-me...@vger.kernel.org; davinci-linux-open- sou...@linux.davincidsp.com; khil...@deeprootsystems.com Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver On Friday 14 August 2009 23:01:41 m-kariche...@ti.com wrote: From: Muralidharan Karicheri m-kariche...@ti.com This patch makes the following changes:- 1) Modify vpif_subdev_info to add board_info, routing information and vpif interface configuration. Remove addr since it is part of board_info 2) Add code to setup channel mode and input decoder path for vpif capture driver Also incorporated comments against version v0 of the patch series and added a spinlock to protect writes to common registers A quick question: against which git tree are these arch changes applied? I've lost track of that :-) Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
Stijn,
If you could provide me the details of tweakings that you have made, it would
help me to improve the driver.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com
From: Stijn Devriendt [mailto:high...@gmail.com]
Sent: Saturday, August 15, 2009 2:19 AM
To: Karicheri, Muralidharan; Davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
This code is so EVM specific, instead of SOC-specific.
In order to connect 2 DM646x chips directly via VPIF
this driver requires quite a bit of tweaking.
(I know because I had to do this before ;) )
Please share the details so that I could explain if that is an issue with this
driver and if so, we could update the driver with another patch to take care of
the same.
I'd appreciate a more loosely coupled subdevice layer.
The sub device layer is implemented using v4l2 sub device framework. If you
check all of the video drivers that uses sub device framework, you would see
similar implementation. There is a well defined interface for bridge driver to
interface with sub devices. So I don't understand what is your concern here. I
suggest you discuss your concern in the linux-media mailing list.
VPIF itself doesn't use I2C so this stuff should belong
elsewhere.
The driver consists of 2 parts.
vpif_capture.c has the bridge driver. As per sub device framework, the bridge
driver is aware of all sub devices it works with. The i2c adapter information
is required to load up an i2c sub device. So we can't help on that. If the sub
device is not i2c specific, then there are other APIs to load up the module. So
this driver will be able to work any sub device that implements the v4l2 sub
device APIs.
The sub device part which in this is tvp514x module. It is written for v4l2 sub
device interface. If you could discuss specific issues, it will be easy to
understand your concerns.
Secondly I can imagine any board other
than the EVM uses other codec chips (either I2C or not).
So basically the whole codec stuff would preferable be
split out of the core VPIF driver.
Not sure what you mean here. Can you clarify what codec part you are talking
about?
Regards,
Stijn
+/**
+ * vpif_probe : This function probes the vpif capture driver
+ * @pdev: platform device pointer
+ *
+ * This creates device entries by register itself to the V4L2 driver and
+ * initializes fields of each channel objects
+ */
+static __init int vpif_probe(struct platform_device *pdev)
+{
+ struct vpif_subdev_info *subdevdata;
+ struct vpif_capture_config *config;
+ int i, j, k, m, q, err;
+ struct i2c_adapter *i2c_adap;
+ struct channel_obj *ch;
+ struct common_obj *common;
+ struct video_device *vfd;
+ struct resource *res;
+ int subdev_count;
+
+ vpif_dev = pdev-dev;
+
+ err = initialize_vpif();
+ if (err) {
+ v4l2_err(vpif_dev-driver, Error initializing vpif\n);
+ return err;
+ }
+
+ k = 0;
+ while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, k))) {
+ for (i = res-start; i = res-end; i++) {
+ if (request_irq(i, vpif_channel_isr, IRQF_DISABLED,
+ DM646x_Capture,
+ (void *)(vpif_obj.dev[k]-channel_id))) {
+ err = -EBUSY;
+ i--;
+ goto vpif_int_err;
+ }
+ }
+ k++;
+ }
+
+ for (i = 0; i VPIF_CAPTURE_MAX_DEVICES; i++) {
+ /* Get the pointer to the channel object */
+ ch = vpif_obj.dev[i];
+ /* Allocate memory for video device */
+ vfd = video_device_alloc();
+ if (NULL == vfd) {
+ for (j = 0; j i; j++) {
+ ch = vpif_obj.dev[j];
+ video_device_release(ch-video_dev);
+ }
+ err = -ENOMEM;
+ goto vpif_dev_alloc_err;
+ }
+
+ /* Initialize field of video device */
+ *vfd = vpif_video_template;
+ vfd-v4l2_dev = vpif_obj.v4l2_dev;
+ vfd-release = video_device_release;
+ snprintf(vfd-name, sizeof(vfd-name),
+DM646x_VPIFCapture_DRIVER_V%d.%d.%d,
+(VPIF_CAPTURE_VERSION_CODE 16) 0xff,
+(VPIF_CAPTURE_VERSION_CODE 8) 0xff,
+(VPIF_CAPTURE_VERSION_CODE) 0xff);
+ /* Set video_dev to the video device */
+ ch-video_dev = vfd;
+ }
+
+ for (j = 0; j VPIF_CAPTURE_MAX_DEVICES; j++) {
+
RE: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
Khasim,
I think you are talking about Freon. Yes, the plan is to re-use the driver for
Freon. If there are no register changes, then just adding the vpif
configuration data such as register io address, irq etc in the board/platform
specific files, it would work on Freon. Minor changes to the register will
require customization in the vpif.c and vpif.h. If there are any difference in
the way encoder/decoder chips are connected to the vpif input or output, we
just need to change a function in the board specific file that switches the
input or output to the vpif.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com
From: Syed Mohammed, Khasim
Sent: Saturday, August 15, 2009 3:12 AM
To: Stijn Devriendt; Karicheri, Muralidharan;
Davinci-linux-open-source@linux.davincidsp.com
Subject: RE: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
Are we taking care of OMAP L 138 as well, since this chipset has similar VPIF
module, I expect we should be leveraging this code base as is.
Regards,
Khasim
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Stijn Devriendt
Sent: Saturday, August 15, 2009 11:49 AM
To: Karicheri, Muralidharan; Davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
This code is so EVM specific, instead of SOC-specific.
In order to connect 2 DM646x chips directly via VPIF
this driver requires quite a bit of tweaking.
(I know because I had to do this before ;) )
I'd appreciate a more loosely coupled subdevice layer.
VPIF itself doesn't use I2C so this stuff should belong
elsewhere. Secondly I can imagine any board other
than the EVM uses other codec chips (either I2C or not).
So basically the whole codec stuff would preferable be
split out of the core VPIF driver.
Regards,
Stijn
+/**
+ * vpif_probe : This function probes the vpif capture driver
+ * @pdev: platform device pointer
+ *
+ * This creates device entries by register itself to the V4L2 driver and
+ * initializes fields of each channel objects
+ */
+static __init int vpif_probe(struct platform_device *pdev)
+{
+ struct vpif_subdev_info *subdevdata;
+ struct vpif_capture_config *config;
+ int i, j, k, m, q, err;
+ struct i2c_adapter *i2c_adap;
+ struct channel_obj *ch;
+ struct common_obj *common;
+ struct video_device *vfd;
+ struct resource *res;
+ int subdev_count;
+
+ vpif_dev = pdev-dev;
+
+ err = initialize_vpif();
+ if (err) {
+ v4l2_err(vpif_dev-driver, Error initializing vpif\n);
+ return err;
+ }
+
+ k = 0;
+ while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, k))) {
+ for (i = res-start; i = res-end; i++) {
+ if (request_irq(i, vpif_channel_isr, IRQF_DISABLED,
+ DM646x_Capture,
+ (void *)(vpif_obj.dev[k]-channel_id))) {
+ err = -EBUSY;
+ i--;
+ goto vpif_int_err;
+ }
+ }
+ k++;
+ }
+
+ for (i = 0; i VPIF_CAPTURE_MAX_DEVICES; i++) {
+ /* Get the pointer to the channel object */
+ ch = vpif_obj.dev[i];
+ /* Allocate memory for video device */
+ vfd = video_device_alloc();
+ if (NULL == vfd) {
+ for (j = 0; j i; j++) {
+ ch = vpif_obj.dev[j];
+ video_device_release(ch-video_dev);
+ }
+ err = -ENOMEM;
+ goto vpif_dev_alloc_err;
+ }
+
+ /* Initialize field of video device */
+ *vfd = vpif_video_template;
+ vfd-v4l2_dev = vpif_obj.v4l2_dev;
+ vfd-release = video_device_release;
+ snprintf(vfd-name, sizeof(vfd-name),
+DM646x_VPIFCapture_DRIVER_V%d.%d.%d,
+(VPIF_CAPTURE_VERSION_CODE 16) 0xff,
+(VPIF_CAPTURE_VERSION_CODE 8) 0xff,
+(VPIF_CAPTURE_VERSION_CODE) 0xff);
+ /* Set video_dev to the video device */
+ ch-video_dev = vfd;
+ }
+
+ for (j = 0; j VPIF_CAPTURE_MAX_DEVICES; j++) {
+ ch = vpif_obj.dev[j];
+ ch-channel_id = j;
+ common = (ch-common[VPIF_VIDEO_INDEX]);
+ spin_lock_init(common-irqlock);
+ mutex_init(common-lock);
+ /* Initialize prio member of channel object */
+
RE: does vpfe driver support select or poll sys call?
Laurent, Thanks. That was my bad. I have checked up both the code base LSP 2.10 and Git version of the driver and both has support for poll/select. They call videobuf_poll_stream(). May be what is referenced here is LSP version older than this. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-kariche...@ti.com -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Monday, August 17, 2009 10:55 AM To: davinci-linux-open-source@linux.davincidsp.com Cc: Karicheri, Muralidharan; zuowenping Subject: Re: does vpfe driver support select or poll sys call? Hi, On Monday 17 August 2009 16:46:07 Karicheri, Muralidharan wrote: Hi, Poll() is not supported, but you could do select() call. Please try it. It had worked for us. That's quite weird, as the select syscall uses the poll file operation internally. I suppose the original poster was referring to the LSP 2.6.18 kernel, while you might be referring to the public patches sent for inclusion in the mainline kernel. Implementing poll support in the LSP kernel shouldn't be difficult, it seems to just be a matter of calling videobuf_poll_stream(). -- Regards, Laurent Pinchart ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
Hi Murali,
Thanks for confirming this, I will give a try later this week. Will get in
touch with you.
Regards,
Khasim
From: Karicheri, Muralidharan
Sent: Monday, August 17, 2009 9:24 PM
To: Syed Mohammed, Khasim; Stijn Devriendt;
Davinci-linux-open-source@linux.davincidsp.com
Subject: RE: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
Khasim,
I think you are talking about Freon. Yes, the plan is to re-use the driver for
Freon. If there are no register changes, then just adding the vpif
configuration data such as register io address, irq etc in the board/platform
specific files, it would work on Freon. Minor changes to the register will
require customization in the vpif.c and vpif.h. If there are any difference in
the way encoder/decoder chips are connected to the vpif input or output, we
just need to change a function in the board specific file that switches the
input or output to the vpif.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com
From: Syed Mohammed, Khasim
Sent: Saturday, August 15, 2009 3:12 AM
To: Stijn Devriendt; Karicheri, Muralidharan;
Davinci-linux-open-source@linux.davincidsp.com
Subject: RE: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
Are we taking care of OMAP L 138 as well, since this chipset has similar VPIF
module, I expect we should be leveraging this code base as is.
Regards,
Khasim
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Stijn Devriendt
Sent: Saturday, August 15, 2009 11:49 AM
To: Karicheri, Muralidharan; Davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
This code is so EVM specific, instead of SOC-specific.
In order to connect 2 DM646x chips directly via VPIF
this driver requires quite a bit of tweaking.
(I know because I had to do this before ;) )
I'd appreciate a more loosely coupled subdevice layer.
VPIF itself doesn't use I2C so this stuff should belong
elsewhere. Secondly I can imagine any board other
than the EVM uses other codec chips (either I2C or not).
So basically the whole codec stuff would preferable be
split out of the core VPIF driver.
Regards,
Stijn
+/**
+ * vpif_probe : This function probes the vpif capture driver
+ * @pdev: platform device pointer
+ *
+ * This creates device entries by register itself to the V4L2 driver and
+ * initializes fields of each channel objects
+ */
+static __init int vpif_probe(struct platform_device *pdev)
+{
+ struct vpif_subdev_info *subdevdata;
+ struct vpif_capture_config *config;
+ int i, j, k, m, q, err;
+ struct i2c_adapter *i2c_adap;
+ struct channel_obj *ch;
+ struct common_obj *common;
+ struct video_device *vfd;
+ struct resource *res;
+ int subdev_count;
+
+ vpif_dev = pdev-dev;
+
+ err = initialize_vpif();
+ if (err) {
+ v4l2_err(vpif_dev-driver, Error initializing vpif\n);
+ return err;
+ }
+
+ k = 0;
+ while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, k))) {
+ for (i = res-start; i = res-end; i++) {
+ if (request_irq(i, vpif_channel_isr, IRQF_DISABLED,
+ DM646x_Capture,
+ (void *)(vpif_obj.dev[k]-channel_id))) {
+ err = -EBUSY;
+ i--;
+ goto vpif_int_err;
+ }
+ }
+ k++;
+ }
+
+ for (i = 0; i VPIF_CAPTURE_MAX_DEVICES; i++) {
+ /* Get the pointer to the channel object */
+ ch = vpif_obj.dev[i];
+ /* Allocate memory for video device */
+ vfd = video_device_alloc();
+ if (NULL == vfd) {
+ for (j = 0; j i; j++) {
+ ch = vpif_obj.dev[j];
+ video_device_release(ch-video_dev);
+ }
+ err = -ENOMEM;
+ goto vpif_dev_alloc_err;
+ }
+
+ /* Initialize field of video device */
+ *vfd = vpif_video_template;
+ vfd-v4l2_dev = vpif_obj.v4l2_dev;
+ vfd-release = video_device_release;
+ snprintf(vfd-name, sizeof(vfd-name),
+DM646x_VPIFCapture_DRIVER_V%d.%d.%d,
+(VPIF_CAPTURE_VERSION_CODE 16) 0xff,
+(VPIF_CAPTURE_VERSION_CODE 8) 0xff,
+(VPIF_CAPTURE_VERSION_CODE) 0xff);
+ /* Set video_dev to the video device */
+
RE: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
Khasim,
Could you let me know what you are trying to do?
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
From: Syed Mohammed, Khasim
Sent: Monday, August 17, 2009 12:02 PM
To: Karicheri, Muralidharan; Stijn Devriendt;
Davinci-linux-open-source@linux.davincidsp.com
Subject: RE: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
Hi Murali,
Thanks for confirming this, I will give a try later this week. Will get in
touch with you.
Regards,
Khasim
From: Karicheri, Muralidharan
Sent: Monday, August 17, 2009 9:24 PM
To: Syed Mohammed, Khasim; Stijn Devriendt;
Davinci-linux-open-source@linux.davincidsp.com
Subject: RE: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
Khasim,
I think you are talking about Freon. Yes, the plan is to re-use the driver for
Freon. If there are no register changes, then just adding the vpif
configuration data such as register io address, irq etc in the board/platform
specific files, it would work on Freon. Minor changes to the register will
require customization in the vpif.c and vpif.h. If there are any difference in
the way encoder/decoder chips are connected to the vpif input or output, we
just need to change a function in the board specific file that switches the
input or output to the vpif.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com
From: Syed Mohammed, Khasim
Sent: Saturday, August 15, 2009 3:12 AM
To: Stijn Devriendt; Karicheri, Muralidharan;
Davinci-linux-open-source@linux.davincidsp.com
Subject: RE: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
Are we taking care of OMAP L 138 as well, since this chipset has similar VPIF
module, I expect we should be leveraging this code base as is.
Regards,
Khasim
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Stijn Devriendt
Sent: Saturday, August 15, 2009 11:49 AM
To: Karicheri, Muralidharan; Davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
This code is so EVM specific, instead of SOC-specific.
In order to connect 2 DM646x chips directly via VPIF
this driver requires quite a bit of tweaking.
(I know because I had to do this before ;) )
I'd appreciate a more loosely coupled subdevice layer.
VPIF itself doesn't use I2C so this stuff should belong
elsewhere. Secondly I can imagine any board other
than the EVM uses other codec chips (either I2C or not).
So basically the whole codec stuff would preferable be
split out of the core VPIF driver.
Regards,
Stijn
+/**
+ * vpif_probe : This function probes the vpif capture driver
+ * @pdev: platform device pointer
+ *
+ * This creates device entries by register itself to the V4L2 driver and
+ * initializes fields of each channel objects
+ */
+static __init int vpif_probe(struct platform_device *pdev)
+{
+ struct vpif_subdev_info *subdevdata;
+ struct vpif_capture_config *config;
+ int i, j, k, m, q, err;
+ struct i2c_adapter *i2c_adap;
+ struct channel_obj *ch;
+ struct common_obj *common;
+ struct video_device *vfd;
+ struct resource *res;
+ int subdev_count;
+
+ vpif_dev = pdev-dev;
+
+ err = initialize_vpif();
+ if (err) {
+ v4l2_err(vpif_dev-driver, Error initializing vpif\n);
+ return err;
+ }
+
+ k = 0;
+ while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, k))) {
+ for (i = res-start; i = res-end; i++) {
+ if (request_irq(i, vpif_channel_isr, IRQF_DISABLED,
+ DM646x_Capture,
+ (void *)(vpif_obj.dev[k]-channel_id))) {
+ err = -EBUSY;
+ i--;
+ goto vpif_int_err;
+ }
+ }
+ k++;
+ }
+
+ for (i = 0; i VPIF_CAPTURE_MAX_DEVICES; i++) {
+ /* Get the pointer to the channel object */
+ ch = vpif_obj.dev[i];
+ /* Allocate memory for video device */
+ vfd = video_device_alloc();
+ if (NULL == vfd) {
+ for (j = 0; j i; j++) {
+ ch = vpif_obj.dev[j];
+ video_device_release(ch-video_dev);
+ }
+ err = -ENOMEM;
+ goto vpif_dev_alloc_err;
+ }
+
+ /* Initialize field of video device */
+ *vfd = vpif_video_template;
+ vfd-v4l2_dev =
RE: [PATCH v1 - 4/5] V4L : vpif updates for DM6467 vpif capture driver
Vaibhav,
I don't see any serious issues raised here. I can send another patch to fix
this if needed.
Regards,
Murali
+#include linux/spinlock.h
#include linux/kernel.h
+#include linux/io.h
[Hiremath, Vaibhav] You may want to put one line gap here.
Ok. Just editorial.
+#include mach/hardware.h
#include vpif.h
@@ -31,6 +35,12 @@ MODULE_LICENSE(GPL);
#define VPIF_CH2_MAX_MODES (15)
#define VPIF_CH3_MAX_MODES (02)
+static resource_size_t res_len;
+static struct resource *res;
[Hiremath, Vaibhav] Do we really require this to be static variable?
I think we can manage it to be local variable.
Yes. We could. Probably change it with a new patch. Don't want to hold up merge
because of this.
+spinlock_t vpif_lock;
+
+void __iomem *vpif_base;
+
static inline void vpif_wr_bit(u32 reg, u32 bit, u32 val)
{
if (val)
@@ -151,17 +161,17 @@ static void config_vpif_params(struct
vpif_params *vpifparams,
else if (config-capture_format) {
/* Set the polarity of various pins */
vpif_wr_bit(reg, VPIF_CH_FID_POLARITY_BIT,
-vpifparams-
params.raw_params.fid_pol);
+vpifparams-iface.fid_pol);
vpif_wr_bit(reg, VPIF_CH_V_VALID_POLARITY_BIT,
-vpifparams-params.raw_params.vd_pol);
+vpifparams-iface.vd_pol);
vpif_wr_bit(reg, VPIF_CH_H_VALID_POLARITY_BIT,
-vpifparams-params.raw_params.hd_pol);
+vpifparams-iface.hd_pol);
value = regr(reg);
/* Set data width */
value = ((~(unsigned int)(0x3))
VPIF_CH_DATA_WIDTH_BIT);
-value |= ((vpifparams-params.raw_params.data_sz)
+value |= ((vpifparams-params.data_sz)
VPIF_CH_DATA_WIDTH_BIT);
regw(value, reg);
}
@@ -227,8 +237,60 @@ int vpif_channel_getfid(u8 channel_id)
}
EXPORT_SYMBOL(vpif_channel_getfid);
-void vpif_base_addr_init(void __iomem *base)
+static int __init vpif_probe(struct platform_device *pdev)
+{
+int status = 0;
+
+res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+if (!res)
+return -ENOENT;
+
+res_len = res-end - res-start + 1;
+
+res = request_mem_region(res-start, res_len, res-name);
+if (!res)
+return -EBUSY;
+
+vpif_base = ioremap(res-start, res_len);
+if (!vpif_base) {
+status = -EBUSY;
+goto fail;
+}
+
+spin_lock_init(vpif_lock);
+dev_info(pdev-dev, vpif probe success\n);
+return 0;
+
+fail:
+release_mem_region(res-start, res_len);
+return status;
+}
+
+static int vpif_remove(struct platform_device *pdev)
{
-vpif_base = base;
+iounmap(vpif_base);
+release_mem_region(res-start, res_len);
+return 0;
}
-EXPORT_SYMBOL(vpif_base_addr_init);
+
+static struct platform_driver vpif_driver = {
+.driver = {
+.name = vpif,
+.owner = THIS_MODULE,
+},
+.remove = __devexit_p(vpif_remove),
+.probe = vpif_probe,
+};
+
+static void vpif_exit(void)
+{
+platform_driver_unregister(vpif_driver);
+}
+
+static int __init vpif_init(void)
+{
+return platform_driver_register(vpif_driver);
+}
+subsys_initcall(vpif_init);
+module_exit(vpif_exit);
+
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h
index fca26dc..188841b 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -19,6 +19,7 @@
#include linux/io.h
#include linux/videodev2.h
[Hiremath, Vaibhav] one line gap here.
Again editorial.
#include mach/hardware.h
+#include mach/dm646x.h
/* Maximum channel allowed */
#define VPIF_NUM_CHANNELS (4)
@@ -26,7 +27,9 @@
#define VPIF_DISPLAY_NUM_CHANNELS (2)
/* Macros to read/write registers */
-static void __iomem *vpif_base;
+extern void __iomem *vpif_base;
+extern spinlock_t vpif_lock;
[Hiremath, Vaibhav] I think I would want to check compete driver. How these
extern variables have been used.
Let me know if you find some thing wrong in the driver. At this time, I just
don't see any issues with this.
+
#define regr(reg) readl((reg) + vpif_base)
#define regw(value, reg)writel(value, (reg + vpif_base))
@@ -280,6 +283,10 @@ static inline void enable_channel1(int enable)
/* inline function to enable interrupt for channel0 */
static inline void channel0_intr_enable(int enable)
{
+unsigned long flags;
+
+spin_lock_irqsave(vpif_lock, flags);
+
if (enable) {
regw((regr(VPIF_INTEN) | 0x10), VPIF_INTEN);
RE: [PATCH v1 - 4/5] V4L : vpif updates for DM6467 vpif capture driver
H Murali,
-Original Message-
From: Karicheri, Muralidharan
Sent: Monday, August 17, 2009 9:38 PM
To: Hiremath, Vaibhav; linux-me...@vger.kernel.org
Cc: davinci-linux-open-source@linux.davincidsp.com;
hverk...@xs4all.nl
Subject: RE: [PATCH v1 - 4/5] V4L : vpif updates for DM6467 vpif
capture driver
Vaibhav,
I don't see any serious issues raised here. I can send another patch
to fix this if needed.
[Hiremath, Vaibhav] yes most of them are editorial, as I mentioned I just
reviewed it quickly.
But as far as static variables are concerned I still think we can avoid them
completely, again it's not critical though.
As I mentioned I will have to look for extern variables, how they have been
used and stuff like that.
As of now, I am ok if it gets merged.
Regards,
Murali
+#include linux/spinlock.h
#include linux/kernel.h
+#include linux/io.h
[Hiremath, Vaibhav] You may want to put one line gap here.
Ok. Just editorial.
+#include mach/hardware.h
#include vpif.h
@@ -31,6 +35,12 @@ MODULE_LICENSE(GPL);
#define VPIF_CH2_MAX_MODES(15)
#define VPIF_CH3_MAX_MODES(02)
+static resource_size_tres_len;
+static struct resource*res;
[Hiremath, Vaibhav] Do we really require this to be static
variable?
I think we can manage it to be local variable.
Yes. We could. Probably change it with a new patch. Don't want to
hold up merge because of this.
+spinlock_t vpif_lock;
+
+void __iomem *vpif_base;
+
static inline void vpif_wr_bit(u32 reg, u32 bit, u32 val)
{
if (val)
@@ -151,17 +161,17 @@ static void config_vpif_params(struct
vpif_params *vpifparams,
else if (config-capture_format) {
/* Set the polarity of various pins */
vpif_wr_bit(reg, VPIF_CH_FID_POLARITY_BIT,
- vpifparams-
params.raw_params.fid_pol);
+ vpifparams-iface.fid_pol);
vpif_wr_bit(reg, VPIF_CH_V_VALID_POLARITY_BIT,
- vpifparams-params.raw_params.vd_pol);
+ vpifparams-iface.vd_pol);
vpif_wr_bit(reg, VPIF_CH_H_VALID_POLARITY_BIT,
- vpifparams-params.raw_params.hd_pol);
+ vpifparams-iface.hd_pol);
value = regr(reg);
/* Set data width */
value = ((~(unsigned int)(0x3))
VPIF_CH_DATA_WIDTH_BIT);
- value |= ((vpifparams-params.raw_params.data_sz)
+ value |= ((vpifparams-params.data_sz)
VPIF_CH_DATA_WIDTH_BIT);
regw(value, reg);
}
@@ -227,8 +237,60 @@ int vpif_channel_getfid(u8 channel_id)
}
EXPORT_SYMBOL(vpif_channel_getfid);
-void vpif_base_addr_init(void __iomem *base)
+static int __init vpif_probe(struct platform_device *pdev)
+{
+ int status = 0;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENOENT;
+
+ res_len = res-end - res-start + 1;
+
+ res = request_mem_region(res-start, res_len, res-name);
+ if (!res)
+ return -EBUSY;
+
+ vpif_base = ioremap(res-start, res_len);
+ if (!vpif_base) {
+ status = -EBUSY;
+ goto fail;
+ }
+
+ spin_lock_init(vpif_lock);
+ dev_info(pdev-dev, vpif probe success\n);
+ return 0;
+
+fail:
+ release_mem_region(res-start, res_len);
+ return status;
+}
+
+static int vpif_remove(struct platform_device *pdev)
{
- vpif_base = base;
+ iounmap(vpif_base);
+ release_mem_region(res-start, res_len);
+ return 0;
}
-EXPORT_SYMBOL(vpif_base_addr_init);
+
+static struct platform_driver vpif_driver = {
+ .driver = {
+ .name = vpif,
+ .owner = THIS_MODULE,
+ },
+ .remove = __devexit_p(vpif_remove),
+ .probe = vpif_probe,
+};
+
+static void vpif_exit(void)
+{
+ platform_driver_unregister(vpif_driver);
+}
+
+static int __init vpif_init(void)
+{
+ return platform_driver_register(vpif_driver);
+}
+subsys_initcall(vpif_init);
+module_exit(vpif_exit);
+
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h
index fca26dc..188841b 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -19,6 +19,7 @@
#include linux/io.h
#include linux/videodev2.h
[Hiremath, Vaibhav] one line gap here.
Again editorial.
#include mach/hardware.h
+#include mach/dm646x.h
/* Maximum channel allowed */
#define VPIF_NUM_CHANNELS (4)
@@ -26,7 +27,9 @@
#define VPIF_DISPLAY_NUM_CHANNELS (2)
/* Macros to read/write registers */
-static void __iomem *vpif_base;
+extern void __iomem
RE: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
Murali,
I am working on OMAP L 138 based Low cost platform. This has Composite IN port,
I would like to write driver for this peripheral.
Thought of using your patches for the same.
Regards,
Khasim
From: Karicheri, Muralidharan
Sent: Monday, August 17, 2009 9:40 PM
To: Syed Mohammed, Khasim; Stijn Devriendt;
Davinci-linux-open-source@linux.davincidsp.com
Subject: RE: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
Khasim,
Could you let me know what you are trying to do?
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
From: Syed Mohammed, Khasim
Sent: Monday, August 17, 2009 12:02 PM
To: Karicheri, Muralidharan; Stijn Devriendt;
Davinci-linux-open-source@linux.davincidsp.com
Subject: RE: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
Hi Murali,
Thanks for confirming this, I will give a try later this week. Will get in
touch with you.
Regards,
Khasim
From: Karicheri, Muralidharan
Sent: Monday, August 17, 2009 9:24 PM
To: Syed Mohammed, Khasim; Stijn Devriendt;
Davinci-linux-open-source@linux.davincidsp.com
Subject: RE: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
Khasim,
I think you are talking about Freon. Yes, the plan is to re-use the driver for
Freon. If there are no register changes, then just adding the vpif
configuration data such as register io address, irq etc in the board/platform
specific files, it would work on Freon. Minor changes to the register will
require customization in the vpif.c and vpif.h. If there are any difference in
the way encoder/decoder chips are connected to the vpif input or output, we
just need to change a function in the board specific file that switches the
input or output to the vpif.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com
From: Syed Mohammed, Khasim
Sent: Saturday, August 15, 2009 3:12 AM
To: Stijn Devriendt; Karicheri, Muralidharan;
Davinci-linux-open-source@linux.davincidsp.com
Subject: RE: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
Are we taking care of OMAP L 138 as well, since this chipset has similar VPIF
module, I expect we should be leveraging this code base as is.
Regards,
Khasim
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Stijn Devriendt
Sent: Saturday, August 15, 2009 11:49 AM
To: Karicheri, Muralidharan; Davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH v1 - 3/5] V4L : vpif capture driver for DM6467
This code is so EVM specific, instead of SOC-specific.
In order to connect 2 DM646x chips directly via VPIF
this driver requires quite a bit of tweaking.
(I know because I had to do this before ;) )
I'd appreciate a more loosely coupled subdevice layer.
VPIF itself doesn't use I2C so this stuff should belong
elsewhere. Secondly I can imagine any board other
than the EVM uses other codec chips (either I2C or not).
So basically the whole codec stuff would preferable be
split out of the core VPIF driver.
Regards,
Stijn
+/**
+ * vpif_probe : This function probes the vpif capture driver
+ * @pdev: platform device pointer
+ *
+ * This creates device entries by register itself to the V4L2 driver and
+ * initializes fields of each channel objects
+ */
+static __init int vpif_probe(struct platform_device *pdev)
+{
+ struct vpif_subdev_info *subdevdata;
+ struct vpif_capture_config *config;
+ int i, j, k, m, q, err;
+ struct i2c_adapter *i2c_adap;
+ struct channel_obj *ch;
+ struct common_obj *common;
+ struct video_device *vfd;
+ struct resource *res;
+ int subdev_count;
+
+ vpif_dev = pdev-dev;
+
+ err = initialize_vpif();
+ if (err) {
+ v4l2_err(vpif_dev-driver, Error initializing vpif\n);
+ return err;
+ }
+
+ k = 0;
+ while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, k))) {
+ for (i = res-start; i = res-end; i++) {
+ if (request_irq(i, vpif_channel_isr, IRQF_DISABLED,
+ DM646x_Capture,
+ (void *)(vpif_obj.dev[k]-channel_id))) {
+ err = -EBUSY;
+ i--;
+ goto vpif_int_err;
+ }
+ }
+ k++;
+ }
+
+ for (i = 0; i VPIF_CAPTURE_MAX_DEVICES; i++) {
+ /* Get the pointer to the channel object */
+ ch = vpif_obj.dev[i];
+ /* Allocate memory for video device */
+ vfd = video_device_alloc();
+
RE: [PATCH v1 - 4/5] V4L : vpif updates for DM6467 vpif capture driver
Yes. I will send another patch later to fix the static variables.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com
-Original Message-
From: Hiremath, Vaibhav
Sent: Monday, August 17, 2009 12:35 PM
To: Karicheri, Muralidharan; linux-me...@vger.kernel.org
Cc: davinci-linux-open-source@linux.davincidsp.com; hverk...@xs4all.nl
Subject: RE: [PATCH v1 - 4/5] V4L : vpif updates for DM6467 vpif capture
driver
H Murali,
-Original Message-
From: Karicheri, Muralidharan
Sent: Monday, August 17, 2009 9:38 PM
To: Hiremath, Vaibhav; linux-me...@vger.kernel.org
Cc: davinci-linux-open-source@linux.davincidsp.com;
hverk...@xs4all.nl
Subject: RE: [PATCH v1 - 4/5] V4L : vpif updates for DM6467 vpif
capture driver
Vaibhav,
I don't see any serious issues raised here. I can send another patch
to fix this if needed.
[Hiremath, Vaibhav] yes most of them are editorial, as I mentioned I just
reviewed it quickly.
But as far as static variables are concerned I still think we can avoid
them completely, again it's not critical though.
As I mentioned I will have to look for extern variables, how they have been
used and stuff like that.
As of now, I am ok if it gets merged.
Regards,
Murali
+#include linux/spinlock.h
#include linux/kernel.h
+#include linux/io.h
[Hiremath, Vaibhav] You may want to put one line gap here.
Ok. Just editorial.
+#include mach/hardware.h
#include vpif.h
@@ -31,6 +35,12 @@ MODULE_LICENSE(GPL);
#define VPIF_CH2_MAX_MODES (15)
#define VPIF_CH3_MAX_MODES (02)
+static resource_size_t res_len;
+static struct resource *res;
[Hiremath, Vaibhav] Do we really require this to be static
variable?
I think we can manage it to be local variable.
Yes. We could. Probably change it with a new patch. Don't want to
hold up merge because of this.
+spinlock_t vpif_lock;
+
+void __iomem *vpif_base;
+
static inline void vpif_wr_bit(u32 reg, u32 bit, u32 val)
{
if (val)
@@ -151,17 +161,17 @@ static void config_vpif_params(struct
vpif_params *vpifparams,
else if (config-capture_format) {
/* Set the polarity of various pins */
vpif_wr_bit(reg, VPIF_CH_FID_POLARITY_BIT,
- vpifparams-
params.raw_params.fid_pol);
+ vpifparams-iface.fid_pol);
vpif_wr_bit(reg, VPIF_CH_V_VALID_POLARITY_BIT,
- vpifparams-params.raw_params.vd_pol);
+ vpifparams-iface.vd_pol);
vpif_wr_bit(reg, VPIF_CH_H_VALID_POLARITY_BIT,
- vpifparams-params.raw_params.hd_pol);
+ vpifparams-iface.hd_pol);
value = regr(reg);
/* Set data width */
value = ((~(unsigned int)(0x3))
VPIF_CH_DATA_WIDTH_BIT);
- value |= ((vpifparams-params.raw_params.data_sz)
+ value |= ((vpifparams-params.data_sz)
VPIF_CH_DATA_WIDTH_BIT);
regw(value, reg);
}
@@ -227,8 +237,60 @@ int vpif_channel_getfid(u8 channel_id)
}
EXPORT_SYMBOL(vpif_channel_getfid);
-void vpif_base_addr_init(void __iomem *base)
+static int __init vpif_probe(struct platform_device *pdev)
+{
+ int status = 0;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENOENT;
+
+ res_len = res-end - res-start + 1;
+
+ res = request_mem_region(res-start, res_len, res-name);
+ if (!res)
+ return -EBUSY;
+
+ vpif_base = ioremap(res-start, res_len);
+ if (!vpif_base) {
+ status = -EBUSY;
+ goto fail;
+ }
+
+ spin_lock_init(vpif_lock);
+ dev_info(pdev-dev, vpif probe success\n);
+ return 0;
+
+fail:
+ release_mem_region(res-start, res_len);
+ return status;
+}
+
+static int vpif_remove(struct platform_device *pdev)
{
- vpif_base = base;
+ iounmap(vpif_base);
+ release_mem_region(res-start, res_len);
+ return 0;
}
-EXPORT_SYMBOL(vpif_base_addr_init);
+
+static struct platform_driver vpif_driver = {
+ .driver = {
+ .name = vpif,
+ .owner = THIS_MODULE,
+ },
+ .remove = __devexit_p(vpif_remove),
+ .probe = vpif_probe,
+};
+
+static void vpif_exit(void)
+{
+ platform_driver_unregister(vpif_driver);
+}
+
+static int __init vpif_init(void)
+{
+ return platform_driver_register(vpif_driver);
+}
+subsys_initcall(vpif_init);
+module_exit(vpif_exit);
+
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h
index fca26dc..188841b 100644
---
Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
On Monday 17 August 2009 16:52:20 Karicheri, Muralidharan wrote: Hans, They are applied against davinci tree (also mentioned in the patch). General procedure what I follow is to create platform code against davinci tree and v4l patches against v4l-dvb linux-next tree. The architecture part of linux-next is not up to date. Davinci tree is at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git I must have missed the mention of this tree. I have a problem, though, as the current v4l-dvb repository doesn't compile against the linux-davinci git tree. And the only way I can get it to compile is to apply all five patches first. However, the whole tree should still compile after each patch is applied. And that goes wrong with your second patch where the Kconfig and Makefile are modified when the new sources aren't even added yet! What I would like to see is a patch series that starts with one patch that makes the current v4l-dvb tree compile again, then the arch patch is added, then a series of v4l-dvb patches in such an order that everything compiles after each step. Merging this is already complicated enough without breaking compilation in this way. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
connect I2S compatible audio codec to Dm355
Hi All, I am working on DM355 EVM board and trying to connect one I2S compatible audio codec to DC3. I am wondering if somebody have done this before and can give me some clues. is there any example code available? thanks, Wayne___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] DM365 VPSS support
From: Neil Sikka neilsi...@ti.com
This patch adds support for DM365 VPSS
Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com
Mandatory-Reviewer: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Neil Sikka neilsi...@ti.com
---
Applies to v4l-dvb linux-next repository
drivers/media/video/davinci/vpss.c | 232
include/media/davinci/vpss.h | 59 +-
2 files changed, 268 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/davinci/vpss.c
b/drivers/media/video/davinci/vpss.c
index 6d709ca..83dac1b 100644
--- a/drivers/media/video/davinci/vpss.c
+++ b/drivers/media/video/davinci/vpss.c
@@ -42,9 +42,12 @@ MODULE_AUTHOR(Texas Instruments);
/* masks and shifts */
#define VPSS_HSSISEL_SHIFT 4
-/*
+/* lock to write into common register */
+static spinlock_t vpss_lock;
+
+/**
* vpss operations. Depends on platform. Not all functions are available
- * on all platforms. The api, first check if a functio is available before
+ * on all platforms. The api, first check if a function is available before
* invoking it. In the probe, the function ptrs are intialized based on
* vpss name. vpss name can be dm355_vpss, dm644x_vpss etc.
*/
@@ -53,14 +56,19 @@ struct vpss_hw_ops {
int (*enable_clock)(enum vpss_clock_sel clock_sel, int en);
/* select input to ccdc */
void (*select_ccdc_source)(enum vpss_ccdc_source_sel src_sel);
- /* clear wbl overlflow bit */
+ /* clear wbl overflow bit */
int (*clear_wbl_overflow)(enum vpss_wbl_sel wbl_sel);
+ /*set sync polarity */
+ void (*set_sync_pol)(struct vpss_sync_pol);
+ /*set the PG_FRAME_SIZE register*/
+ void (*set_pg_frame_size)(struct vpss_pg_frame_size);
};
/* vpss configuration */
struct vpss_oper_config {
- __iomem void *vpss_bl_regs_base;
- __iomem void *vpss_regs_base;
+ __iomem void *vpss_regs_base0;
+ __iomem void *vpss_regs_base1;
+ resource_size_t *vpss_regs_base2;
struct resource *r1;
resource_size_t len1;
struct resource *r2;
@@ -75,22 +83,32 @@ static struct vpss_oper_config oper_cfg;
/* register access routines */
static inline u32 bl_regr(u32 offset)
{
- return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
+ return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
}
static inline void bl_regw(u32 val, u32 offset)
{
- __raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
+ __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
+}
+
+static inline u32 isp5_read(u32 offset)
+{
+ return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
+}
+
+static inline void isp5_write(u32 val, u32 offset)
+{
+ __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
}
static inline u32 vpss_regr(u32 offset)
{
- return __raw_readl(oper_cfg.vpss_regs_base + offset);
+ return __raw_readl(oper_cfg.vpss_regs_base1 + offset);
}
static inline void vpss_regw(u32 val, u32 offset)
{
- __raw_writel(val, oper_cfg.vpss_regs_base + offset);
+ __raw_writel(val, oper_cfg.vpss_regs_base1 + offset);
}
static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
@@ -98,12 +116,25 @@ static void dm355_select_ccdc_source(enum
vpss_ccdc_source_sel src_sel)
bl_regw(src_sel VPSS_HSSISEL_SHIFT, DM355_VPSSBL_CCDCMUX);
}
+static void dm365_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+ u32 temp = isp5_read(DM365_ISP5_CCDCMUX) ~CCD_SRC_SEL_MASK;
+
+ /* if we are using pattern generator, enable it */
+ if (src_sel == VPSS_PGLPBK || src_sel == VPSS_CCDCPG)
+ temp |= 0x08;
+
+ temp |= (src_sel CCD_SRC_SEL_SHIFT);
+ isp5_write(temp, DM365_ISP5_CCDCMUX);
+}
+
int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
{
if (!oper_cfg.hw_ops.select_ccdc_source)
return -1;
- dm355_select_ccdc_source(src_sel);
+ oper_cfg.hw_ops.select_ccdc_source(src_sel);
+
return 0;
}
EXPORT_SYMBOL(vpss_select_ccdc_source);
@@ -120,9 +151,56 @@ static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel
wbl_sel)
mask = ~(mask wbl_sel);
val = bl_regr(DM644X_SBL_PCR_VPSS) mask;
bl_regw(val, DM644X_SBL_PCR_VPSS);
+
return 0;
}
+static void dm365_enable_irq(void)
+{
+ u32 current_val = isp5_read(DM365_VPSS_INTSEL1);
+ /*just enable INTSEL0 and INTSEL1 and leave everything else as is*/
+ current_val = ~(CCD_INT_SEL_MASK);
+ current_val |= BIT_MASK(8);
+ isp5_write(current_val, DM365_VPSS_INTSEL1);
+}
+
+void dm365_set_sync_pol(struct vpss_sync_pol sync)
+{
+ int val = 0;
+ val = isp5_read(DM365_ISP5_CCDCMUX);
+
+ val |= (sync.ccdpg_hdpol DM365_CCDC_PG_HD_POL_SHIFT);
+ val |= (sync.ccdpg_vdpol DM365_CCDC_PG_VD_POL_SHIFT);
+
+ isp5_write(val, DM365_ISP5_CCDCMUX);
+}
+
+void vpss_set_sync_pol(struct
[PATCH] DM365 Platform support for VPFE
From: Neil Sikka neilsi...@ti.com
This has platform and board setup changes to support the vpfe capture
driver for DM365 EVMs.
Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com
Mandatory-Reviewer: Hans Verkuil hverk...@xs4all.nl
Mandatory-Reviewer: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Neil Sikka neilsi...@ti.com
---
Applies to Kevin Hilman's linux-davinci repository
arch/arm/mach-davinci/board-dm365-evm.c| 71
arch/arm/mach-davinci/dm365.c | 68 ++
arch/arm/mach-davinci/include/mach/dm365.h |2 +
3 files changed, 141 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index f6adf79..757ad13 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -38,6 +38,8 @@
#include mach/common.h
#include mach/mmc.h
#include mach/nand.h
+#include linux/videodev2.h
+#include media/tvp514x.h
static inline int have_imager(void)
@@ -98,6 +100,11 @@ static inline int have_tvp7002(void)
static void __iomem *cpld;
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity = 1,
+ .vs_polarity = 1
+};
/* NOTE: this is geared for the standard config, with a socketed
* 2 GByte Micron NAND (MT29F16G08FAA) using 128KB sectors. If you
@@ -210,6 +217,68 @@ static int cpld_mmc_get_ro(int module)
return !!(__raw_readb(cpld + CPLD_CARDSTAT) BIT(module ? 5 : 1));
}
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std = TVP514X_STD_ALL,
+ },
+};
+
+/*
+ * this is the route info for connecting each input to decoder
+ * ouput that goes to vpfe. There is a one to one correspondence
+ * with tvp5146_inputs
+ */
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI2B,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+{
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+{
+ .module_name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO(tvp5146, 0x5d),
+ .platform_data = tvp5146_pdata,
+ },
+ }
+};
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs = ARRAY_SIZE(vpfe_sub_devs),
+ .sub_devs = vpfe_sub_devs,
+ .card_name = DM365 EVM,
+ .ccdc = DM365 ISIF,
+ .num_clocks = 1,
+ .clocks = {vpss_master},
+};
+
static struct davinci_mmc_config dm365evm_mmc_config = {
.get_cd = cpld_mmc_get_cd,
.get_ro = cpld_mmc_get_ro,
@@ -461,6 +530,8 @@ static struct davinci_uart_config uart_config __initdata = {
static void __init dm365_evm_map_io(void)
{
+ /* setup input configuration for VPFE input devices */
+ dm365_set_vpfe_config(vpfe_cfg);
dm365_init();
}
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index f8bac94..aa432d4 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -904,6 +904,62 @@ void __init dm365_init(void)
davinci_common_init(davinci_soc_info_dm365);
}
+static struct resource dm365_vpss_resources[] = {
+ {
+ /* VPSS ISP5 Base address */
+ .name = vpss,
+ .start = 0x01c7,
+ .end= 0x01c7 + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ /* VPSS CLK Base address */
+ .name = vpss,
+ .start = 0x01c70200,
+ .end= 0x01c70200 + 0xff,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device dm365_vpss_device = {
+ .name = vpss,
+ .id = -1,
+ .dev.platform_data = dm365_vpss,
+ .num_resources = ARRAY_SIZE(dm365_vpss_resources),
+ .resource =
[PATCH] Build system support for DM365 CCDC
From: Neil Sikka neilsi...@ti.com This patch sets up the build system for DM365 VPFE support Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com Mandatory-Reviewer: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Neil Sikka neilsi...@ti.com --- Applies to v4l-dvb linux-next repository drivers/media/video/Kconfig |9 + drivers/media/video/davinci/Makefile |3 ++- 2 files changed, 11 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 1fa3c87..e0dd402 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -578,6 +578,15 @@ config VIDEO_DM355_CCDC To compile this driver as a module, choose M here: the module will be called vpfe. +config VIDEO_DM365_ISIF + tristate DM365 CCDC/ISIF HW module + depends on ARCH_DAVINCI_DM365 VIDEO_VPFE_CAPTURE + default y + help + Enables DM365 ISIF hw module. This is the hardware module for + configuring ISIF in VPFE to capture Raw Bayer RGB data from + a image sensor or YUV data from a YUV source. + source drivers/media/video/bt8xx/Kconfig config VIDEO_PMS diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index f44cad2..5f4c830 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -8,8 +8,9 @@ obj-$(CONFIG_VIDEO_DAVINCI_VPIF) += vpif.o #DM646x EVM Display driver obj-$(CONFIG_DISPLAY_DAVINCI_DM646X_EVM) += vpif_display.o -# Capture: DM6446 and DM355 +# Capture: DM6446, DM355, DM365 obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o +obj-$(CONFIG_VIDEO_DM365_ISIF) += dm365_ccdc.o -- 1.6.0.4 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v1 0/4] Adding capture support for DM365 device
From: Neil Sikka neilsi...@ti.com This patch series adds support for the VPSS capture on the DM365 SOC. Specifically, it supports the CCDC/ISIF module. This code has been tested and works with the TVP5146 decoder (using the tvp514x driver). During testing of this code, the NTSC capture format was used. This patch depends on previous other patches contributed by Muralidharan Karicheri. Please see the individual patch notes for dependency details. The patches contained in this patch set are: 1) DM365 Platform support for VPFE-additions to the DM365 SOC files 2) DM365 VPSS support-additions to the VPSS.h and VPSS.c files 3) CCDC support on DM365-the actual DM365 CCDC driver and its supporting files NOTE: All patches are to be applied before build. Mandatory reviewers: Hans Verkuil hverk...@xs4all.nl for V4L tree Kevin Hilman khil...@deeprootsystems.com for DaVinci tree Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com Signed-off-by: Neil Sikka neilsi...@ti.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
Hans, Ok. I will rework the patch and send you the same. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Monday, August 17, 2009 2:47 PM To: Karicheri, Muralidharan Cc: linux-me...@vger.kernel.org; davinci-linux-open- sou...@linux.davincidsp.com; khil...@deeprootsystems.com Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver On Monday 17 August 2009 16:52:20 Karicheri, Muralidharan wrote: Hans, They are applied against davinci tree (also mentioned in the patch). General procedure what I follow is to create platform code against davinci tree and v4l patches against v4l-dvb linux-next tree. The architecture part of linux-next is not up to date. Davinci tree is at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git I must have missed the mention of this tree. I have a problem, though, as the current v4l-dvb repository doesn't compile against the linux-davinci git tree. And the only way I can get it to compile is to apply all five patches first. However, the whole tree should still compile after each patch is applied. And that goes wrong with your second patch where the Kconfig and Makefile are modified when the new sources aren't even added yet! What I would like to see is a patch series that starts with one patch that makes the current v4l-dvb tree compile again, then the arch patch is added, then a series of v4l-dvb patches in such an order that everything compiles after each step. Merging this is already complicated enough without breaking compilation in this way. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
problem booting the kernel
I have done some changes in kernel and is not proceeding beyond this during boot: Uncompressing linux...done, booting the kernel. Any ideas how to fix this. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v1 0/4] Adding capture support for DM365 device
Please disregard the previous patch. I am sending one with corrected Subject fields. -Original Message- From: Sikka, Neil Sent: Monday, August 17, 2009 3:35 PM To: linux-me...@vger.kernel.org; davinci-linux-open-source@linux.davincidsp.com Cc: khil...@deeprootsystems.com; hverk...@xs4all.nl; Sikka, Neil Subject: [PATCH v1 0/4] Adding capture support for DM365 device From: Neil Sikka neilsi...@ti.com This patch series adds support for the VPSS capture on the DM365 SOC. Specifically, it supports the CCDC/ISIF module. This code has been tested and works with the TVP5146 decoder (using the tvp514x driver). During testing of this code, the NTSC capture format was used. This patch depends on previous other patches contributed by Muralidharan Karicheri. Please see the individual patch notes for dependency details. The patches contained in this patch set are: 1) DM365 Platform support for VPFE-additions to the DM365 SOC files 2) DM365 VPSS support-additions to the VPSS.h and VPSS.c files 3) CCDC support on DM365-the actual DM365 CCDC driver and its supporting files NOTE: All patches are to be applied before build. Mandatory reviewers: Hans Verkuil hverk...@xs4all.nl for V4L tree Kevin Hilman khil...@deeprootsystems.com for DaVinci tree Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com Signed-off-by: Neil Sikka neilsi...@ti.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v1 0/4] Adding capture support for DM365 device
From: Neil Sikka neilsi...@ti.com This patch series adds support for the VPSS capture on the DM365 SOC. Specifically, it supports the CCDC/ISIF module. This code has been tested and works with the TVP5146 decoder (using the tvp514x driver). During testing of this code, the NTSC capture format was used. This patch depends on previous other patches contributed by Muralidharan Karicheri. Please see the individual patch notes for dependency details. The patches contained in this patch set are: 1) DM365 Platform support for VPFE-additions to the DM365 SOC files 2) DM365 VPSS support-additions to the VPSS.h and VPSS.c files 3) CCDC support on DM365-the actual DM365 CCDC driver and its supporting files NOTE: All patches are to be applied before build. Mandatory reviewers: Hans Verkuil hverk...@xs4all.nl for V4L tree Kevin Hilman khil...@deeprootsystems.com for DaVinci tree Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com Signed-off-by: Neil Sikka neilsi...@ti.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v1 2/4] DM365 VPSS support
From: Neil Sikka neilsi...@ti.com
This patch adds support for DM365 VPSS
Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com
Mandatory-Reviewer: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Neil Sikka neilsi...@ti.com
---
Applies to v4l-dvb linux-next repository
drivers/media/video/davinci/vpss.c | 232
include/media/davinci/vpss.h | 59 +-
2 files changed, 268 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/davinci/vpss.c
b/drivers/media/video/davinci/vpss.c
index 6d709ca..83dac1b 100644
--- a/drivers/media/video/davinci/vpss.c
+++ b/drivers/media/video/davinci/vpss.c
@@ -42,9 +42,12 @@ MODULE_AUTHOR(Texas Instruments);
/* masks and shifts */
#define VPSS_HSSISEL_SHIFT 4
-/*
+/* lock to write into common register */
+static spinlock_t vpss_lock;
+
+/**
* vpss operations. Depends on platform. Not all functions are available
- * on all platforms. The api, first check if a functio is available before
+ * on all platforms. The api, first check if a function is available before
* invoking it. In the probe, the function ptrs are intialized based on
* vpss name. vpss name can be dm355_vpss, dm644x_vpss etc.
*/
@@ -53,14 +56,19 @@ struct vpss_hw_ops {
int (*enable_clock)(enum vpss_clock_sel clock_sel, int en);
/* select input to ccdc */
void (*select_ccdc_source)(enum vpss_ccdc_source_sel src_sel);
- /* clear wbl overlflow bit */
+ /* clear wbl overflow bit */
int (*clear_wbl_overflow)(enum vpss_wbl_sel wbl_sel);
+ /*set sync polarity */
+ void (*set_sync_pol)(struct vpss_sync_pol);
+ /*set the PG_FRAME_SIZE register*/
+ void (*set_pg_frame_size)(struct vpss_pg_frame_size);
};
/* vpss configuration */
struct vpss_oper_config {
- __iomem void *vpss_bl_regs_base;
- __iomem void *vpss_regs_base;
+ __iomem void *vpss_regs_base0;
+ __iomem void *vpss_regs_base1;
+ resource_size_t *vpss_regs_base2;
struct resource *r1;
resource_size_t len1;
struct resource *r2;
@@ -75,22 +83,32 @@ static struct vpss_oper_config oper_cfg;
/* register access routines */
static inline u32 bl_regr(u32 offset)
{
- return __raw_readl(oper_cfg.vpss_bl_regs_base + offset);
+ return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
}
static inline void bl_regw(u32 val, u32 offset)
{
- __raw_writel(val, oper_cfg.vpss_bl_regs_base + offset);
+ __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
+}
+
+static inline u32 isp5_read(u32 offset)
+{
+ return __raw_readl(oper_cfg.vpss_regs_base0 + offset);
+}
+
+static inline void isp5_write(u32 val, u32 offset)
+{
+ __raw_writel(val, oper_cfg.vpss_regs_base0 + offset);
}
static inline u32 vpss_regr(u32 offset)
{
- return __raw_readl(oper_cfg.vpss_regs_base + offset);
+ return __raw_readl(oper_cfg.vpss_regs_base1 + offset);
}
static inline void vpss_regw(u32 val, u32 offset)
{
- __raw_writel(val, oper_cfg.vpss_regs_base + offset);
+ __raw_writel(val, oper_cfg.vpss_regs_base1 + offset);
}
static void dm355_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
@@ -98,12 +116,25 @@ static void dm355_select_ccdc_source(enum
vpss_ccdc_source_sel src_sel)
bl_regw(src_sel VPSS_HSSISEL_SHIFT, DM355_VPSSBL_CCDCMUX);
}
+static void dm365_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
+{
+ u32 temp = isp5_read(DM365_ISP5_CCDCMUX) ~CCD_SRC_SEL_MASK;
+
+ /* if we are using pattern generator, enable it */
+ if (src_sel == VPSS_PGLPBK || src_sel == VPSS_CCDCPG)
+ temp |= 0x08;
+
+ temp |= (src_sel CCD_SRC_SEL_SHIFT);
+ isp5_write(temp, DM365_ISP5_CCDCMUX);
+}
+
int vpss_select_ccdc_source(enum vpss_ccdc_source_sel src_sel)
{
if (!oper_cfg.hw_ops.select_ccdc_source)
return -1;
- dm355_select_ccdc_source(src_sel);
+ oper_cfg.hw_ops.select_ccdc_source(src_sel);
+
return 0;
}
EXPORT_SYMBOL(vpss_select_ccdc_source);
@@ -120,9 +151,56 @@ static int dm644x_clear_wbl_overflow(enum vpss_wbl_sel
wbl_sel)
mask = ~(mask wbl_sel);
val = bl_regr(DM644X_SBL_PCR_VPSS) mask;
bl_regw(val, DM644X_SBL_PCR_VPSS);
+
return 0;
}
+static void dm365_enable_irq(void)
+{
+ u32 current_val = isp5_read(DM365_VPSS_INTSEL1);
+ /*just enable INTSEL0 and INTSEL1 and leave everything else as is*/
+ current_val = ~(CCD_INT_SEL_MASK);
+ current_val |= BIT_MASK(8);
+ isp5_write(current_val, DM365_VPSS_INTSEL1);
+}
+
+void dm365_set_sync_pol(struct vpss_sync_pol sync)
+{
+ int val = 0;
+ val = isp5_read(DM365_ISP5_CCDCMUX);
+
+ val |= (sync.ccdpg_hdpol DM365_CCDC_PG_HD_POL_SHIFT);
+ val |= (sync.ccdpg_vdpol DM365_CCDC_PG_VD_POL_SHIFT);
+
+ isp5_write(val, DM365_ISP5_CCDCMUX);
+}
+
+void vpss_set_sync_pol(struct
[PATCH v1 4/4] Build system support for DM365 CCDC
From: Neil Sikka neilsi...@ti.com This patch sets up the build system for DM365 VPFE support Reviewed-by: Muralidharan Karicheri m-kariche...@ti.com Mandatory-Reviewer: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Neil Sikka neilsi...@ti.com --- Applies to v4l-dvb linux-next repository drivers/media/video/Kconfig |9 + drivers/media/video/davinci/Makefile |3 ++- 2 files changed, 11 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 1fa3c87..e0dd402 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -578,6 +578,15 @@ config VIDEO_DM355_CCDC To compile this driver as a module, choose M here: the module will be called vpfe. +config VIDEO_DM365_ISIF + tristate DM365 CCDC/ISIF HW module + depends on ARCH_DAVINCI_DM365 VIDEO_VPFE_CAPTURE + default y + help + Enables DM365 ISIF hw module. This is the hardware module for + configuring ISIF in VPFE to capture Raw Bayer RGB data from + a image sensor or YUV data from a YUV source. + source drivers/media/video/bt8xx/Kconfig config VIDEO_PMS diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index f44cad2..5f4c830 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -8,8 +8,9 @@ obj-$(CONFIG_VIDEO_DAVINCI_VPIF) += vpif.o #DM646x EVM Display driver obj-$(CONFIG_DISPLAY_DAVINCI_DM646X_EVM) += vpif_display.o -# Capture: DM6446 and DM355 +# Capture: DM6446, DM355, DM365 obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o obj-$(CONFIG_VIDEO_VPFE_CAPTURE) += vpfe_capture.o obj-$(CONFIG_VIDEO_DM6446_CCDC) += dm644x_ccdc.o obj-$(CONFIG_VIDEO_DM355_CCDC) += dm355_ccdc.o +obj-$(CONFIG_VIDEO_DM365_ISIF) += dm365_ccdc.o -- 1.6.0.4 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
Hans, Would you like the architecture specific changes against v4l-dvb linux-next tree or linux-davinci ? I will rework both the vpfe and vpif patches as per your comment. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Monday, August 17, 2009 2:47 PM To: Karicheri, Muralidharan Cc: linux-me...@vger.kernel.org; davinci-linux-open- sou...@linux.davincidsp.com; khil...@deeprootsystems.com Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver On Monday 17 August 2009 16:52:20 Karicheri, Muralidharan wrote: Hans, They are applied against davinci tree (also mentioned in the patch). General procedure what I follow is to create platform code against davinci tree and v4l patches against v4l-dvb linux-next tree. The architecture part of linux-next is not up to date. Davinci tree is at git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git I must have missed the mention of this tree. I have a problem, though, as the current v4l-dvb repository doesn't compile against the linux-davinci git tree. And the only way I can get it to compile is to apply all five patches first. However, the whole tree should still compile after each patch is applied. And that goes wrong with your second patch where the Kconfig and Makefile are modified when the new sources aren't even added yet! What I would like to see is a patch series that starts with one patch that makes the current v4l-dvb tree compile again, then the arch patch is added, then a series of v4l-dvb patches in such an order that everything compiles after each step. Merging this is already complicated enough without breaking compilation in this way. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: problem booting the kernel
On Mon, 2009-08-17 at 12:48 -0700, Vijay Soni wrote: I have done some changes in kernel and is not proceeding beyond this during boot: Uncompressing linux...done, booting the kernel. Any ideas how to fix this. Nope, but you can try turning DEBUG_LL to see if you can get additional information. You may need the printascii patch to see something.. depend on the kernel you have. Regards, Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
On Monday 17 August 2009 22:10:04 Karicheri, Muralidharan wrote: Hans, Would you like the architecture specific changes against v4l-dvb linux-next tree or linux-davinci ? I will rework both the vpfe and vpif patches as per your comment. v4l-dvb linux-next. The current v4l-dvb at least compiles against that one, so that is the most appropriate tree to do the patches against. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: problem booting the kernel
Vijay Soni wrote: I have done some changes in kernel and is not proceeding beyond this during boot: Uncompressing linux...done, booting the kernel. Any ideas how to fix this. You could check if you have the right console settings in the uboot bootargs (eg: console=ttyS0,115200n8). You might be actually booting but not showing on the serial console if the console setting is mistyped or not present. If the size of your kernel exceeds the allowable kernel size (I think its 4MB arch/arm/kernel/head.S), you might have to increase it. regards, -sid ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 1/5 - v3] Adding new fields to add the vpfe capture enhancements
From: Muralidharan Karicheri m-kariche...@ti.com
Restructured the patch to apply cleanly. This will allow compilation after
applying each patch. To do this existing fields in the header files are
retained and removed later when the new fields are used.
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next repository
include/media/davinci/vpfe_capture.h | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/include/media/davinci/vpfe_capture.h
b/include/media/davinci/vpfe_capture.h
index 71d8982..196245e 100644
--- a/include/media/davinci/vpfe_capture.h
+++ b/include/media/davinci/vpfe_capture.h
@@ -47,6 +47,8 @@ struct vpfe_pixel_format {
struct v4l2_fmtdesc fmtdesc;
/* bytes per pixel */
int bpp;
+ /* decoder format */
+ u32 subdev_pix_fmt;
};
struct vpfe_std_info {
@@ -61,9 +63,16 @@ struct vpfe_route {
u32 output;
};
+enum vpfe_subdev_id {
+ VPFE_SUBDEV_TVP5146 = 1,
+ VPFE_SUBDEV_MT9T031 = 2
+};
+
struct vpfe_subdev_info {
- /* Sub device name */
+ /* Deprecated. Will be removed in the next patch */
char name[32];
+ /* Sub device module name */
+ char module_name[32];
/* Sub device group id */
int grp_id;
/* Number of inputs supported */
@@ -72,12 +81,16 @@ struct vpfe_subdev_info {
struct v4l2_input *inputs;
/* Sub dev routing information for each input */
struct vpfe_route *routes;
- /* check if sub dev supports routing */
- int can_route;
/* ccdc bus/interface configuration */
struct vpfe_hw_if_param ccdc_if_params;
/* i2c subdevice board info */
struct i2c_board_info board_info;
+ /* Is this a camera sub device ? */
+ unsigned is_camera:1;
+ /* check if sub dev supports routing */
+ unsigned can_route:1;
+ /* registered ? */
+ unsigned registered:1;
};
struct vpfe_config {
@@ -92,6 +105,12 @@ struct vpfe_config {
/* vpfe clock */
struct clk *vpssclk;
struct clk *slaveclk;
+ /* setup function for the input path */
+ int (*setup_input)(enum vpfe_subdev_id id);
+ /* number of clocks */
+ int num_clocks;
+ /* clocks used for vpfe capture */
+ char *clocks[];
};
struct vpfe_device {
@@ -102,6 +121,8 @@ struct vpfe_device {
struct v4l2_subdev **sd;
/* vpfe cfg */
struct vpfe_config *cfg;
+ /* clock ptrs for vpfe capture */
+ struct clk **clks;
/* V4l2 device */
struct v4l2_device v4l2_dev;
/* parent device */
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 5/5 - v3] V4L: ccdc driver - adding support for camera capture
From: Muralidharan Karicheri m-kariche...@ti.com
Recreating this to apply cleanly and compile
There was no comment against v1 of the patch. So no change in this file
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next repository
drivers/media/video/davinci/dm355_ccdc.c | 16 +++-
drivers/media/video/davinci/dm644x_ccdc.c | 13 +
include/media/davinci/dm355_ccdc.h|2 +-
include/media/davinci/dm644x_ccdc.h |2 +-
4 files changed, 22 insertions(+), 11 deletions(-)
diff --git a/drivers/media/video/davinci/dm355_ccdc.c
b/drivers/media/video/davinci/dm355_ccdc.c
index 4629cab..4efffc2 100644
--- a/drivers/media/video/davinci/dm355_ccdc.c
+++ b/drivers/media/video/davinci/dm355_ccdc.c
@@ -92,7 +92,7 @@ static struct ccdc_params_raw ccdc_hw_params_raw = {
/* Object for CCDC ycbcr mode */
static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
- .win = CCDC_WIN_PAL,
+ .win = CCDC_WIN_NTSC,
.pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
.frm_fmt = CCDC_FRMFMT_INTERLACED,
.fid_pol = VPFE_PINPOL_POSITIVE,
@@ -548,7 +548,7 @@ static int ccdc_config_vdfc(struct ccdc_vertical_dft *dfc)
*/
static void ccdc_config_csc(struct ccdc_csc *csc)
{
- u32 val1, val2;
+ u32 val1 = 0, val2;
int i;
if (!csc-enable)
@@ -925,8 +925,11 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param
*params)
ccdc_hw_params_ycbcr.vd_pol = params-vdpol;
ccdc_hw_params_ycbcr.hd_pol = params-hdpol;
break;
+ case VPFE_RAW_BAYER:
+ ccdc_hw_params_raw.vd_pol = params-vdpol;
+ ccdc_hw_params_raw.hd_pol = params-hdpol;
+ break;
default:
- /* TODO add support for raw bayer here */
return -EINVAL;
}
return 0;
@@ -961,9 +964,12 @@ static struct ccdc_hw_device ccdc_hw_dev = {
static int dm355_ccdc_init(void)
{
+ int ret;
+
printk(KERN_NOTICE dm355_ccdc_init\n);
- if (vpfe_register_ccdc_device(ccdc_hw_dev) 0)
- return -1;
+ ret = vpfe_register_ccdc_device(ccdc_hw_dev);
+ if (ret 0)
+ return ret;
printk(KERN_NOTICE %s is registered with vpfe.\n,
ccdc_hw_dev.name);
return 0;
diff --git a/drivers/media/video/davinci/dm644x_ccdc.c
b/drivers/media/video/davinci/dm644x_ccdc.c
index 2f19a91..5dff8d9 100644
--- a/drivers/media/video/davinci/dm644x_ccdc.c
+++ b/drivers/media/video/davinci/dm644x_ccdc.c
@@ -65,7 +65,7 @@ static struct ccdc_params_raw ccdc_hw_params_raw = {
static struct ccdc_params_ycbcr ccdc_hw_params_ycbcr = {
.pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
.frm_fmt = CCDC_FRMFMT_INTERLACED,
- .win = CCDC_WIN_PAL,
+ .win = CCDC_WIN_NTSC,
.fid_pol = VPFE_PINPOL_POSITIVE,
.vd_pol = VPFE_PINPOL_POSITIVE,
.hd_pol = VPFE_PINPOL_POSITIVE,
@@ -825,8 +825,10 @@ static int ccdc_set_hw_if_params(struct vpfe_hw_if_param
*params)
ccdc_hw_params_ycbcr.vd_pol = params-vdpol;
ccdc_hw_params_ycbcr.hd_pol = params-hdpol;
break;
+ case VPFE_RAW_BAYER:
+ ccdc_hw_params_raw.vd_pol = params-vdpol;
+ ccdc_hw_params_raw.hd_pol = params-hdpol;
default:
- /* TODO add support for raw bayer here */
return -EINVAL;
}
return 0;
@@ -861,9 +863,12 @@ static struct ccdc_hw_device ccdc_hw_dev = {
static int dm644x_ccdc_init(void)
{
+ int ret;
+
printk(KERN_NOTICE dm644x_ccdc_init\n);
- if (vpfe_register_ccdc_device(ccdc_hw_dev) 0)
- return -1;
+ ret = vpfe_register_ccdc_device(ccdc_hw_dev);
+ if (ret 0)
+ return ret;
printk(KERN_NOTICE %s is registered with vpfe.\n,
ccdc_hw_dev.name);
return 0;
diff --git a/include/media/davinci/dm355_ccdc.h
b/include/media/davinci/dm355_ccdc.h
index df8a7b1..9395900 100644
--- a/include/media/davinci/dm355_ccdc.h
+++ b/include/media/davinci/dm355_ccdc.h
@@ -254,7 +254,7 @@ struct ccdc_config_params_raw {
#ifdef __KERNEL__
#include linux/io.h
-#define CCDC_WIN_PAL {0, 0, 720, 576}
+#define CCDC_WIN_NTSC {0, 0, 720, 480}
#define CCDC_WIN_VGA {0, 0, 640, 480}
struct ccdc_params_ycbcr {
diff --git a/include/media/davinci/dm644x_ccdc.h
b/include/media/davinci/dm644x_ccdc.h
index 3e178eb..e34a54a 100644
--- a/include/media/davinci/dm644x_ccdc.h
+++ b/include/media/davinci/dm644x_ccdc.h
@@ -131,7 +131,7 @@ struct ccdc_config_params_raw {
#define NUM_EXTRALINES 8
/* settings for commonly used video formats */
-#define CCDC_WIN_PAL {0, 0, 720, 576}
+#define CCDC_WIN_NTSC {0, 0, 720, 480}
/* ntsc square pixel */
#define CCDC_WIN_VGA {0, 0, (640 + NUM_EXTRAPIXELS), (480 + NUM_EXTRALINES)}
--
[PATCH 2/5 - v3] V4L: ccdc driver - select MSP driver for CCDC input selection
From: Muralidharan Karicheri m-kariche...@ti.com Just being recreated to apply cleanly and compile. There were no comments against v1 of this patch. So no change from v1/v2 of the patch Reviewed-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- Applies to V4L-DVB linux-next repository drivers/media/video/Kconfig |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index e8a6e4d..1fa3c87 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -565,13 +565,15 @@ config VIDEO_DM355_CCDC tristate DM355 CCDC HW module depends on ARCH_DAVINCI_DM355 VIDEO_VPFE_CAPTURE select VIDEO_VPSS_SYSTEM + select MFD_DM355EVM_MSP default y help Enables DM355 CCD hw module. DM355 CCDC hw interfaces with decoder modules such as TVP5146 over BT656 or sensor module such as MT9T001 over a raw interface. This module configures the interface and CCDC/ISIF to do - video frame capture from a slave decoders + video frame capture from a slave decoders. MFD_DM355EVM_MSP + is enabled to select input to CCDC at run time. To compile this driver as a module, choose M here: the module will be called vpfe. -- 1.6.0.4 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 3/5 - v3] DaVinci: platform changes to support vpfe camera capture Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
From: Muralidharan Karicheri m-kariche...@ti.com
Recreating the patch to apply cleanly and compile.
There were no comments against v1 of this patch. So no change from v1/v2 of
this patch
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next repository
arch/arm/mach-davinci/board-dm355-evm.c | 140 +-
arch/arm/mach-davinci/board-dm644x-evm.c |6 +-
2 files changed, 140 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index 605bf03..8f2842a 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -24,6 +24,7 @@
#include media/tvp514x.h
#include linux/spi/spi.h
#include linux/spi/eeprom.h
+#include linux/i2c/dm355evm_msp.h
#include asm/setup.h
#include asm/mach-types.h
@@ -136,14 +137,58 @@ static void dm355evm_mmcsd_gpios(unsigned gpio)
dm355evm_mmc_gpios = gpio;
}
+#define PCA9543A_I2C_ADDR (0x73)
+
+static struct i2c_client *pca9543a;
+
+static int pca9543a_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ pca9543a = client;
+ return 0;
+}
+
+static int pca9543a_remove(struct i2c_client *client)
+{
+ pca9543a = NULL;
+ return 0;
+}
+
+static const struct i2c_device_id pca9543a_ids[] = {
+ { PCA9543A, 0, },
+ { /* end of list */ },
+};
+
+/* This is for i2c driver for the MT9T031 header i2c switch */
+static struct i2c_driver pca9543a_driver = {
+ .driver.name= PCA9543A,
+ .id_table = pca9543a_ids,
+ .probe = pca9543a_probe,
+ .remove = pca9543a_remove,
+};
+
static struct i2c_board_info dm355evm_i2c_info[] = {
{ I2C_BOARD_INFO(dm355evm_msp, 0x25),
.platform_data = dm355evm_mmcsd_gpios,
},
+ {
+ I2C_BOARD_INFO(PCA9543A, 0x73),
+ },
/* { plus irq }, */
/* { I2C_BOARD_INFO(tlv320aic3x, 0x1b), }, */
};
+/* have_sensor() - Check if we have support for sensor interface */
+static inline int have_sensor(void)
+{
+#if defined(CONFIG_SOC_CAMERA_MT9T031) || \
+defined(CONFIG_SOC_CAMERA_MT9T031_MODULE)
+ return 1;
+#else
+ return 0;
+#endif
+}
+
static void __init evm_init_i2c(void)
{
davinci_init_i2c(i2c_pdata);
@@ -151,7 +196,8 @@ static void __init evm_init_i2c(void)
gpio_request(5, dm355evm_msp);
gpio_direction_input(5);
dm355evm_i2c_info[0].irq = gpio_to_irq(5);
-
+ if (have_sensor())
+ i2c_add_driver(pca9543a_driver);
i2c_register_board_info(1, dm355evm_i2c_info,
ARRAY_SIZE(dm355evm_i2c_info));
}
@@ -180,6 +226,72 @@ static struct platform_device dm355evm_dm9000 = {
.num_resources = ARRAY_SIZE(dm355evm_dm9000_rsrc),
};
+/**
+ * dm355_enable_i2c_switch() - Enable/Disable I2C switch PCA9543A for sensor
+ * @en: enable/disbale flag
+ */
+static int dm355evm_enable_i2c_switch(int en)
+{
+ static char val = 1;
+ int status;
+ struct i2c_msg msg = {
+ .flags = 0,
+ .len = 1,
+ .buf = val,
+ };
+
+ if (!en)
+ val = 0;
+
+ if (!pca9543a)
+ return -ENXIO;
+
+ msg.addr = pca9543a-addr;
+ /* turn i2c switch, pca9543a, on/off */
+ status = i2c_transfer(pca9543a-adapter, msg, 1);
+ return status;
+}
+
+/**
+ * dm355evm_setup_video_input() - setup video data path and i2c
+ * @id: sub device id
+ */
+static int dm355evm_setup_video_input(enum vpfe_subdev_id id)
+{
+ int ret;
+
+ switch (id) {
+ case VPFE_SUBDEV_MT9T031:
+ {
+ ret = dm355evm_msp_write(MSP_VIDEO_IMAGER,
+DM355EVM_MSP_VIDEO_IN);
+ if (ret = 0)
+ ret = dm355evm_enable_i2c_switch(1);
+ else
+ /* switch off i2c switch since we failed */
+ ret = dm355evm_enable_i2c_switch(0);
+ break;
+ }
+ case VPFE_SUBDEV_TVP5146:
+ {
+ ret = dm355evm_msp_write(0, DM355EVM_MSP_VIDEO_IN);
+ break;
+ }
+ default:
+ return -EINVAL;
+ }
+ return (ret = 0 ? 0 : ret);
+}
+
+/* Input available at the mt9t031 */
+static struct v4l2_input mt9t031_inputs[] = {
+ {
+ .index = 0,
+ .name = Camera,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ }
+};
+
static struct tvp514x_platform_data tvp5146_pdata = {
.clk_polarity = 0,
.hs_polarity = 1,
@@ -203,7 +315,7 @@ static struct v4l2_input tvp5146_inputs[] = {
},
};
-/*
+/**
* this is the route info for connecting each input to decoder
* ouput that goes to vpfe. There
[PATCH 4/5 - v3] V4L-vpfe capture driver - adding support for camera capture
From: Muralidharan Karicheri m-kariche...@ti.com
Recreating this patch to apply cleanly and compile.
v2 of the patch incorporated following comments received against v1 patch
series.
1) retained vpfe_g_std() since for vbi support g_std handling in v4l2
framework
is not sufficient.
2) rename name field in vpfe_subdev_info to module_name and camera to
is_camera.
also grouped bit field variables
Additional features added on top v1 patch:-
2) vpfe_enable/disable_clock restructered to allow configuration of
required
clocks in vpfe_capture configuration. This is required for upcoming
DM365
support.
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next repository
drivers/media/video/davinci/vpfe_capture.c | 545 +---
include/media/davinci/vpfe_capture.h |5 -
2 files changed, 413 insertions(+), 137 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 402ce43..ff43446 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -59,10 +59,8 @@
*TODO list
* - Support multiple REQBUF after open
* - Support for de-allocating buffers through REQBUF
- * - Support for Raw Bayer RGB capture
* - Support for chaining Image Processor
* - Support for static allocation of buffers
- * - Support for USERPTR IO
* - Support for STREAMON before QBUF
* - Support for control ioctls
*/
@@ -79,11 +77,24 @@
static int debug;
static u32 numbuffers = 3;
static u32 bufsize = (720 * 576 * 2);
+static int interface;
+module_param(interface, bool, S_IRUGO);
module_param(numbuffers, uint, S_IRUGO);
module_param(bufsize, uint, S_IRUGO);
-module_param(debug, int, 0644);
-
+module_param(debug, bool, 0644);
+
+/**
+ * VPFE capture can be used for capturing video such as from TVP5146 or TVP7002
+ * and for capture raw bayer data from camera sensors such as MT9T031. At this
+ * point there is problem in co-existence of mt9t031 and tvp5146 due to i2c
+ * address collision. So set the variable below from bootargs to do either
video
+ * capture or camera capture.
+ * interface = 0 - video capture (from TVP514x or such),
+ * interface = 1 - Camera capture (from MT9T031 or such)
+ * Re-visit this when we fix the co-existence issue
+ */
+MODULE_PARM_DESC(interface, interface 0-1 (default:0));
MODULE_PARM_DESC(numbuffers, buffer count (default:3));
MODULE_PARM_DESC(bufsize, buffer size in bytes (default:720 x 576 x 2));
MODULE_PARM_DESC(debug, Debug level 0-1);
@@ -143,6 +154,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SBGGR8,
},
.bpp = 1,
+ .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -152,6 +164,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SBGGR16,
},
.bpp = 2,
+ .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -161,6 +174,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_SGRBG10DPCM8,
},
.bpp = 1,
+ .subdev_pix_fmt = V4L2_PIX_FMT_SGRBG10,
},
{
.fmtdesc = {
@@ -170,6 +184,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_UYVY,
},
.bpp = 2,
+ .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
{
.fmtdesc = {
@@ -179,6 +194,7 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_YUYV,
},
.bpp = 2,
+ .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
{
.fmtdesc = {
@@ -188,12 +204,15 @@ static const struct vpfe_pixel_format vpfe_pix_fmts[] = {
.pixelformat = V4L2_PIX_FMT_NV12,
},
.bpp = 1,
+ .subdev_pix_fmt = V4L2_PIX_FMT_UYVY,
},
};
-/*
- * vpfe_lookup_pix_format()
- * lookup an entry in the vpfe pix format table based on pix_format
+/**
+ * vpfe_lookup_pix_format() - lookup an entry in the vpfe pix format table
+ * @pix_format: v4l pix format
+ * This function lookup an entry in the vpfe pix format table based on
+ * pix_format
*/
static const struct vpfe_pixel_format *vpfe_lookup_pix_format(u32 pix_format)
{
@@ -241,19 +260,19 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device *dev)
* walk through it
[PATCH 1/5 - v3]V4L: vpfe capture - adding new fields for vpfe capture enhancements
From: Muralidharan Karicheri m-kariche...@ti.com
Resending with V4L prefix.
Restructured the patch to apply cleanly. This will allow compilation after
applying each patch. To do this existing fields in the header files are
retained and removed later when the new fields are used.
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next repository
include/media/davinci/vpfe_capture.h | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/include/media/davinci/vpfe_capture.h
b/include/media/davinci/vpfe_capture.h
index 71d8982..196245e 100644
--- a/include/media/davinci/vpfe_capture.h
+++ b/include/media/davinci/vpfe_capture.h
@@ -47,6 +47,8 @@ struct vpfe_pixel_format {
struct v4l2_fmtdesc fmtdesc;
/* bytes per pixel */
int bpp;
+ /* decoder format */
+ u32 subdev_pix_fmt;
};
struct vpfe_std_info {
@@ -61,9 +63,16 @@ struct vpfe_route {
u32 output;
};
+enum vpfe_subdev_id {
+ VPFE_SUBDEV_TVP5146 = 1,
+ VPFE_SUBDEV_MT9T031 = 2
+};
+
struct vpfe_subdev_info {
- /* Sub device name */
+ /* Deprecated. Will be removed in the next patch */
char name[32];
+ /* Sub device module name */
+ char module_name[32];
/* Sub device group id */
int grp_id;
/* Number of inputs supported */
@@ -72,12 +81,16 @@ struct vpfe_subdev_info {
struct v4l2_input *inputs;
/* Sub dev routing information for each input */
struct vpfe_route *routes;
- /* check if sub dev supports routing */
- int can_route;
/* ccdc bus/interface configuration */
struct vpfe_hw_if_param ccdc_if_params;
/* i2c subdevice board info */
struct i2c_board_info board_info;
+ /* Is this a camera sub device ? */
+ unsigned is_camera:1;
+ /* check if sub dev supports routing */
+ unsigned can_route:1;
+ /* registered ? */
+ unsigned registered:1;
};
struct vpfe_config {
@@ -92,6 +105,12 @@ struct vpfe_config {
/* vpfe clock */
struct clk *vpssclk;
struct clk *slaveclk;
+ /* setup function for the input path */
+ int (*setup_input)(enum vpfe_subdev_id id);
+ /* number of clocks */
+ int num_clocks;
+ /* clocks used for vpfe capture */
+ char *clocks[];
};
struct vpfe_device {
@@ -102,6 +121,8 @@ struct vpfe_device {
struct v4l2_subdev **sd;
/* vpfe cfg */
struct vpfe_config *cfg;
+ /* clock ptrs for vpfe capture */
+ struct clk **clks;
/* V4l2 device */
struct v4l2_device v4l2_dev;
/* parent device */
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH 1/5 - v3] Adding new fields to add the vpfe capture enhancements
Please ignore this since v4l prefix is missing in the subject.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
new phone: 301-407-9583
Old Phone : 301-515-3736 (will be deprecated)
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Monday, August 17, 2009 7:19 PM
To: linux-me...@vger.kernel.org
Cc: davinci-linux-open-source@linux.davincidsp.com; hverk...@xs4all.nl;
Karicheri, Muralidharan
Subject: [PATCH 1/5 - v3] Adding new fields to add the vpfe capture
enhancements
From: Muralidharan Karicheri m-kariche...@ti.com
Restructured the patch to apply cleanly. This will allow compilation after
applying each patch. To do this existing fields in the header files are
retained and removed later when the new fields are used.
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next repository
include/media/davinci/vpfe_capture.h | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/include/media/davinci/vpfe_capture.h
b/include/media/davinci/vpfe_capture.h
index 71d8982..196245e 100644
--- a/include/media/davinci/vpfe_capture.h
+++ b/include/media/davinci/vpfe_capture.h
@@ -47,6 +47,8 @@ struct vpfe_pixel_format {
struct v4l2_fmtdesc fmtdesc;
/* bytes per pixel */
int bpp;
+ /* decoder format */
+ u32 subdev_pix_fmt;
};
struct vpfe_std_info {
@@ -61,9 +63,16 @@ struct vpfe_route {
u32 output;
};
+enum vpfe_subdev_id {
+ VPFE_SUBDEV_TVP5146 = 1,
+ VPFE_SUBDEV_MT9T031 = 2
+};
+
struct vpfe_subdev_info {
- /* Sub device name */
+ /* Deprecated. Will be removed in the next patch */
char name[32];
+ /* Sub device module name */
+ char module_name[32];
/* Sub device group id */
int grp_id;
/* Number of inputs supported */
@@ -72,12 +81,16 @@ struct vpfe_subdev_info {
struct v4l2_input *inputs;
/* Sub dev routing information for each input */
struct vpfe_route *routes;
- /* check if sub dev supports routing */
- int can_route;
/* ccdc bus/interface configuration */
struct vpfe_hw_if_param ccdc_if_params;
/* i2c subdevice board info */
struct i2c_board_info board_info;
+ /* Is this a camera sub device ? */
+ unsigned is_camera:1;
+ /* check if sub dev supports routing */
+ unsigned can_route:1;
+ /* registered ? */
+ unsigned registered:1;
};
struct vpfe_config {
@@ -92,6 +105,12 @@ struct vpfe_config {
/* vpfe clock */
struct clk *vpssclk;
struct clk *slaveclk;
+ /* setup function for the input path */
+ int (*setup_input)(enum vpfe_subdev_id id);
+ /* number of clocks */
+ int num_clocks;
+ /* clocks used for vpfe capture */
+ char *clocks[];
};
struct vpfe_device {
@@ -102,6 +121,8 @@ struct vpfe_device {
struct v4l2_subdev **sd;
/* vpfe cfg */
struct vpfe_config *cfg;
+ /* clock ptrs for vpfe capture */
+ struct clk **clks;
/* V4l2 device */
struct v4l2_device v4l2_dev;
/* parent device */
--
1.6.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
Hans, I have re-send vpfe capture patch. I will re-send vpif patches tomorrow. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 new phone: 301-407-9583 Old Phone : 301-515-3736 (will be deprecated) email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Monday, August 17, 2009 4:27 PM To: Karicheri, Muralidharan Cc: linux-me...@vger.kernel.org; davinci-linux-open- sou...@linux.davincidsp.com; khil...@deeprootsystems.com Subject: Re: [PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver On Monday 17 August 2009 22:10:04 Karicheri, Muralidharan wrote: Hans, Would you like the architecture specific changes against v4l-dvb linux- next tree or linux-davinci ? I will rework both the vpfe and vpif patches as per your comment. v4l-dvb linux-next. The current v4l-dvb at least compiles against that one, so that is the most appropriate tree to do the patches against. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: Regarding increase in Sever Thread stack size
The limit is the amount of memory in the heap that you assign for stacks.
- Rob
From: Sandeep YEDIRE [mailto:sandee...@yahoo.co.in]
Sent: Monday, August 17, 2009 5:43 AM
To: Tivy, Robert; davinci-linux-open-source@linux.davincidsp.com
Cc: Sandeep Yedire
Subject: Re: Regarding increase in Sever Thread stack size
Thanks for your reply. I am looking for the same. Is there any max limit for
this segment?
Many Thanks,
Sandeep.Yedire
From: Tivy, Robert rt...@ti.com
To: Sandeep YEDIRE sandee...@yahoo.co.in;
davinci-linux-open-source@linux.davincidsp.com
davinci-linux-open-source@linux.davincidsp.com
Cc: Sandeep Yedire sande...@acmet.com
Sent: Saturday, 15 August, 2009 5:09:38 AM
Subject: RE: Regarding increase in Sever Thread stack size
Is this what you're looking for?:
var Server = xdc.useModule('ti.sdo.ce.Server');
Server.algs = [
{name: viddec_copy, mod: VIDDEC_COPY, threadAttrs: {
stackSize: 0x4096, stackMemId: 0, priority: Server.MINPRI + 2}, groupId
: 0,
},
{name: videnc_copy, mod: VIDENC_COPY, threadAttrs: {
stackMemId: 0, priority: Server.MINPRI + 2}, groupId : 0,
}
];
The max limit is dictated by your available memory for BIOS TSK stacks.
- Rob
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Sandeep YEDIRE
Sent: Tuesday, August 11, 2009 10:34 PM
To: davinci-linux-open-source@linux.davincidsp.com
Cc: Sandeep Yedire
Subject: Regarding increase in Sever Thread stack size
Hello all,
is there anyway to increase server thread stack size for one particular codec?
What is max limit ?
Many Thanks,
Sandeep.Yedire
See the Web's breaking stories, chosen by people like you. Check out Yahoo!
Buzzhttp://in.rd.yahoo.com/tagline_buzz_1/*http://in.buzz.yahoo.com/.
Looking for local information? Find it on Yahoo!
Localhttp://in.rd.yahoo.com/tagline_local_1/*http://in.local.yahoo.com/
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)
Sergei Shtylyov wrote: Texas Instruments CPPI 4.1 DMA support for the MUSBMHRDC driver. snip .. Index: linux-davinci/drivers/usb/musb/Makefile === --- linux-davinci.orig/drivers/usb/musb/Makefile +++ linux-davinci/drivers/usb/musb/Makefile @@ -53,9 +53,13 @@ ifneq ($(CONFIG_MUSB_PIO_ONLY),y) musb_hdrc-objs += cppi_dma.o else - ifeq ($(CONFIG_USB_TUSB_OMAP_DMA),y) -musb_hdrc-objs += tusb6010_omap.o + ifeq ($(CONFIG_USB_TI_CPPI41_DMA),y) +musb_hdrc-objs += cppi41_dma.o +ifeq ($(CONFIG_USB_TUSB_OMAP_DMA),y) + musb_hdrc-objs += tusb6010_omap.o + +endif endif endif endif You put the ifeq($(CONFIG_USB_TUSB_OMAP_DMA),y) in the ifeq ($(CONFIG_USB_TI_CPPI41_DMA),y) . endif. So if CONFIG_USB_TI_CPPI41_DMA is not enabled, tusb6010_omap.c will not be compiled. Stanley. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
