Re: EDMA Question: Transfer Polling
On Thursday 14 January 2010 07:35:15 am Adithya Prakash wrote: Hi Caglar, You have to poll on the IPR register. Later to clear the bit in the IPR, you will have to write to the ICR register as IPR is read-only. You can find the details in this document: http://focus.ti.com/lit/ug/sprueq5a/sprueq5a.pdf Regards, Adithya Thanks for the tip. This solves the problem. Regards, Caglar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: 2.6.32 tag for the davinci kernel
Anand Sivaram aspn...@gmail.com writes: Do we have a tag for 2.6.32 davinci kernel? Actually I could not find any tag like v2.6.31-davinci1 for 2.6.32 kernel. I would like to baseline my development on top of 2.6.32 and I am looking for a label from where I could branch. Any help would be really appreciated. Hi Anand, I just created a v2.6.32-davinci1 tag. Admiteddly, this has not been thoroughly tested, but it includes v2.6.32 plus all the davinci changes that were queued up for 2.6.33 as well. Hope that helps, Kevin ___ 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 - v4 1/4] V4L - vpfe_capture-remove clock and platform code
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, January 14, 2010 3:48 PM
To: Karicheri, Muralidharan
Cc: linux-me...@vger.kernel.org; hverk...@xs4all.nl; mche...@infradead.org;
davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
Karicheri, Muralidharan m-kariche...@ti.com writes:
Mauro,
Please merge this patches if there are no more comments.
Kevin,
Could you work with Mauro to merge the arch part as required?
This version looks good with me.
I'll assume that these are targed for 2.6.34, not 2.6.33-rc fixes window.
That is correct.
These appear to be able at least compile independently, so as soon as
Mauro/Hans sign-off on them, I wi add PATCH 4/4 to davinci-next so
it will be queued for 2.6.34 and be a part of linux-next.
Thanks.
Murali
Mauro can queue patches 1-3 in his queue for 2.6.34. They will both
be in linux-next for testing.
Also, I can *temporarily* add patches 1-3 to davinci git so davinci git
will have them all while waiting for 2.6.34 merge window. I will then
drop them when Mauro's tree merges upstream.
Kevin
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, January 13, 2010 6:27 PM
To: linux-me...@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com; mche...@infradead.org
Cc: davinci-linux-open-source@linux.davincidsp.com; Karicheri,
Muralidharan
Subject: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
From: Muralidharan Karicheri m-kariche...@ti.com
Following changes are done in this patch:-
1) removed the platform code and clk configuration. They are now
part of ccdc driver (part of the ccdc patches and platform
patches 2-4)
2) Added proper error codes for ccdc register function
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree of v4l-dvb
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated
comments
against v1 of these patches.
drivers/media/video/davinci/vpfe_capture.c | 131 +++---
--
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
-/* for storing mem maps for CCDC */
-int ccdc_addr_size;
-void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
-BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR vpfe capture not initialized\n);
-ret = -1;
+ret = -EFAULT;
goto unlock;
}
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
ccdc_dev = dev;
-dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
- ccdc_cfg-ccdc_addr_size);
unlock:
mutex_unlock(ccdc_lock);
return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
-clk_disable(vpfe_cfg-vpssclk);
-clk_put(vpfe_cfg-vpssclk);
-clk_disable(vpfe_cfg-slaveclk);
-clk_put(vpfe_cfg-slaveclk);
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-int ret = -ENOENT;
-
-vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
-if (NULL == vpfe_cfg-vpssclk) {
-v4l2_err(vpfe_dev-pdev-driver, No clock defined for
- vpss_master\n);
-
RE: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform code
Mauro,
Could you add patches 1-3 to linux-next ASAP?
See the response from Kevin for the arch part.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Kevin Hilman [mailto:khil...@deeprootsystems.com]
Sent: Thursday, January 14, 2010 3:48 PM
To: Karicheri, Muralidharan
Cc: linux-me...@vger.kernel.org; hverk...@xs4all.nl; mche...@infradead.org;
davinci-linux-open-source@linux.davincidsp.com
Subject: Re: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
Karicheri, Muralidharan m-kariche...@ti.com writes:
Mauro,
Please merge this patches if there are no more comments.
Kevin,
Could you work with Mauro to merge the arch part as required?
This version looks good with me.
I'll assume that these are targed for 2.6.34, not 2.6.33-rc fixes window.
These appear to be able at least compile independently, so as soon as
Mauro/Hans sign-off on them, I wi add PATCH 4/4 to davinci-next so
it will be queued for 2.6.34 and be a part of linux-next.
Mauro can queue patches 1-3 in his queue for 2.6.34. They will both
be in linux-next for testing.
Also, I can *temporarily* add patches 1-3 to davinci git so davinci git
will have them all while waiting for 2.6.34 merge window. I will then
drop them when Mauro's tree merges upstream.
Kevin
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Karicheri, Muralidharan
Sent: Wednesday, January 13, 2010 6:27 PM
To: linux-me...@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com; mche...@infradead.org
Cc: davinci-linux-open-source@linux.davincidsp.com; Karicheri,
Muralidharan
Subject: [PATCH - v4 1/4] V4L - vpfe_capture-remove clock and platform
code
From: Muralidharan Karicheri m-kariche...@ti.com
Following changes are done in this patch:-
1) removed the platform code and clk configuration. They are now
part of ccdc driver (part of the ccdc patches and platform
patches 2-4)
2) Added proper error codes for ccdc register function
Reviewed-by: Vaibhav Hiremath hvaib...@ti.com
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Rebased to latest linux-next tree of v4l-dvb
This combines the two patches sent earlier to change the clock
configuration
and converting ccdc drivers to platform drivers. This has updated
comments
against v1 of these patches.
drivers/media/video/davinci/vpfe_capture.c | 131 +++---
--
1 files changed, 13 insertions(+), 118 deletions(-)
diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index de22bc9..885cd54 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -107,9 +107,6 @@ struct ccdc_config {
int vpfe_probed;
/* name of ccdc device */
char name[32];
-/* for storing mem maps for CCDC */
-int ccdc_addr_size;
-void *__iomem ccdc_addr;
};
/* data structures */
@@ -229,7 +226,6 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
BUG_ON(!dev-hw_ops.set_image_window);
BUG_ON(!dev-hw_ops.get_image_window);
BUG_ON(!dev-hw_ops.get_line_length);
-BUG_ON(!dev-hw_ops.setfbaddr);
BUG_ON(!dev-hw_ops.getfid);
mutex_lock(ccdc_lock);
@@ -240,25 +236,23 @@ int vpfe_register_ccdc_device(struct ccdc_hw_device
*dev)
* walk through it during vpfe probe
*/
printk(KERN_ERR vpfe capture not initialized\n);
-ret = -1;
+ret = -EFAULT;
goto unlock;
}
if (strcmp(dev-name, ccdc_cfg-name)) {
/* ignore this ccdc */
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
if (ccdc_dev) {
printk(KERN_ERR ccdc already registered\n);
-ret = -1;
+ret = -EINVAL;
goto unlock;
}
ccdc_dev = dev;
-dev-hw_ops.set_ccdc_base(ccdc_cfg-ccdc_addr,
- ccdc_cfg-ccdc_addr_size);
unlock:
mutex_unlock(ccdc_lock);
return ret;
@@ -1786,61 +1780,6 @@ static struct vpfe_device *vpfe_initialize(void)
return vpfe_dev;
}
-static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-
-clk_disable(vpfe_cfg-vpssclk);
-clk_put(vpfe_cfg-vpssclk);
-clk_disable(vpfe_cfg-slaveclk);
-clk_put(vpfe_cfg-slaveclk);
-v4l2_info(vpfe_dev-pdev-driver,
- vpfe vpss master slave clocks disabled\n);
-}
-
-static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
-{
-struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
-int ret = -ENOENT;
-
-
RE: DMA for Davinci SPI controller with multiple slave devices
-Original Message- From: Nori, Sekhar [mailto:nsek...@ti.com] Sent: Thursday, January 14, 2010 12:44 AM To: Brian Niebuhr Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: DMA for Davinci SPI controller with multiple slave devices Hello Brian, On Thu, Jan 14, 2010 at 04:26:15, Brian Niebuhr wrote: I am working on building a kernel for a custom board based on an OMAP L138. As a baseline I am using the OMAP L138 SDK kernel. On my board there are multiple SPI slaves connected to the SPI1 controller. I'm getting some errors during boot because after the first slave has initialized, the others report an error that they can't aquire a DMA channel. I've been looking through the code and I understand why the error occurs, but I'm not sure how to fix it correctly. Here's what I know: - In arch/arm/mach-davinci/devices-da8xx.c there are two DMA channels (one Tx, one Rx) allocated for the SPI1 controller. - In drivers/spi/davinci_spi_master.c the controller maintains a struct davinci_spi_dma for every chip select. - In drivers/spi/davinci_spi_master.c, davinci_spi_probe() sets the dma_rx_sync_dev field of that structure for every chip select to the Rx DMA channel, and likewise the dma_tx_sync_dev field of that structure for every chip select to the Tx DMA channel. - Then for every SPI device, drivers/spi/davinci_spi_master.c:davinci_spi_setup() gets called which in turn calls davinci_spi_request_dma(). - So here is the problem: davinci_spi_request_dma() requests the channels specified in dma_rx_sync_dev and dma_tx_sync_dev, which are the same channels for every device. Therefore the first device succeeds but additional devices on that controller fail. Yes, this was reported before when the driver patch was submitted for review[1]. But, in the interest of having the driver hit upstream sooner versus having all features supported correctly, this has remained a TODO item. So I'm trying to figure out what the driver writer intended so I can solve this problem. I see two potential solutions: 1. Allocate more DMA channels in devices-da8xx.c. Then in davinci_spi_probe() set the dma_[rx|tx]_sync_dev fields to a different channel for each device. I don't fully understand though if they would need separate eventqs too. This seems unnecessary, though, because only one can be active at a time anyway. 2. Share the DMA channels between all devices on a controller. This seems like it would work fine except for the fact that the DMA callbacks would be messed up as written. However I also think that it would be possible to rewrite the callback function to work correctly. Right. Without a fix of some sort, the only other way is to not to use DMA at all and use PIO mode instead. I'm leaning toward (2), but I don't fully understand the driver. I believe (2) is the right way too. Does anyone have any suggestions on how to fix this, or am I just completely misunderstanding how this is supposed to work? A fix is needed. It would be great if this is something you can help on. I will attempt a fix, though it's going to be a while before I get to test it. If I can test before anyone else gets around to fixing it, I'll submit a patch. Brian Thanks, Sekhar [1] http://linux.omap.com/pipermail/davinci-linux-open-source/2009 -November/016979.html ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
