Re: [alsa-devel] [PATCH v2 1/5] MFD: DaVinci Voice Codec
On Thu, 2010-03-11 at 09:32 -0600, miguel.agui...@ridgerun.com wrote: From: Miguel Aguilar miguel.agui...@ridgerun.com This is the MFD driver for the DaVinci Voice codec, it has two clients: * Voice codec interface * Voice codec CQ93VC Signed-off-by: Miguel Aguilar miguel.agui...@ridgerun.com Please CC the MFD maintainer too for this one. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [alsa-devel] [PATCH v2 2/5] ASoC: DaVinci: Voice Codec Interface
On Thu, 2010-03-11 at 09:32 -0600, miguel.agui...@ridgerun.com wrote:
From: Miguel Aguilar miguel.agui...@ridgerun.com
This patch adds the support for the interface needed by the DaVinci
Voice Codec CQ93VC.
Signed-off-by: Miguel Aguilar miguel.agui...@ridgerun.com
---
snip
+
+static int davinci_vcif_hw_params(struct snd_pcm_substream *substream,
+ struct snd_pcm_hw_params *params,
+ struct snd_soc_dai *dai)
+{
+ struct davinci_vcif_dev *davinci_vcif_dev = dai-private_data;
+ struct davinci_vc *davinci_vc = davinci_vcif_dev-davinci_vc;
+ struct davinci_pcm_dma_params *dma_params =
+ davinci_vcif_dev-dma_params[substream-stream];
+ u32 w;
+
+ /* Restart the codec before setup */
+ davinci_vcif_stop(substream);
+ davinci_vcif_start(substream);
+
+ /* General line settings */
+ writel(DAVINCI_VC_CTRL_MASK, davinci_vc-base + DAVINCI_VC_CTRL);
+
+ writel(DAVINCI_VC_INT_MASK, davinci_vc-base + DAVINCI_VC_INTCLR);
+
+ writel(DAVINCI_VC_INT_MASK, davinci_vc-base + DAVINCI_VC_INTEN);
+
+ w = readl(davinci_vc-base + DAVINCI_VC_CTRL);
+
+ /* Determine xfer data type */
+ switch (params_format(params)) {
+ case SNDRV_PCM_FORMAT_U8:
+ dma_params-data_type = 0;
+
+ MOD_REG_BIT(w, DAVINCI_VC_CTRL_RD_BITS_8 |
+ DAVINCI_VC_CTRL_RD_UNSIGNED |
+ DAVINCI_VC_CTRL_WD_BITS_8 |
+ DAVINCI_VC_CTRL_WD_UNSIGNED, 1);
+ break;
+ case SNDRV_PCM_FORMAT_S8:
+ dma_params-data_type = 1;
+
+ MOD_REG_BIT(w, DAVINCI_VC_CTRL_RD_BITS_8 |
+ DAVINCI_VC_CTRL_WD_BITS_8, 1);
+
+ MOD_REG_BIT(w, DAVINCI_VC_CTRL_RD_UNSIGNED |
+ DAVINCI_VC_CTRL_WD_UNSIGNED, 0);
+ break;
+ case SNDRV_PCM_FORMAT_S16_LE:
+ dma_params-data_type = 2;
+
+ MOD_REG_BIT(w, DAVINCI_VC_CTRL_RD_BITS_8 |
+ DAVINCI_VC_CTRL_RD_UNSIGNED |
+ DAVINCI_VC_CTRL_WD_BITS_8 |
+ DAVINCI_VC_CTRL_WD_UNSIGNED, 0);
+ break;
+ default:
+ printk(KERN_WARNING davinci-vcif: unsupported PCM format);
+ return -EINVAL;
+ }
+
+ dma_params-acnt = dma_params-data_type;
+
+ writel(w, davinci_vc-base + DAVINCI_VC_CTRL);
+
+ return 0;
+}
+
+static int davinci_vcif_trigger(struct snd_pcm_substream *substream, int cmd,
+ struct snd_soc_dai *dai)
+{
+ int ret = 0;
+
+ switch (cmd) {
+ case SNDRV_PCM_TRIGGER_START:
+ case SNDRV_PCM_TRIGGER_RESUME:
+ case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
+ davinci_vcif_start(substream);
+ case SNDRV_PCM_TRIGGER_STOP:
+ case SNDRV_PCM_TRIGGER_SUSPEND:
+ case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
+ davinci_vcif_stop(substream);
+ break;
+ default:
+ ret = -EINVAL;
+ }
+
+ return ret;
+}
+
+#define DAVINCI_VCIF_RATES SNDRV_PCM_RATE_8000_48000
+
+static struct snd_soc_dai_ops davinci_vcif_dai_ops = {
+ .trigger= davinci_vcif_trigger,
+ .hw_params = davinci_vcif_hw_params,
+};
+
+struct snd_soc_dai davinci_vcif_dai = {
+ .name = davinci-vcif,
+ .playback = {
+ .channels_min = 1,
+ .channels_max = 2,
+ .rates = DAVINCI_VCIF_RATES,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,},
+ .capture = {
+ .channels_min = 1,
+ .channels_max = 2,
+ .rates = DAVINCI_VCIF_RATES,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE,},
Your hw_params() supports more formats than just this one.
Liam
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [alsa-devel] [PATCH v2 1/5] MFD: DaVinci Voice Codec
On 12 Mar 2010, at 08:01, Liam Girdwood l...@slimlogic.co.uk wrote: On Thu, 2010-03-11 at 09:32 -0600, miguel.agui...@ridgerun.com wrote: From: Miguel Aguilar miguel.agui...@ridgerun.com This is the MFD driver for the DaVinci Voice codec, it has two clients: * Voice codec interface * Voice codec CQ93VC Signed-off-by: Miguel Aguilar miguel.agui...@ridgerun.com Please CC the MFD maintainer too for this one. Or if, as is the case here IIRC, they've already acked it include their ack in repostings. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk ___ 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] davinci: MMC: Pass number of SG segments as platform data
Hi,
On Thu, Mar 11, 2010 at 16:30:45, Sergei Shtylyov wrote:
Hello.
Sudhakar Rajashekhara wrote:
On some platforms like DM355, the number of EDMA parameter
slots available for EDMA_SLOT_ANY usage are few. In such cases,
if MMC/SD uses 16 slots for each instance of MMC controller,
then the number of slots available for other modules will be
very few.
By passing the number of EDMA slots to be used in MMC driver
from platform data, EDMA slots available for other purposes
can be controlled.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
arch/arm/mach-davinci/include/mach/mmc.h |3 +++
drivers/mmc/host/davinci_mmc.c | 22 +++---
2 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/mmc.h
b/arch/arm/mach-davinci/include/mach/mmc.h
index 5a85e24..384fc0e 100644
--- a/arch/arm/mach-davinci/include/mach/mmc.h
+++ b/arch/arm/mach-davinci/include/mach/mmc.h
@@ -22,6 +22,9 @@ struct davinci_mmc_config {
/* Version of the MMC/SD controller */
u8 version;
+
+ /* Number of sg segments */
+ u32 nr_sg;
Why waste 4 bytres if the maximum number is 16?
I'll modify it to u8 and re-submit the patch.
Thanks,
Sudhakar
___
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] davinci: MMC: Pass number of SG segments as platform data
Kevin, On Fri, Mar 12, 2010 at 05:09:24, Kevin Hilman wrote: Sudhakar Rajashekhara sudhakar@ti.com writes: On some platforms like DM355, the number of EDMA parameter slots available for EDMA_SLOT_ANY usage are few. In such cases, if MMC/SD uses 16 slots for each instance of MMC controller, then the number of slots available for other modules will be very few. By passing the number of EDMA slots to be used in MMC driver from platform data, EDMA slots available for other purposes can be controlled. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com --- arch/arm/mach-davinci/include/mach/mmc.h |3 +++ drivers/mmc/host/davinci_mmc.c | 22 +++--- 2 files changed, 18 insertions(+), 7 deletions(-) [...] @@ -1202,6 +1206,10 @@ static int __init davinci_mmcsd_probe(struct platform_device *pdev) init_mmcsd_host(host); + host-nr_sg = pdata-nr_sg - 1; If a board doesn't setup pdata-nr_sg it will be zero, leaving host-nr_sg = -1. + if (host-nr_sg MAX_NR_SG || host-nr_sg == 0) + host-nr_sg = MAX_NR_SG; Since host-nr_sg is unsigned, you get lucky and fix it up here, but for readability, this not too clean and should be more thorough. Wrapping the above in 'if (pdata-nr_sg)' is a more standard way of handling optional platform_data paramaters. I'll modify the patch as per your suggestion and resubmit it. Thanks, Sudhakar ___ 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 v2 1/5] MFD: DaVinci Voice Codec
Thank for the support.
I'm sorry, maybe my question is too simple, anyway I have to understand
which is the default git tree where the patches are normally done against.
I guess you have written the patch against
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git git
tree.
It is right?
If I'm right I can guess that the default git tree where every developer is
working on davinci is actually
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git.
Please somebody can give a clear information about this point?
2010/3/11 miguel.agui...@ridgerun.com
From: Miguel Aguilar miguel.agui...@ridgerun.com
This is the MFD driver for the DaVinci Voice codec, it has two clients:
* Voice codec interface
* Voice codec CQ93VC
Signed-off-by: Miguel Aguilar miguel.agui...@ridgerun.com
---
drivers/mfd/Kconfig|4 +
drivers/mfd/Makefile |1 +
drivers/mfd/davinci_voicecodec.c | 189
include/linux/mfd/davinci_voicecodec.h | 126 +
4 files changed, 320 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/davinci_voicecodec.c
create mode 100644 include/linux/mfd/davinci_voicecodec.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 8782978..6e93c0b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -43,6 +43,10 @@ config MFD_SH_MOBILE_SDHI
This driver supports the SDHI hardware block found in many
SuperH Mobile SoCs.
+config MFD_DAVINCI_VOICECODEC
+ tristate
+ select MFD_CORE
+
config MFD_DM355EVM_MSP
bool DaVinci DM355 EVM microcontroller
depends on I2C MACH_DAVINCI_DM355_EVM
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index ca2f2c4..f5c617f 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_MFD_SH_MOBILE_SDHI)+=
sh_mobile_sdhi.o
obj-$(CONFIG_HTC_EGPIO)+= htc-egpio.o
obj-$(CONFIG_HTC_PASIC3) += htc-pasic3.o
+obj-$(CONFIG_MFD_DAVINCI_VOICECODEC) += davinci_voicecodec.o
obj-$(CONFIG_MFD_DM355EVM_MSP) += dm355evm_msp.o
obj-$(CONFIG_MFD_T7L66XB) += t7l66xb.o
diff --git a/drivers/mfd/davinci_voicecodec.c
b/drivers/mfd/davinci_voicecodec.c
new file mode 100644
index 000..9886aa8
--- /dev/null
+++ b/drivers/mfd/davinci_voicecodec.c
@@ -0,0 +1,189 @@
+/*
+ * DaVinci Voice Codec Core Interface for TI platforms
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc
+ *
+ * Author: Miguel Aguilar miguel.agui...@ridgerun.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/device.h
+#include linux/delay.h
+#include linux/io.h
+#include linux/clk.h
+
+#include sound/pcm.h
+
+#include linux/mfd/davinci_voicecodec.h
+
+u32 davinci_vc_read(struct davinci_vc *davinci_vc, int reg)
+{
+ return __raw_readl(davinci_vc-base + reg);
+}
+
+void davinci_vc_write(struct davinci_vc *davinci_vc,
+ int reg, u32 val)
+{
+ __raw_writel(val, davinci_vc-base + reg);
+}
+
+static int __init davinci_vc_probe(struct platform_device *pdev)
+{
+ struct davinci_vc *davinci_vc;
+ struct resource *res, *mem;
+ struct mfd_cell *cell = NULL;
+ int ret;
+
+ davinci_vc = kzalloc(sizeof(struct davinci_vc), GFP_KERNEL);
+ if (!davinci_vc) {
+ dev_dbg(pdev-dev,
+ could not allocate memory for private
data\n);
+ return -ENOMEM;
+ }
+
+ davinci_vc-clk = clk_get(pdev-dev, NULL);
+ if (IS_ERR(davinci_vc-clk)) {
+ dev_dbg(pdev-dev,
+ could not get the clock for voice codec\n);
+ ret = -ENODEV;
+ goto fail1;
+ }
+ clk_enable(davinci_vc-clk);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(pdev-dev, no mem resource\n);
+ ret = -ENODEV;
+ goto fail2;
+ }
+
+ davinci_vc-pbase = res-start;
+ davinci_vc-base_size = resource_size(res);
+
+ mem =
Re: [alsa-devel] [PATCH v2 1/5] MFD: DaVinci Voice Codec
On Fri, Mar 12, 2010 at 08:13:25AM +, Mark Brown wrote: On 12 Mar 2010, at 08:01, Liam Girdwood l...@slimlogic.co.uk wrote: On Thu, 2010-03-11 at 09:32 -0600, miguel.agui...@ridgerun.com wrote: This is the MFD driver for the DaVinci Voice codec, it has two clients: * Voice codec interface * Voice codec CQ93VC Signed-off-by: Miguel Aguilar miguel.agui...@ridgerun.com Please CC the MFD maintainer too for this one. Or if, as is the case here IIRC, they've already acked it include their ack in repostings. I've found Samuel's previous ack so I've applied the series now - the issue with the capabilities not covering everything the hw_params do that Liam identified can be addressed with an incremental patch. Thanks! ___ 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] davinci: MMC: Pass number of SG segments as platform data
On some platforms like DM355, the number of EDMA parameter
slots available for EDMA_SLOT_ANY usage are few. In such cases,
if MMC/SD uses 16 slots for each instance of MMC controller,
then the number of slots available for other modules will be
very few.
By passing the number of EDMA slots to be used in MMC driver
from platform data, EDMA slots available for other purposes
can be controlled.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
Following are the modifications from the previous version:
1. Changed the type of nr_sg variable to u8 from u32.
2. 'if (pdata-nr_sg)' check was introduced before initializing
host-nr_sg.
arch/arm/mach-davinci/include/mach/mmc.h |3 +++
drivers/mmc/host/davinci_mmc.c | 24 +---
2 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/mmc.h
b/arch/arm/mach-davinci/include/mach/mmc.h
index 5a85e24..d4f1e96 100644
--- a/arch/arm/mach-davinci/include/mach/mmc.h
+++ b/arch/arm/mach-davinci/include/mach/mmc.h
@@ -22,6 +22,9 @@ struct davinci_mmc_config {
/* Version of the MMC/SD controller */
u8 version;
+
+ /* Number of sg segments */
+ u8 nr_sg;
};
void davinci_setup_mmc(int module, struct davinci_mmc_config *config);
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 3bd0ba2..547d29c 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -137,15 +137,15 @@
/*
* One scatterlist dma segment is at most MAX_CCNT rw_threshold units,
- * and we handle up to NR_SG segments. MMC_BLOCK_BOUNCE kicks in only
+ * and we handle up to MAX_NR_SG segments. MMC_BLOCK_BOUNCE kicks in only
* for drivers with max_hw_segs == 1, making the segments bigger (64KB)
- * than the page or two that's otherwise typical. NR_SG == 16 gives at
- * least the same throughput boost, using EDMA transfer linkage instead
- * of spending CPU time copying pages.
+ * than the page or two that's otherwise typical. nr_sg (passed from
+ * platform data) == 16 gives at least the same throughput boost, using
+ * EDMA transfer linkage instead of spending CPU time copying pages.
*/
#define MAX_CCNT ((1 16) - 1)
-#define NR_SG 16
+#define MAX_NR_SG 16
static unsigned rw_threshold = 32;
module_param(rw_threshold, uint, S_IRUGO);
@@ -192,7 +192,7 @@ struct mmc_davinci_host {
struct edmacc_param tx_template;
struct edmacc_param rx_template;
unsignedn_link;
- u32 links[NR_SG - 1];
+ u32 links[MAX_NR_SG - 1];
/* For PIO we walk scatterlists one segment at a time. */
unsigned intsg_len;
@@ -202,6 +202,8 @@ struct mmc_davinci_host {
u8 version;
/* for ns in one cycle calculation */
unsigned ns_in_one_cycle;
+ /* Number of sg segments */
+ u8 nr_sg;
#ifdef CONFIG_CPU_FREQ
struct notifier_block freq_transition;
#endif
@@ -568,6 +570,7 @@ davinci_release_dma_channels(struct mmc_davinci_host *host)
static int __init davinci_acquire_dma_channels(struct mmc_davinci_host *host)
{
+ u32 link_size;
int r, i;
/* Acquire master DMA write channel */
@@ -593,7 +596,8 @@ static int __init davinci_acquire_dma_channels(struct
mmc_davinci_host *host)
/* Allocate parameter RAM slots, which will later be bound to a
* channel as needed to handle a scatterlist.
*/
- for (i = 0; i ARRAY_SIZE(host-links); i++) {
+ link_size = min_t(unsigned, host-nr_sg, ARRAY_SIZE(host-links));
+ for (i = 0; i link_size; i++) {
r = edma_alloc_slot(EDMA_CTLR(host-txdma), EDMA_SLOT_ANY);
if (r 0) {
dev_dbg(mmc_dev(host-mmc), dma PaRAM alloc -- %d\n,
@@ -1202,6 +1206,12 @@ static int __init davinci_mmcsd_probe(struct
platform_device *pdev)
init_mmcsd_host(host);
+ if (pdata-nr_sg)
+ host-nr_sg = pdata-nr_sg - 1;
+
+ if (host-nr_sg MAX_NR_SG || !host-nr_sg)
+ host-nr_sg = MAX_NR_SG;
+
host-use_dma = use_dma;
host-irq = irq;
--
1.5.6
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 0/2] overhaul davinci spi driver to fix multiple errors
INTRODUCTION I have been working on a custom OMAP-L138 board that has multiple spi devices (seven) on one controller. These devices have a wide range of transfer parameters (speed, phase, polarity, internal and gpio chip selects). During my testing I found multiple errors in the davinci spi driver as a result of this complex setup. The primary issues were: 1. There is a race condition due to the SPIBUF read busy-waits for slow devices 2. I found some DMA transfer length errors under some conditions 3. The chip select code caused extra byte transfers (with no chip select active) due to writes to SPIDAT1 4. Several issues prevented using multiple SPI devices, especially the DMA code, as disucussed previously on the davinci list. The fixes to these problems were not simple. I ended up making fairly large changes to the driver, and those changes are contained in these patches. The full list of changes follows. CHANGE LIST 1. davinci_spi_chipelect() now performs both activation and deactivation of chip selects. This lets spi_bitbang fully control chip select activation, as intended by the SPI API. 2. Chip select activation does not cause extra writes to the SPI bus 3. Chip select activation does not use SPIDEF for control. This change will also allow for implementation of inverted (active high) chip selects in the future. 4. Added back gpio chip select capability from the old driver 5. Fixed prescale calculation for non-integer fractions of spi clock 6. Allow specification of SPI transfer parameters on a per-device (instead of per-controller) basis 7. Allow specification of polled, interrupt-based, or DMA operation on a per-device basis 8. Allow DMA with when more than one device is connected 9. Combined pio and dma txrx_bufs functions into one since they share large parts of their functionality, and to simplify item (8). 10. Use only SPIFMT0 to allow more than 4 devices TESTING I have tested the driver using a custom SPI stress test on my OMAP-L138-based board with three devices connected. I have tested configurations with all three devices polled, all three interrupt-based, all three DMA, and a mixture. I have compiled with the davinci_all_defconfig, but I don't have EVMs for the other davinci platforms to test with. SUMMARY I realize that this is a very large patch, but I hope that it's not thrown out just because of its size. It does solve a lot of issues that should save a lot of people time down the road. I would appreciate any feedback from those who can test it out on other davinci EVMs. Brian Niebuhr (2): spi: overhaul davinci spi driver to correct multiple errors spi: modify davinci platform data for updated driver arch/arm/mach-davinci/board-dm355-evm.c | 10 + arch/arm/mach-davinci/board-dm355-leopard.c | 10 + arch/arm/mach-davinci/board-dm365-evm.c | 10 + arch/arm/mach-davinci/board-dm646x-evm.c| 12 + arch/arm/mach-davinci/dm355.c |7 - arch/arm/mach-davinci/dm365.c |7 - arch/arm/mach-davinci/dm646x.c |7 - arch/arm/mach-davinci/include/mach/spi.h| 30 +- drivers/spi/davinci_spi.c | 1021 +++ drivers/spi/davinci_spi.h | 53 +- 10 files changed, 495 insertions(+), 672 deletions(-) ___ 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/2] spi: overhaul davinci spi driver to correct multiple errors
This patch is a significant overhaul of the davinci spi controller driver
that corrects multiple errors:
- Eliminate a race condition that exists for slow SPI devices
- Fix DMA transfer length error
- Fix limitations preventing multiple SPI devices on the same controller
Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com
---
arch/arm/mach-davinci/include/mach/spi.h | 30 +-
drivers/spi/davinci_spi.c| 1021 --
drivers/spi/davinci_spi.h| 53 +-
3 files changed, 453 insertions(+), 651 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/spi.h
b/arch/arm/mach-davinci/include/mach/spi.h
index 7b54926..f88f1ec 100644
--- a/arch/arm/mach-davinci/include/mach/spi.h
+++ b/arch/arm/mach-davinci/include/mach/spi.h
@@ -34,18 +34,24 @@ enum {
struct davinci_spi_platform_data {
u8 version;
u16 num_chipselect;
- u32 wdelay;
- u32 odd_parity;
- u32 parity_enable;
- u32 wait_enable;
- u32 timer_disable;
- u32 clk_internal;
- u32 cs_hold;
- u32 intr_level;
- u32 poll_mode;
- u32 use_dma;
- u8 c2tdelay;
- u8 t2cdelay;
+ u8 *chip_sel;
+};
+
+struct davinci_spi_config {
+ u32 odd_parity : 1;
+ u32 parity_enable : 1;
+ u32 intr_level : 1;
+ u32 io_type : 2;
+#define SPI_IO_TYPE_INTR0
+#define SPI_IO_TYPE_POLL1
+#define SPI_IO_TYPE_DMA 2
+ u32 bytes_per_word : 2;
+ u32 wdelay : 6;
+ u32 timer_disable : 1;
+ u8 c2t_delay;
+ u8 t2c_delay;
+ u8 t2e_delay;
+ u8 c2e_delay;
};
#endif /* __ARCH_ARM_DAVINCI_SPI_H */
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 956f617..eec2fe9 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2009 Texas Instruments.
+ * Copyright (C) 2010 EF Johnson Technologies
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -33,43 +34,45 @@
#include davinci_spi.h
-static unsigned use_dma;
-
#defineDAVINCI_SPI_NO_RESOURCE ((resource_size_t)-1)
static void davinci_spi_rx_buf_u8(u32 data, struct davinci_spi *davinci_spi)
{
- u8 *rx = davinci_spi-rx;
-
- *rx++ = (u8)data;
- davinci_spi-rx = rx;
+ if (davinci_spi-rx) {
+ u8 *rx = davinci_spi-rx;
+ *rx++ = (u8)data;
+ davinci_spi-rx = rx;
+ }
}
static void davinci_spi_rx_buf_u16(u32 data, struct davinci_spi *davinci_spi)
{
- u16 *rx = davinci_spi-rx;
-
- *rx++ = (u16)data;
- davinci_spi-rx = rx;
+ if (davinci_spi-rx) {
+ u16 *rx = davinci_spi-rx;
+ *rx++ = (u16)data;
+ davinci_spi-rx = rx;
+ }
}
static u32 davinci_spi_tx_buf_u8(struct davinci_spi *davinci_spi)
{
- u32 data;
- const u8 *tx = davinci_spi-tx;
-
- data = *tx++;
- davinci_spi-tx = tx;
+ u32 data = 0;
+ if (davinci_spi-tx) {
+ const u8 *tx = davinci_spi-tx;
+ data = *tx++;
+ davinci_spi-tx = tx;
+ }
return data;
}
static u32 davinci_spi_tx_buf_u16(struct davinci_spi *davinci_spi)
{
- u32 data;
- const u16 *tx = davinci_spi-tx;
-
- data = *tx++;
- davinci_spi-tx = tx;
+ u32 data = 0;
+ if (davinci_spi-tx) {
+ const u16 *tx = davinci_spi-tx;
+ data = *tx++;
+ davinci_spi-tx = tx;
+ }
return data;
}
@@ -89,26 +92,6 @@ static inline void clear_io_bits(void __iomem *addr, u32
bits)
iowrite32(v, addr);
}
-static inline void set_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
-{
- set_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
-}
-
-static inline void clear_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
-{
- clear_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
-}
-
-static void davinci_spi_set_dma_req(const struct spi_device *spi, int enable)
-{
- struct davinci_spi *davinci_spi = spi_master_get_devdata(spi-master);
-
- if (enable)
- set_io_bits(davinci_spi-base + SPIINT, SPIINT_DMA_REQ_EN);
- else
- clear_io_bits(davinci_spi-base + SPIINT, SPIINT_DMA_REQ_EN);
-}
-
/*
* Interface to control the chip select signal
*/
@@ -116,25 +99,54 @@ static void davinci_spi_chipselect(struct spi_device *spi,
int value)
{
struct davinci_spi *davinci_spi;
struct davinci_spi_platform_data *pdata;
- u32 data1_reg_val = 0;
+ u8 i, chip_sel = spi-chip_select;
+ u32 spidat1;
+ u16 spidat1_cfg;
davinci_spi = spi_master_get_devdata(spi-master);
pdata =
[PATCH 2/2] spi: modify davinci platform data for updated driver
These changes update the davinci platform data to match the modifications
that were done to the davinci spi controller driver. The driver update
allowed per-device transfer settings, which are provided by this patch.
Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com
---
arch/arm/mach-davinci/board-dm355-evm.c | 10 ++
arch/arm/mach-davinci/board-dm355-leopard.c | 10 ++
arch/arm/mach-davinci/board-dm365-evm.c | 10 ++
arch/arm/mach-davinci/board-dm646x-evm.c| 12
arch/arm/mach-davinci/dm355.c |7 ---
arch/arm/mach-davinci/dm365.c |7 ---
arch/arm/mach-davinci/dm646x.c |7 ---
7 files changed, 42 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index a0724fa..b1a21a4 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -40,6 +40,7 @@
#include mach/serial.h
#include mach/nand.h
#include mach/mmc.h
+#include mach/spi.h
#define DAVINCI_ASYNC_EMIF_CONTROL_BASE0x01e1
#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x0200
@@ -445,10 +446,19 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = 0,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 1,
+};
+
static struct spi_board_info dm355_evm_spi_info[] __initconst = {
{
.modalias = at25,
.platform_data = at25640a,
+ .controller_data = at25640a_spi_cfg,
.max_speed_hz = 30 * 1000 * 1000, /* at 3v3 */
.bus_num= 0,
.chip_select= 0,
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c
b/arch/arm/mach-davinci/board-dm355-leopard.c
index 84ad5d1..d87ff0b 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -36,6 +36,7 @@
#include mach/serial.h
#include mach/nand.h
#include mach/mmc.h
+#include mach/spi.h
#define DAVINCI_ASYNC_EMIF_CONTROL_BASE0x01e1
#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x0200
@@ -232,10 +233,19 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = 0,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 1,
+};
+
static struct spi_board_info dm355_leopard_spi_info[] __initconst = {
{
.modalias = at25,
.platform_data = at25640a,
+ .controller_data = at25640a_spi_cfg,
.max_speed_hz = 10 * 1000 * 1000, /* at 3v3 */
.bus_num= 0,
.chip_select= 0,
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index ab3b0e2..8559c84 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -44,6 +44,7 @@
#include mach/nand.h
#include mach/keyscan.h
#include mach/gpio.h
+#include mach/spi.h
#include linux/videodev2.h
#include media/tvp514x.h
#include media/tvp7002.h
@@ -832,10 +833,19 @@ static struct spi_eeprom at25640 = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640_spi_cfg = {
+ .parity_enable = 0,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 1,
+};
+
static struct spi_board_info dm365_evm_spi_info[] __initconst = {
{
.modalias = at25,
.platform_data = at25640,
+ .controller_data = at25640_spi_cfg,
.max_speed_hz = 20 * 1000 * 1000, /* at 3v3 */
.bus_num= 0,
.chip_select= 0,
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 94271a6..5430b00 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -58,6 +58,7 @@
#include mach/nand.h
#include mach/mmc.h
#include mach/emac.h
+#include mach/spi.h
#include mach/clock.h
#include clock.h
@@ -911,10 +912,21 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = 0,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 0,
+ .c2t_delay = 8,
+ .t2c_delay = 8,
+};
+
static struct spi_board_info dm646x_evm_spi_info[] __initconst = {
{
.modalias = at25,
Re: [PATCH] davinci: edma: clear interrupt status for interrupt enabled channels only
Sekhar Nori nsek...@ti.com writes:
From: Anuj Aggarwal anuj.aggar...@ti.com
Currently, the ISR in the EDMA driver clears the pending interrupt for all
channels without regard to whether that channel has a registered callback
or not.
This causes problems for devices like DM355/DM365 where the multimedia
accelerator uses EDMA by polling on the interrupt pending bits of some of the
EDMA channels. Since these channels are actually allocated through the Linux
EDMA driver (by an out-of-kernel module), the same shadow region is used by
Linux and accelerator. There a race between the Linux ISR and the polling code
running on the accelerator on the IPR (interrupt pending register).
This patch fixes the issue by making the ISR clear the interrupts only for
those channels which have interrupt enabled. The channels which are allocated
for the purpose of being polled on by the accelerator will not have a callback
function provided and so will not have IER (interrupt enable register) bits
set.
Dumb question: why cat the MM accelerator use the normal ISR + callback?
Kevin
Tested on DM365 and OMAP-L137/L138 with audio and MMC/SD (as EDMA users).
Signed-off-by: Anuj Aggarwal anuj.aggar...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
CC: Archith John Bency arch...@ti.com
---
arch/arm/mach-davinci/dma.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 15dd886..ea74a90 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -358,9 +358,11 @@ static irqreturn_t dma_irq_handler(int irq, void *data)
while (1) {
int j;
- if (edma_shadow0_read_array(ctlr, SH_IPR, 0))
+ if (edma_shadow0_read_array(ctlr, SH_IPR, 0)
+ edma_shadow0_read_array(ctlr, SH_IER, 0))
j = 0;
- else if (edma_shadow0_read_array(ctlr, SH_IPR, 1))
+ else if (edma_shadow0_read_array(ctlr, SH_IPR, 1)
+ edma_shadow0_read_array(ctlr, SH_IER, 1))
j = 1;
else
break;
@@ -368,8 +370,9 @@ static irqreturn_t dma_irq_handler(int irq, void *data)
edma_shadow0_read_array(ctlr, SH_IPR, j));
for (i = 0; i 32; i++) {
int k = (j 5) + i;
- if (edma_shadow0_read_array(ctlr, SH_IPR, j)
- (1 i)) {
+ if ((edma_shadow0_read_array(ctlr, SH_IPR, j) BIT(i))
+ (edma_shadow0_read_array(ctlr,
+ SH_IER, j) BIT(i))) {
/* Clear the corresponding IPR bits */
edma_shadow0_write_array(ctlr, SH_ICR, j,
(1 i));
--
1.6.2.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
VPFE fixes and enhancments patch
Hi Murali, When rebasing for 2.6.34, I notcied that all the V4L2 stuff I was carrying in davinci git was merged upstream, except the patch V4L - vpfe_capture - bug fixes and enhancements This is currently still in davinci git, in the 'davinci-upstream-accepted' branch[1]. If this is still needed, please (re)submit to V4L2 and have it merged in the .34-rc cycle. Thanks, Kevin [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=shortlog;h=refs/heads/davinci-upstream-accepted ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 2/2 v2] spi: modify davinci platform data for updated driver
These changes update the davinci platform data to match the modifications
that were done to the davinci spi controller driver. The driver update
allowed per-device transfer settings, which are provided by this patch.
Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com
---
arch/arm/mach-davinci/board-dm355-evm.c | 10 ++
arch/arm/mach-davinci/board-dm355-leopard.c | 10 ++
arch/arm/mach-davinci/board-dm365-evm.c | 10 ++
arch/arm/mach-davinci/board-dm646x-evm.c| 12
arch/arm/mach-davinci/dm355.c |7 ---
arch/arm/mach-davinci/dm365.c |7 ---
arch/arm/mach-davinci/dm646x.c |7 ---
7 files changed, 42 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm355-evm.c
b/arch/arm/mach-davinci/board-dm355-evm.c
index a0724fa..b1a21a4 100644
--- a/arch/arm/mach-davinci/board-dm355-evm.c
+++ b/arch/arm/mach-davinci/board-dm355-evm.c
@@ -40,6 +40,7 @@
#include mach/serial.h
#include mach/nand.h
#include mach/mmc.h
+#include mach/spi.h
#define DAVINCI_ASYNC_EMIF_CONTROL_BASE0x01e1
#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x0200
@@ -445,10 +446,19 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = 0,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 1,
+};
+
static struct spi_board_info dm355_evm_spi_info[] __initconst = {
{
.modalias = at25,
.platform_data = at25640a,
+ .controller_data = at25640a_spi_cfg,
.max_speed_hz = 30 * 1000 * 1000, /* at 3v3 */
.bus_num= 0,
.chip_select= 0,
diff --git a/arch/arm/mach-davinci/board-dm355-leopard.c
b/arch/arm/mach-davinci/board-dm355-leopard.c
index 84ad5d1..d87ff0b 100644
--- a/arch/arm/mach-davinci/board-dm355-leopard.c
+++ b/arch/arm/mach-davinci/board-dm355-leopard.c
@@ -36,6 +36,7 @@
#include mach/serial.h
#include mach/nand.h
#include mach/mmc.h
+#include mach/spi.h
#define DAVINCI_ASYNC_EMIF_CONTROL_BASE0x01e1
#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE 0x0200
@@ -232,10 +233,19 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = 0,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 1,
+};
+
static struct spi_board_info dm355_leopard_spi_info[] __initconst = {
{
.modalias = at25,
.platform_data = at25640a,
+ .controller_data = at25640a_spi_cfg,
.max_speed_hz = 10 * 1000 * 1000, /* at 3v3 */
.bus_num= 0,
.chip_select= 0,
diff --git a/arch/arm/mach-davinci/board-dm365-evm.c
b/arch/arm/mach-davinci/board-dm365-evm.c
index ab3b0e2..8559c84 100644
--- a/arch/arm/mach-davinci/board-dm365-evm.c
+++ b/arch/arm/mach-davinci/board-dm365-evm.c
@@ -44,6 +44,7 @@
#include mach/nand.h
#include mach/keyscan.h
#include mach/gpio.h
+#include mach/spi.h
#include linux/videodev2.h
#include media/tvp514x.h
#include media/tvp7002.h
@@ -832,10 +833,19 @@ static struct spi_eeprom at25640 = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640_spi_cfg = {
+ .parity_enable = 0,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 1,
+};
+
static struct spi_board_info dm365_evm_spi_info[] __initconst = {
{
.modalias = at25,
.platform_data = at25640,
+ .controller_data = at25640_spi_cfg,
.max_speed_hz = 20 * 1000 * 1000, /* at 3v3 */
.bus_num= 0,
.chip_select= 0,
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 94271a6..5430b00 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -58,6 +58,7 @@
#include mach/nand.h
#include mach/mmc.h
#include mach/emac.h
+#include mach/spi.h
#include mach/clock.h
#include clock.h
@@ -911,10 +912,21 @@ static struct spi_eeprom at25640a = {
.flags = EE_ADDR2,
};
+static struct davinci_spi_config at25640a_spi_cfg = {
+ .parity_enable = 0,
+ .intr_level = 0,
+ .io_type= SPI_IO_TYPE_DMA,
+ .wdelay = 0,
+ .timer_disable = 0,
+ .c2t_delay = 8,
+ .t2c_delay = 8,
+};
+
static struct spi_board_info dm646x_evm_spi_info[] __initconst = {
{
.modalias = at25,
[PATCH 1/2 v2] spi: overhaul davinci spi driver to correct multiple errors
This patch is a significant overhaul of the davinci spi controller driver
that corrects multiple errors:
- Eliminate a race condition that exists for slow SPI devices
- Fix DMA transfer length error
- Fix limitations preventing multiple SPI devices on the same controller
Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com
---
arch/arm/mach-davinci/include/mach/spi.h | 30 +-
drivers/spi/davinci_spi.c| 990 --
drivers/spi/davinci_spi.h| 53 +-
3 files changed, 437 insertions(+), 636 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/spi.h
b/arch/arm/mach-davinci/include/mach/spi.h
index 7b54926..10c39d8 100644
--- a/arch/arm/mach-davinci/include/mach/spi.h
+++ b/arch/arm/mach-davinci/include/mach/spi.h
@@ -34,18 +34,24 @@ enum {
struct davinci_spi_platform_data {
u8 version;
u16 num_chipselect;
- u32 wdelay;
- u32 odd_parity;
- u32 parity_enable;
- u32 wait_enable;
- u32 timer_disable;
- u32 clk_internal;
- u32 cs_hold;
- u32 intr_level;
- u32 poll_mode;
- u32 use_dma;
- u8 c2tdelay;
- u8 t2cdelay;
+ u8 *chip_sel;
+};
+
+struct davinci_spi_config {
+ u32 odd_parity:1;
+ u32 parity_enable:1;
+ u32 intr_level:1;
+ u32 io_type:2;
+#define SPI_IO_TYPE_INTR0
+#define SPI_IO_TYPE_POLL1
+#define SPI_IO_TYPE_DMA 2
+ u32 bytes_per_word:2;
+ u32 wdelay:6;
+ u32 timer_disable:1;
+ u8 c2t_delay;
+ u8 t2c_delay;
+ u8 t2e_delay;
+ u8 c2e_delay;
};
#endif /* __ARCH_ARM_DAVINCI_SPI_H */
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 956f617..0bed840 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2009 Texas Instruments.
+ * Copyright (C) 2010 EF Johnson Technologies
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -33,43 +34,45 @@
#include davinci_spi.h
-static unsigned use_dma;
-
#defineDAVINCI_SPI_NO_RESOURCE ((resource_size_t)-1)
static void davinci_spi_rx_buf_u8(u32 data, struct davinci_spi *davinci_spi)
{
- u8 *rx = davinci_spi-rx;
-
- *rx++ = (u8)data;
- davinci_spi-rx = rx;
+ if (davinci_spi-rx) {
+ u8 *rx = davinci_spi-rx;
+ *rx++ = (u8)data;
+ davinci_spi-rx = rx;
+ }
}
static void davinci_spi_rx_buf_u16(u32 data, struct davinci_spi *davinci_spi)
{
- u16 *rx = davinci_spi-rx;
-
- *rx++ = (u16)data;
- davinci_spi-rx = rx;
+ if (davinci_spi-rx) {
+ u16 *rx = davinci_spi-rx;
+ *rx++ = (u16)data;
+ davinci_spi-rx = rx;
+ }
}
static u32 davinci_spi_tx_buf_u8(struct davinci_spi *davinci_spi)
{
- u32 data;
- const u8 *tx = davinci_spi-tx;
-
- data = *tx++;
- davinci_spi-tx = tx;
+ u32 data = 0;
+ if (davinci_spi-tx) {
+ const u8 *tx = davinci_spi-tx;
+ data = *tx++;
+ davinci_spi-tx = tx;
+ }
return data;
}
static u32 davinci_spi_tx_buf_u16(struct davinci_spi *davinci_spi)
{
- u32 data;
- const u16 *tx = davinci_spi-tx;
-
- data = *tx++;
- davinci_spi-tx = tx;
+ u32 data = 0;
+ if (davinci_spi-tx) {
+ const u16 *tx = davinci_spi-tx;
+ data = *tx++;
+ davinci_spi-tx = tx;
+ }
return data;
}
@@ -89,26 +92,6 @@ static inline void clear_io_bits(void __iomem *addr, u32
bits)
iowrite32(v, addr);
}
-static inline void set_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
-{
- set_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
-}
-
-static inline void clear_fmt_bits(void __iomem *addr, u32 bits, int cs_num)
-{
- clear_io_bits(addr + SPIFMT0 + (0x4 * cs_num), bits);
-}
-
-static void davinci_spi_set_dma_req(const struct spi_device *spi, int enable)
-{
- struct davinci_spi *davinci_spi = spi_master_get_devdata(spi-master);
-
- if (enable)
- set_io_bits(davinci_spi-base + SPIINT, SPIINT_DMA_REQ_EN);
- else
- clear_io_bits(davinci_spi-base + SPIINT, SPIINT_DMA_REQ_EN);
-}
-
/*
* Interface to control the chip select signal
*/
@@ -116,25 +99,54 @@ static void davinci_spi_chipselect(struct spi_device *spi,
int value)
{
struct davinci_spi *davinci_spi;
struct davinci_spi_platform_data *pdata;
- u32 data1_reg_val = 0;
+ u8 i, chip_sel = spi-chip_select;
+ u32 spidat1;
+ u16 spidat1_cfg;
davinci_spi = spi_master_get_devdata(spi-master);
pdata = davinci_spi-pdata;
- /*
-*
RE: [PATCH 0/2] overhaul davinci spi driver to fix multiple errors
Sorry, the last version had a bunch of whitespace problems. I will resubmit the patch shortly. ___ 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/2 v2] davinci: da830/omap-l137 evm: add support for GPIO based MMC/SD card detection
Sekhar Nori nsek...@ti.com writes:
From: Vipin Bhandari vipin.bhand...@ti.com
The DA830/OMAP-L137 EVM has GPIO based card detection logic, but the current
code does not use it.
Add support for GPIO based card detection to avoid reading the card to see
if a card is present or not.
Signed-off-by: Vipin Bhandari vipin.bhand...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
This is a replacement for patch submitted by Vipin earlier.
http://patchwork.kernel.org/patch/6/
The patch has been split into two and the description updated.
Thanks, applying both, and queuing in davinci-next for 2.6.35.
Kevin
arch/arm/mach-davinci/board-da830-evm.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index dc19870..8e67037 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -229,14 +229,21 @@ static const short da830_evm_mmc_sd_pins[] = {
};
#define DA830_MMCSD_WP_PIN GPIO_TO_PIN(2, 1)
+#define DA830_MMCSD_CD_PIN GPIO_TO_PIN(2, 2)
static int da830_evm_mmc_get_ro(int index)
{
return gpio_get_value(DA830_MMCSD_WP_PIN);
}
+static int da830_evm_mmc_get_cd(int index)
+{
+ return !gpio_get_value(DA830_MMCSD_CD_PIN);
+}
+
static struct davinci_mmc_config da830_evm_mmc_config = {
.get_ro = da830_evm_mmc_get_ro,
+ .get_cd = da830_evm_mmc_get_cd,
.wires = 4,
.max_freq = 5000,
.caps = MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED,
@@ -262,6 +269,14 @@ static inline void da830_evm_init_mmc(void)
}
gpio_direction_input(DA830_MMCSD_WP_PIN);
+ ret = gpio_request(DA830_MMCSD_CD_PIN, MMC CD\n);
+ if (ret) {
+ pr_warning(da830_evm_init: can not open GPIO %d\n,
+DA830_MMCSD_CD_PIN);
+ return;
+ }
+ gpio_direction_input(DA830_MMCSD_CD_PIN);
+
ret = da8xx_register_mmcsd0(da830_evm_mmc_config);
if (ret) {
pr_warning(da830_evm_init: mmc/sd registration failed: %d\n,
--
1.6.2.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
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/2] TI DaVinci EMAC: Add EMAC PHY clock handling.
Sriramakrishnan s...@ti.com writes:
Source for the EMAC PHY clock can be different from the
module clock and driver needs to request/enable the EMAC
phy clock explicitly. This was not required earlier as on
most Davinci platforms the phy clock is always on . On AM35x
platform the phy clock needs to be managed explicitly , hence
adding clock management for phy clock.
Signed-off-by: Sriramakrishnan s...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
Dave, if you prefer, with your ack, I'll merge this via the davinci
tree along with corresponding platform changes.
Kevin
---
drivers/net/davinci_emac.c | 22 --
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 8a42dbe..d9ae6ee 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -491,6 +491,7 @@ struct emac_priv {
/* clock frequency for EMAC */
static struct clk *emac_clk;
+static struct clk *emac_phy_clk;
static unsigned long emac_bus_frequency;
static unsigned long mdio_max_freq;
@@ -2637,18 +2638,28 @@ static int __devinit davinci_emac_probe(struct
platform_device *pdev)
struct emac_platform_data *pdata;
struct device *emac_dev;
- /* obtain emac clock from kernel */
- emac_clk = clk_get(pdev-dev, NULL);
+ /* obtain emac module clock from kernel */
+ emac_clk = clk_get(pdev-dev, emac_clk);
if (IS_ERR(emac_clk)) {
printk(KERN_ERR DaVinci EMAC: Failed to get EMAC clock\n);
return -EBUSY;
}
+
+ /* obtain emac phy clock from kernel */
+ emac_phy_clk = clk_get(pdev-dev, phy_clk);
+ if (IS_ERR(emac_phy_clk)) {
+ printk(KERN_ERR DaVinci EMAC: Failed to get PHY clock\n);
+ clk_put(emac_clk);
+ return -EBUSY;
+ }
+
emac_bus_frequency = clk_get_rate(emac_clk);
/* TODO: Probe PHY here if possible */
ndev = alloc_etherdev(sizeof(struct emac_priv));
if (!ndev) {
printk(KERN_ERR DaVinci EMAC: Error allocating net_device\n);
+ clk_put(emac_phy_clk);
clk_put(emac_clk);
return -ENOMEM;
}
@@ -2734,6 +2745,7 @@ static int __devinit davinci_emac_probe(struct
platform_device *pdev)
netif_napi_add(ndev, priv-napi, emac_poll, EMAC_POLL_WEIGHT);
clk_enable(emac_clk);
+ clk_enable(emac_phy_clk);
/* register the network device */
SET_NETDEV_DEV(ndev, pdev-dev);
@@ -2783,6 +2795,7 @@ mdiobus_quit:
netdev_reg_err:
mdio_alloc_err:
+ clk_disable(emac_phy_clk);
clk_disable(emac_clk);
no_irq_res:
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -2790,6 +2803,7 @@ no_irq_res:
iounmap(priv-remap_addr);
probe_quit:
+ clk_put(emac_phy_clk);
clk_put(emac_clk);
free_netdev(ndev);
return rc;
@@ -2821,7 +2835,9 @@ static int __devexit davinci_emac_remove(struct
platform_device *pdev)
free_netdev(ndev);
iounmap(priv-remap_addr);
+ clk_disable(emac_phy_clk);
clk_disable(emac_clk);
+ clk_put(emac_phy_clk);
clk_put(emac_clk);
return 0;
@@ -2835,6 +2851,7 @@ static int davinci_emac_suspend(struct device *dev)
if (netif_running(ndev))
emac_dev_stop(ndev);
+ clk_disable(emac_phy_clk);
clk_disable(emac_clk);
return 0;
@@ -2846,6 +2863,7 @@ static int davinci_emac_resume(struct device *dev)
struct net_device *ndev = platform_get_drvdata(pdev);
clk_enable(emac_clk);
+ clk_enable(emac_phy_clk);
if (netif_running(ndev))
emac_dev_open(ndev);
--
1.6.2.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
___
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 2/2] davinci: introduce EMAC PHY clock usage
Sriramakrishnan s...@ti.com writes:
From: Sekhar Nori nsek...@ti.com
The patch TI DaVinci EMAC: Add EMAC PHY clock handling adds
support for enabling and disabling the EMAC PHY clock.
The PHY clock on all DaVinci boards is derived from a fixed
on board clock. This patch adds the PHY clock definition to
the clock tree for all the DaVinci boards using EMAC. Also,
the existing input to EMAC module is differentiated from the
PHY clock using the clock name emac_clk.
Without this patch ethernet fails to initialize since it cannot
get the PHY clock and EMAC clock.
Tested on EVM boards for DM365, DM6467, DM644x, DA830 and DA850.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
Though i have made changes for Neuros OSD2 and SFFSDR boards, i
do not have the hardware to test. Appreciate if folks having this
hardware ack the patch.
arch/arm/mach-davinci/board-da830-evm.c | 19 +++
arch/arm/mach-davinci/board-da850-evm.c | 21 +
arch/arm/mach-davinci/board-dm365-evm.c | 18 ++
arch/arm/mach-davinci/board-dm644x-evm.c | 18 ++
arch/arm/mach-davinci/board-dm646x-evm.c | 15 +++
arch/arm/mach-davinci/board-neuros-osd2.c | 19 +++
arch/arm/mach-davinci/board-sffsdr.c | 19 +++
arch/arm/mach-davinci/da830.c |2 +-
arch/arm/mach-davinci/da850.c |2 +-
arch/arm/mach-davinci/dm365.c |2 +-
arch/arm/mach-davinci/dm644x.c|2 +-
arch/arm/mach-davinci/dm646x.c|2 +-
12 files changed, 134 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index dc19870..54e8567 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -20,9 +20,11 @@
#include linux/i2c/at24.h
#include linux/mtd/mtd.h
#include linux/mtd/partitions.h
+#include linux/clk.h
#include asm/mach-types.h
#include asm/mach/arch.h
+#include mach/clock.h
#include mach/cp_intc.h
#include mach/mux.h
@@ -30,6 +32,8 @@
#include mach/da8xx.h
#include mach/usb.h
+#include clock.h
+
#define DA830_EVM_PHY_MASK 0x0
#define DA830_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */
@@ -557,9 +561,24 @@ static __init void da830_evm_irq_init(void)
soc_info-intc_irq_prios);
}
+#define EMAC_PHY_CLK_RATE5000
+
+static struct clk emac_phy = {
+ .name = emac_phy,
+ .rate = EMAC_PHY_CLK_RATE,
+};
+
+static struct clk_lookup emac_phy_clks[] = {
+ CLK(davinci_emac.1, phy_clk, emac_phy),
Just make it phy instead of phy_clk. The con_id field is just
a handle to differentiate between multiple clocks per device.
The same for the emac_clk change. I'd call that one main (or emac
if you prefer.) Doing this change will require an update do PATCH 1/2
as well.
+ CLK(NULL, NULL, NULL),
+};
+
I'm not crazy about the clock definitions in the board files. I
assume you put it here instead of soc.c is because each clock
has a board specific rate.
Instead, what I'd rather see is the clock defined once for each
soc.c with a custom set_rate hook. The default rate could
be a per-SoC default (25MHz looks common) and any board files
that don't use the default can use clk_set_rate() to change it.
This approach should simplfy things and minimize changes to board
files.
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: VPFE fixes and enhancments patch
Kevin, You can drop it. I had some comments against it from V4L and I had to drop it from upstream merge. 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: Friday, March 12, 2010 1:35 PM To: Karicheri, Muralidharan Cc: davinci-linux-open-source@linux.davincidsp.com Subject: VPFE fixes and enhancments patch Hi Murali, When rebasing for 2.6.34, I notcied that all the V4L2 stuff I was carrying in davinci git was merged upstream, except the patch V4L - vpfe_capture - bug fixes and enhancements This is currently still in davinci git, in the 'davinci-upstream-accepted' branch[1]. If this is still needed, please (re)submit to V4L2 and have it merged in the .34-rc cycle. Thanks, Kevin [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux- davinci.git;a=shortlog;h=refs/heads/davinci-upstream-accepted ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: adv7180 support
Raffaele, The vpfe_capture driver on DM365 is merged to upsteam kernel 2.6.34.rc1 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/media/video/davinci;h=2cb15a21e472caad918ec789253b8f309c99845d;hb=522dba7134d6b2e5821d3457f7941ec34f668e6d I suggest you work with this version (using linux-davinci tree from Kevin) and submit patches. Looking at the data sheet, this peripheral is similar to tvp5146. Currently we support capture from TVP5146 using vpfe_capture in the linux-davinci tree on DM365. It uses BT.656 interface to capture from TVP5146. So integrating ADV7180 would be easy IMO. Let me know if you have any questions on vpfe capture. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 phone: 301-407-9583 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 Raffaele Recalcati Sent: Friday, March 12, 2010 1:54 AM To: Nori, Sekhar Cc: davinci-linux-open-source Subject: Re: adv7180 support 2010/3/12 Nori, Sekhar nsek...@ti.commailto:nsek...@ti.com Hello Raffaele, On Thu, Mar 11, 2010 at 21:44:58, Raffaele Recalcati wrote: We are starting developing adv7180 support compliant to arago tree. I hope it is a good idea, and when khilman tree will be the possible davinci standard tree we'll move to it changing adv7180 support. Any suggestion is welcome. Note that patches are not accepted against arago tree. It is only a TI development tree. You can use it for testing, but the patch you submit should be against the tree V4L2 maintainer mandates. Typically only arch/arm/mach-davinci/* changes are merged through Kevin's tree. I was writing now about adv7180 replying to Hilman. So the right thing is moving my development to Kevin branch. I'd like to be as near as possible to the mainline, by now. Any idea about evm-dm365 peripheral tests? Thanks, Sekhar -- www.opensurf.ithttp://www.opensurf.it ___ 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 3/4] OMAP3 : clock data: Update name string for EMAC clocks.
Sriramakrishnan s...@ti.com writes:
The emac driver uses generic name for the module and phy
clocks. Updated the omap3xxx_clks table to match the names
used by the Davinci emac driver.
Signed-off-by: Sriramakrishnan s...@ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index d5153b6..989da2e 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3472,8 +3472,8 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, ipss_ick, ipss_ick, CK_AM35XX),
CLK(NULL, rmii_ck, rmii_ck, CK_AM35XX),
CLK(NULL, pclk_ck, pclk_ck, CK_AM35XX),
- CLK(davinci_emac, ick, emac_ick, CK_AM35XX),
- CLK(davinci_emac, fck, emac_fck, CK_AM35XX),
+ CLK(davinci_emac, emac_clk, emac_ick, CK_AM35XX),
+ CLK(davinci_emac, phy_clk, emac_fck, CK_AM35XX),
As I mentioned in the review of the equivalent davinci changes,
I'm not crazy abou the _clk suffixes on the con_id. I think
these should be called main (or emac) and phy.
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] TI DaVinci EMAC: Convert to dev_pm_ops
Chaithrika U S chaithr...@ti.com writes: Migrate from the legacy PM hooks to use dev_pm_ops structure. Signed-off-by: Chaithrika U S chaithr...@ti.com Acked-by: Kevin Hilman khil...@deeprootsystems.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: davinci git updated to v2.6.34-rc1
Raffaele Recalcati lamiapost...@gmail.com writes: 2010/3/12 Kevin Hilman khil...@deeprootsystems.com FYI... Davinci git has now been updated to v2.6.34-rc1. With this release, we have dramatically reduced the gap between davinci git and mainline with lots of stuff making it in for 2.6.34. Nice work! Nice! I need anyway more explanations. I see you are talking about: http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git and not: http://arago-project.org/git/projects/linux-davinci.git Correct. As pointed out elsewhere, the arago tree is a TI development tree and includes several things that are not ready for upstream or work in progress etc. So, the best thing for me should be to move exactly now to it for testing input video with adv7180 on dm365? Yes. Maybe I spend more time at this moment, but if it is the right thing I will spend less time in the future rebasing my code from arago old tree. The right thing is to do your development and submit your patches as close to mainline as possible. If you have dependencies on other features that are not upstream, you might have to merge from arago, but patches should always be submitted against mainline (or davinci git, which track closely with mainline) Any out of tree dependencies should be stated in the patch changelog. 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: VPFE fixes and enhancments patch
Karicheri, Muralidharan m-kariche...@ti.com writes: You can drop it. I had some comments against it from V4L and I had to drop it from upstream merge. Thanks for the update. Will drop. 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 1/4] TI DaVinci: Adding header file for SPI support.
s-paul...@ti.com writes: From: Sandeep Paulraj s-paul...@ti.com This patch adds spi.h header file that will be used by board and architecture specific code. Signed-off-by: Sandeep Paulraj s-paul...@ti.com Looks like I never replied to this, but this series was merged into 2.6.34, in case you hadn't noticed already. 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: DM3xx: UART transmit delays
Brian Murphy br...@murphy.dk writes: On Mon, Feb 15, 2010 at 10:07 PM, Bansal, Prateek pban...@ti.com wrote: Hi Brian, Thanks for sharing the patch. We tested this on 2.6.32 kernel on DM355 device and it worked fine however we are yet to get this working with 2.6.30 kernel. One of the things that we are trying to investigate is why the transmit FIFO empty interrupts are not generated. If you have more visibility into this, I would appreciate any details. Considering we see this issue across number of devices OMAP-L137, DM6446 and DM355, it points to a software issue rather than hardware one but needs to be confirmed. I have it working with several kernels, It needed a little massaging to work with the latest as someone else was playing in the same place as me :). The issue the patch fixes is a hardware issue. The UART in the TI SOC devices does not have the same behaviour as a 16550 uart and the linux kernel driver requires that behaviour to function efficiently. The workaround in the current kernel driver is not good and hides the problem in a very bad way. I will try again next week to get a discusion going on the linux-serial list. It seems like Alan Cox is still active despite threats to the contary so I may send directly to him to see if that helps. [sorry to jump in late on this thread...] Unfortunately, last time I checked, the 8250 driver was orphaned (no maintainer.) And since there are 8250 UARTs on *tons* of devices out there, folks are reluctant to do significant changes without lots of testing. I suggest in your repost of this patch to be also list the devices that you (or others) have validated it on. That always helps. You might also request others do do some testing on their platforms as well. 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 1/2 v2] spi: overhaul davinci spi driver to correct multiple errors
Brian Niebuhr bniebu...@gmail.com writes: This patch is a significant overhaul of the davinci spi controller driver that corrects multiple errors: - Eliminate a race condition that exists for slow SPI devices - Fix DMA transfer length error - Fix limitations preventing multiple SPI devices on the same controller Signed-off-by: Brian Niebuhr bnieb...@efjohnson.com The verbose description of the issues addressed from PATCH 0/2 should go here is well so it makes it into the permanent git history. That being said, I think for the sake of reviewing, you're going to need to break this up into reviewable pieces, each having a verbose description of the issues being solved. There is also a mixture of fixes, enhancements, renames etc. These should be done as separate patches. I know that it's more work to break it up like this, but that's the only way to make a large change like this reviewable by others. Thanks, 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: Custom pinmuxing on DM355 with git kernel
On Fri, Mar 12, 2010 at 5:18 PM, Kevin Hilman khil...@deeprootsystems.comwrote: Nori, Sekhar nsek...@ti.com writes: On Thu, Mar 11, 2010 at 11:45:47, Jon Povey wrote: Steve Chen wrote: On Wed, Mar 10, 2010 at 12:49 AM, Jon Povey jon.po...@racelogic.co.uk wrote: We have 3 different boards using DM355, with different gpio / pinmux setups. So far, our device drivers are modules which fiddle the pinmux registers directly. At the moment I am thinking that I might want to split up davinci_cfg_reg into two functions so it's not hardwired to soc_info-pinmux_pins, and I could pass my own mux_config structs in. If this is of interest I can have a go at doing this and submitting the patch here. For board specific pinmux, you can put them in board-dm355-*.c. There are some board specific pinmux setup in board-da830-evm.c. Look for da8xx_pinmux_setup. Thanks, I see this. I have also been looking at the gpiolib support and something like that would be useful. At minimum it would be helpful to split out the davinci_cfg_reg stuff as described above so that driver modules can use the same functions. Methods of handing pinmux were debated at length on this list. I think this thread captures most of it: http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg11281.html It's a long thread, but very useful read. I don't think having drivers handle pinmux directly is acceptable at all. Correct. Drivers should not do muxing. This should be done by SoC or board init code. If your bootloader is doing it, that suggests that it is init-time only, and should be done in init code. Would it be possible to architect the pin-mux logic to accept boot arguments to configure the SoC devices wanted? We are struggling with porting a kernel to a davinci based System-on-Module type board that would allow end users to select what interfaces (e.g., UARTS vs. SPI ports) to use on these devices. Having a pile of custom machines (kernel configurations) for every permutation seems painful if all they are doing is enabling different devices. I sort of thought the point of modular kernel drivers was to provide pluggable support for dynamic device control. I appreciate that someone needs to keep track of the resources, but couldn't there be some sort of allocation mechanism to allow drivers to test and see if they can have a set of resources before using them, much like the gpiolib? -Mike ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: davinci git updated to v2.6.34-rc1
Nice! I need anyway more explanations. I see you are talking about: http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git and not: http://arago-project.org/git/projects/linux-davinci.git Correct. thx As pointed out elsewhere, the arago tree is a TI development tree and includes several things that are not ready for upstream or work in progress etc. ok So, the best thing for me should be to move exactly now to it for testing input video with adv7180 on dm365? Yes. Maybe I spend more time at this moment, but if it is the right thing I will spend less time in the future rebasing my code from arago old tree. The right thing is to do your development and submit your patches as close to mainline as possible. If you have dependencies on other features that are not upstream, you might have to merge from arago, but patches should always be submitted against mainline (or davinci git, which track closely with mainline) Any out of tree dependencies should be stated in the patch changelog. ok, I'm doing like that Kevin Raffaele ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
