RE: Custom pinmuxing on DM355 with git kernel
Nori, Sekhar wrote: On Mon, Mar 15, 2010 at 07:47:44, Jon Povey wrote: - Board init would setup pinmuxing resource structures that could be passed to drivers, something like gpio, but supporting the different DaVinci devices (insert handwaving here) - Device driver can callback to request / release its mux resources - mux layer can print/warn/bug for debug if claimed resources conflict Aplogies if this is all very wrongheaded. I am still getting to grips with the provided APIs, attempting to specify a new one is a stretch. As far as possible, the interfaces to device drivers should not be SoC specific ones, but should be portable across platforms and architectures. So, what you are proposing needs to be an interface defined in include/linux/* and cannot be DaVinci specific. The problem is there is no cross-platform framework for handling pin as a resource defined yet. Currently, every platform that runs into this solves it in its own way. Have a look at this post from the thread I posted earlier.. http://www.mail-archive.com/davinci-linux-open-sou...@linux.davincidsp.c om/msg11301.html .. and the response from Dave Brownell to that. http://www.mail-archive.com/davinci-linux-open-sou...@linux.davincidsp.c om/msg11303.html Thanks for those useful archive links. How about a generic interface which included claim/free resource methods, like for gpio, but taking a pointer to a mux resource struct instead of a gpio number. The mux resource struct would include function pointers to mach- or soc- specific functions to do the work of checking, setting and freeing the mux resources. The mux resource struct would also contain a list of mach- or soc- specific resource data required by that device (pointers into an array of mux resource structs or whatever?) The mux resources would be setup and passed by the board init to the driver. The driver could claim and release them using the platform-independent functions. The platform-independent functions could just be wrappers calling the mach-specific functions, or do more elaborate generic things (sysfs stuff, printing/handling conflicts) I appreciate this is fairly simpleminded and doesn't handle, for example, large peripherals that you may not want to mux all of the pins for (I'm thinking DM355 VPFE, we reuse the sync pins for example). Obviously I am handwaving all implementation details. Just trying to get a grip on the theory and appreciate all experienced criticism. -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ 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
Nori, Sekhar wrote: On Mon, Mar 15, 2010 at 07:54:57, Jon Povey wrote: I did a bit of wiki-work this morning, improvements encouraged to http://wiki.davincidsp.com/index.php/Linux_Toolchain#Linux_Kernel Hmm, did not realize this is documented here so far. Thanks! The details look pretty complete to me. What would you would like to see added there? I just meant, I wrote it up to the best of my ability, but TI folks / Kevin / others may have a better idea of the differences between the available kernels. If my understanding is good, great! Information on submitting patches upstream is documented here: http://wiki.davincidsp.com/index.php/Patch_upstream_sending Ah, I wasn't aware of that page. There seem to be a lot of hidden gems (and hidden crusy old junk) hiding in the wiki. Note that this is a public wiki, so modifications can be made by anyone in the community (not just TI folks). Yup.. I just linked the upstream patches page from that kernels section :) -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Problem with DMsoc voice codec on Dm365
Hi, I want to use the M1(mic) on DM365 EVM as sound input. I modified the demo application to read data from MIC (M1) and write it to a file by commenting the encode call and its working fine. But when I modified and run the encode application to use new sound device with the command ./encode -s test.g711, it could not encode and giving following errors: *Error: Failed to encode speech buffer (Demo application prints)* *SPHENC1_process() failed with error (-1 ext: 0xa) (Print kept in DMAI source code) *If I use the default kernel and the default sound device to run the encode application, it will run well. Can anyone tell me what is going wrong with the encoding in case of M1(mic)? Regards, Krunal Patil -- _ Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. _ ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] Davinci SDIO Support
From: Alagu Sankar alagusan...@embwise.com
Added SDIO Support for Davinci Platforms. This is tested with DM355 and DM365
EVM platforms using Libertas driver with SD8686 and SD8688 SDIO WiFi cards.
There is a hack to support Libertas firmware download. This hack may not be
required for other SDIO cards.
Signed-off-by: alagusan...@embwise.com
---
drivers/mmc/host/davinci_mmc.c | 131
1 files changed, 120 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 933cd42..2836ad1 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -32,6 +32,7 @@
#include linux/delay.h
#include linux/dma-mapping.h
#include linux/mmc/mmc.h
+#include linux/mmc/card.h
#include mach/mmc.h
#include mach/edma.h
@@ -66,8 +67,8 @@
#define DAVINCI_MMCBLNC 0x60
#define DAVINCI_SDIOCTL 0x64
#define DAVINCI_SDIOST0 0x68
-#define DAVINCI_SDIOEN 0x6C
-#define DAVINCI_SDIOST 0x70
+#define DAVINCI_SDIOIEN 0x6C
+#define DAVINCI_SDIOIST 0x70
#define DAVINCI_MMCFIFOCTL 0x74 /* FIFO Control Register */
/* DAVINCI_MMCCTL definitions */
@@ -135,6 +136,23 @@
/* MMCSD Init clock in Hz in opendrain mode */
#define MMCSD_INIT_CLOCK 20
+/* DAVINCI_SDIOCTL definitions */
+#define SDIOCTL_RDWTRQ_SETBIT(0)
+#define SDIOCTL_RDWTCR_SETBIT(1)
+
+/* DAVINCI_SDIOST0 definitions */
+#define SDIOST0_DAT1_HI BIT(0)
+#define SDIOST0_INTPRDBIT(1)
+#define SDIOST0_RDWTSTBIT(2)
+
+/* DAVINCI_SDIOIEN definitions */
+#define SDIOIEN_IOINTEN BIT(0)
+#define SDIOIEN_RWSEN BIT(1)
+
+/* DAVINCI_SDIOIST definitions */
+#define SDIOIST_IOINT BIT(0)
+#define SDIOIST_RWS BIT(1)
+
/*
* 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
@@ -147,6 +165,8 @@
#define NR_SG 16
+#define DAVINCI_SDIO_IRQ(dev_id) (((dev_id) == 0) ? sdio0 : sdio1)
+
static unsigned rw_threshold = 32;
module_param(rw_threshold, uint, S_IRUGO);
MODULE_PARM_DESC(rw_threshold,
@@ -164,7 +184,7 @@ struct mmc_davinci_host {
unsigned int mmc_input_clk;
void __iomem *base;
struct resource *mem_res;
- int irq;
+ int mmc_irq, sdio_irq;
unsigned char bus_mode;
#define DAVINCI_MMC_DATADIR_NONE 0
@@ -184,6 +204,7 @@ struct mmc_davinci_host {
u32 rxdma, txdma;
bool use_dma;
bool do_dma;
+ bool sdio_int;
/* Scatterlist DMA uses one or more parameter RAM entries:
* the main one (associated with rxdma or txdma) plus zero or
@@ -670,6 +691,24 @@ mmc_davinci_prepare_data(struct mmc_davinci_host *host,
struct mmc_request *req)
host-buffer = NULL;
host-bytes_left = data-blocks * data-blksz;
+/*
+ * Hack for overcoming the 2ms delay required by Libertas helper
+ * firmware download. Without this delay the primary firmware load fails
+ * without an error. Not having the delay does not result in host
+ * controller error (or) helper firmware download error. But will result
+ * in primary firmware load error.
+ *
+ * May not be required for usage with other SDIO client drivers and
+ * should be removed after identifying the root cause in consultation
+ * with the libertas developers.
+ */
+ if (host-mmc-card) {
+ if (mmc_card_sdio(host-mmc-card)) {
+ if ((data-blksz == 64))
+ mdelay(2);
+ }
+ }
+
/* For now we try to use DMA whenever we won't need partial FIFO
* reads or writes, either for the whole transfer (as tested here)
* or for any individual scatterlist segment (tested when we call
@@ -862,6 +901,19 @@ mmc_davinci_xfer_done(struct mmc_davinci_host *host,
struct mmc_data *data)
{
host-data = NULL;
+ if (host-mmc-caps MMC_CAP_SDIO_IRQ) {
+ /* SDIO Interrupt Detection work-around as suggested by
+* Davinci Errata (TMS320DM355 Silicon Revision 1.1 Errata
+* 2.1.5)
+* Signal SDIO interrupt only if it is enabled by core
+*/
+ if (host-sdio_int (!((readl(host-base + DAVINCI_SDIOST0))
+SDIOST0_DAT1_HI))) {
+ writel(SDIOIST_IOINT, host-base + DAVINCI_SDIOIST);
+ mmc_signal_sdio_irq(host-mmc);
+ }
+ }
+
if (host-do_dma) {
davinci_abort_dma(host);
@@ -928,6 +980,22 @@ davinci_abort_data(struct mmc_davinci_host *host, struct
mmc_data *data)
mmc_davinci_reset_ctrl(host, 0);
}
+static irqreturn_t mmc_davinci_sdio_irq(int irq, void *dev_id)
+{
+ struct mmc_davinci_host *host = (struct mmc_davinci_host
[PATCH v3 2/3] davinci: da8xx/omapl EVM: Specify reserved channels/slots
From: Rajashekhara, Sudhakar sudhakar@ti.com
The drivers on da8xx/omapl EVMs do not utilize all the channels
and slots provided by EDMA. Some of these are better utilitzed by
the DSP on the SoC for speeding up codec operations.
Reserve these channels/slots for the DSP.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
Since v2, the channel/slot reservation has been made board specific
instead of imposing it on all users. Also, the da830 and da850 changes
are now in a single patch since a lot of common code is touched.
Unfortunately it has been a long time since the patches were reviewed
last. Here is the relevant discussion thread:
http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg16506.html
arch/arm/mach-davinci/board-da830-evm.c| 25 +-
arch/arm/mach-davinci/board-da850-evm.c| 38 +++-
arch/arm/mach-davinci/devices-da8xx.c | 26 --
arch/arm/mach-davinci/include/mach/da8xx.h |4 ++-
4 files changed, 81 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index dc19870..90088af 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -482,12 +482,35 @@ static struct davinci_i2c_platform_data
da830_evm_i2c_0_pdata = {
.bus_delay = 0,/* usec */
};
+/*
+ * The following EDMA channels/slots are not being used by drivers (for
+ * example: Timer, GPIO, UART events etc) on da830/omap-l137 EVM, hence
+ * they are being reserved for codecs on the DSP side.
+ */
+static const s16 da830_dma_rsv_chans[][2] = {
+ /* (offset, number) */
+ { 8, 2},
+ {12, 2},
+ {24, 4},
+ {30, 2},
+ {-1, -1}
+};
+
+static const s16 da830_dma_rsv_slots[][2] = {
+ /* (offset, number) */
+ { 8, 2},
+ {12, 2},
+ {24, 4},
+ {30, 26},
+ {-1, -1}
+};
+
static __init void da830_evm_init(void)
{
struct davinci_soc_info *soc_info = davinci_soc_info;
int ret;
- ret = da8xx_register_edma();
+ ret = da830_register_edma(da830_dma_rsv_chans, da830_dma_rsv_slots);
if (ret)
pr_warning(da830_evm_init: edma registration failed: %d\n,
ret);
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 411284d..37f9714 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -612,6 +612,41 @@ static int __init da850_evm_config_emac(void)
}
device_initcall(da850_evm_config_emac);
+/*
+ * The following EDMA channels/slots are not being used by drivers (for
+ * example: Timer, GPIO, UART events etc) on da850/omap-l138 EVM, hence
+ * they are being reserved for codecs on the DSP side.
+ */
+static const s16 da850_dma0_rsv_chans[][2] = {
+ /* (offset, number) */
+ { 8, 6},
+ {24, 4},
+ {30, 2},
+ {-1, -1}
+};
+
+static const s16 da850_dma0_rsv_slots[][2] = {
+ /* (offset, number) */
+ { 8, 6},
+ {24, 4},
+ {30, 50},
+ {-1, -1}
+};
+
+static const s16 da850_dma1_rsv_chans[][2] = {
+ /* (offset, number) */
+ { 0, 28},
+ {30, 2},
+ {-1, -1}
+};
+
+static const s16 da850_dma1_rsv_slots[][2] = {
+ /* (offset, number) */
+ { 0, 28},
+ {30, 90},
+ {-1, -1}
+};
+
static __init void da850_evm_init(void)
{
int ret;
@@ -621,7 +656,8 @@ static __init void da850_evm_init(void)
pr_warning(da850_evm_init: TPS65070 PMIC init failed: %d\n,
ret);
- ret = da8xx_register_edma();
+ ret = da850_register_edma(da850_dma0_rsv_chans, da850_dma0_rsv_slots,
+ da850_dma1_rsv_chans, da850_dma1_rsv_slots);
if (ret)
pr_warning(da850_evm_init: edma registration failed: %d\n,
ret);
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index 0a96791..6e913f8 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -248,18 +248,26 @@ static struct platform_device da850_edma_device = {
.resource = da850_edma_resources,
};
-int __init da8xx_register_edma(void)
+int __init da830_register_edma(const s16 (*rsv_chans)[2],
+ const s16 (*rsv_slots)[2])
{
- struct platform_device *pdev;
+ da830_edma_info[0].rsv_chans = rsv_chans;
+ da830_edma_info[0].rsv_slots = rsv_slots;
- if (cpu_is_davinci_da830())
- pdev = da830_edma_device;
- else if (cpu_is_davinci_da850())
- pdev = da850_edma_device;
- else
- return -ENODEV;
+ return platform_device_register(da830_edma_device);
+}
- return
[PATCH v3 3/3] davinci: dm646x EVM: Specify reserved EDMA channel/slots
From: Rajashekhara, Sudhakar sudhakar@ti.com
Not all the channels and slots available on the DM646x EVM
are used by the devices on the EVM. These resources can be
used by the DSP to speed up codec operations.
This patch reserves these channels for the DSP.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
Since v2, the channel/slot reservation has been made board specific
instead of imposing it on all users.
Unfortunately it has been a long time since the patches were reviewed
last. Here is the relevant discussion thread:
http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg16506.html
arch/arm/mach-davinci/board-dm646x-evm.c| 28 +++
arch/arm/mach-davinci/dm646x.c | 10 -
arch/arm/mach-davinci/include/mach/dm646x.h |3 ++
3 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 5ba3cb2..ed47189 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -724,6 +724,32 @@ static struct davinci_uart_config uart_config __initdata =
{
#define DM646X_EVM_PHY_MASK(0x2)
#define DM646X_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
+/*
+ * The following EDMA channels/slots are not being used by drivers (for
+ * example: Timer, GPIO, UART events etc) on dm646x, hence they are being
+ * reserved for codecs on the DSP side.
+ */
+static const s16 dm646x_dma_rsv_chans[][2] = {
+ /* (offset, number) */
+ { 0, 4},
+ {13, 3},
+ {24, 4},
+ {30, 2},
+ {54, 3},
+ {-1, -1}
+};
+
+static const s16 dm646x_dma_rsv_slots[][2] = {
+ /* (offset, number) */
+ { 0, 4},
+ {13, 3},
+ {24, 4},
+ {30, 2},
+ {54, 3},
+ {128, 384},
+ {-1, -1}
+};
+
static __init void evm_init(void)
{
struct davinci_soc_info *soc_info = davinci_soc_info;
@@ -735,6 +761,8 @@ static __init void evm_init(void)
platform_device_register(davinci_nand_device);
+ dm646x_init_edma(dm646x_dma_rsv_chans, dm646x_dma_rsv_slots);
+
if (HAS_ATA)
dm646x_init_ide();
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 893baf4..33ae939 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -912,6 +912,15 @@ void dm646x_setup_vpif(struct vpif_display_config
*display_config,
platform_device_register(vpif_capture_dev);
}
+int __init dm646x_init_edma(const s16 (*rsv_chans)[2],
+ const s16 (*rsv_slots)[2])
+{
+ dm646x_edma_info[0].rsv_chans = rsv_chans;
+ dm646x_edma_info[0].rsv_slots = rsv_slots;
+
+ return platform_device_register(dm646x_edma_device);
+}
+
void __init dm646x_init(void)
{
dm646x_board_setup_refclk(ref_clk);
@@ -923,7 +932,6 @@ static int __init dm646x_init_devices(void)
if (!cpu_is_davinci_dm646x())
return 0;
- platform_device_register(dm646x_edma_device);
platform_device_register(dm646x_emac_device);
return 0;
}
diff --git a/arch/arm/mach-davinci/include/mach/dm646x.h
b/arch/arm/mach-davinci/include/mach/dm646x.h
index 846da98..f281054 100644
--- a/arch/arm/mach-davinci/include/mach/dm646x.h
+++ b/arch/arm/mach-davinci/include/mach/dm646x.h
@@ -32,6 +32,9 @@ void __init dm646x_init_ide(void);
void __init dm646x_init_mcasp0(struct snd_platform_data *pdata);
void __init dm646x_init_mcasp1(struct snd_platform_data *pdata);
void __init dm646x_board_setup_refclk(struct clk *clk);
+int __init dm646x_init_edma(const s16 (*rsv_chans)[2],
+ const s16 (*rsv_slots)[2]);
+
void dm646x_video_init(void);
--
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
RE: davinci git updated to v2.6.34-rc1
On Mon, Mar 15, 2010 at 13:57:10, Jon Povey wrote: Nori, Sekhar wrote: On Mon, Mar 15, 2010 at 07:54:57, Jon Povey wrote: I did a bit of wiki-work this morning, improvements encouraged to http://wiki.davincidsp.com/index.php/Linux_Toolchain#Linux_Kernel Hmm, did not realize this is documented here so far. Thanks! The details look pretty complete to me. What would you would like to see added there? I just meant, I wrote it up to the best of my ability, but TI folks / Kevin / others may have a better idea of the differences between the available kernels. If my understanding is good, great! Oops, did not realize that you are the author! Should have looked at the history :) Information on submitting patches upstream is documented here: http://wiki.davincidsp.com/index.php/Patch_upstream_sending Ah, I wasn't aware of that page. There seem to be a lot of hidden gems (and hidden crusy old junk) hiding in the wiki. Note that this is a public wiki, so modifications can be made by anyone in the community (not just TI folks). Yup.. I just linked the upstream patches page from that kernels section :) Thanks for helping keep the wiki updated. Regards, Sekhar ___ 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/3] davinci: support for EDMA resource sharing
From: Rajashekhara, Sudhakar sudhakar@ti.com
Current EDMA driver is not taking care of EDMA channels/slots
which are allocated from other processor, say DSP. If a
channel/slot is allocated from DSP, the existing EDMA driver
can still allocate the same resource on ARM.
This patch enables the user to pass the channel/slots reserved
for DSP as platform data. EDMA driver scans this list during
probe and prepares a bitmap of channel/slots which can be used
on ARM side.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Cc: David Brownell davi...@pacbell.net
---
This patch is untouched since the last time it was posted.
arch/arm/mach-davinci/dma.c | 36 -
arch/arm/mach-davinci/include/mach/edma.h |2 +
2 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/mach-davinci/dma.c
index 260485c..1cd0982 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/mach-davinci/dma.c
@@ -206,6 +206,18 @@ static inline void edma_parm_or(unsigned ctlr, int offset,
int param_no,
edma_or(ctlr, EDMA_PARM + offset + (param_no 5), or);
}
+static inline void set_bits(int offset, int len, unsigned long *p)
+{
+ for (; len 0; len--)
+ set_bit(offset + (len - 1), p);
+}
+
+static inline void clear_bits(int offset, int len, unsigned long *p)
+{
+ for (; len 0; len--)
+ clear_bit(offset + (len - 1), p);
+}
+
/*/
/* actual number of DMA channels and slots on this silicon */
@@ -1380,8 +1392,10 @@ static int __init edma_probe(struct platform_device
*pdev)
struct edma_soc_info*info = pdev-dev.platform_data;
const s8(*queue_priority_mapping)[2];
const s8(*queue_tc_mapping)[2];
- int i, j, found = 0;
+ int i, j, off, ln, found = 0;
int status = -1;
+ const s16 (*rsv_chans)[2];
+ const s16 (*rsv_slots)[2];
int irq[EDMA_MAX_CC] = {0, 0};
int err_irq[EDMA_MAX_CC] = {0, 0};
struct resource *r[EDMA_MAX_CC] = {NULL};
@@ -1448,6 +1462,26 @@ static int __init edma_probe(struct platform_device
*pdev)
memset(edma_info[j]-edma_unused, 0xff,
sizeof(edma_info[j]-edma_unused));
+ /* Clear the reserved channels in unused list */
+ rsv_chans = info[j].rsv_chans;
+ if (rsv_chans) {
+ for (i = 0; rsv_chans[i][0] != -1; i++) {
+ off = rsv_chans[i][0];
+ ln = rsv_chans[i][1];
+ clear_bits(off, ln, edma_info[j]-edma_unused);
+ }
+ }
+
+ /* Set the reserved channels/slots in inuse list */
+ rsv_slots = info[j].rsv_slots;
+ if (rsv_slots) {
+ for (i = 0; rsv_slots[i][0] != -1; i++) {
+ off = rsv_slots[i][0];
+ ln = rsv_slots[i][1];
+ set_bits(off, ln, edma_info[j]-edma_inuse);
+ }
+ }
+
sprintf(irq_name, edma%d, j);
irq[j] = platform_get_irq_byname(pdev, irq_name);
edma_info[j]-irq_res_start = irq[j];
diff --git a/arch/arm/mach-davinci/include/mach/edma.h
b/arch/arm/mach-davinci/include/mach/edma.h
index ced3092..55e217e 100644
--- a/arch/arm/mach-davinci/include/mach/edma.h
+++ b/arch/arm/mach-davinci/include/mach/edma.h
@@ -280,6 +280,8 @@ struct edma_soc_info {
unsignedn_cc;
enum dma_event_qdefault_queue;
+ const s16 (*rsv_chans)[2];
+ const s16 (*rsv_slots)[2];
const s8(*queue_tc_mapping)[2];
const s8(*queue_priority_mapping)[2];
};
--
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
RE: [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 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. I can certainly do that. 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. I guess I was hoping that this could be reviewed as if it were a new driver submission. I ended up more or less rewriting all of the functional parts of the driver (txrx_bufs(), chipselect(), IRQs and DMA callbacks), so it's very difficult to show this as a series of changes. I do understand the problem from your perspective, though. My thought was that if the TI folks were willing to look the driver over and they gave their blessing, that you would look at it as if it were a replacement driver and accept or deny it on that basis. Thanks for your consideration, Brian ___ 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
On Sat, Mar 13, 2010 at 04:08:20, Kevin Hilman wrote:
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
[...]
+#define EMAC_PHY_CLK_RATE 5000
+
+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),
[...]
+ 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.
That and the fact that none of the DaVinci devices have an
integrated PHY on the SoC. The clock comes from an onboard
oscillator too. So, it seemed odd to include phy clock structure
in the SoC specific file.
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.
Right, that surely will lead to a much simpler patch so I will
go ahead and change. Also, only DA850 offers a choice between
MII (25MHz) and RMII (50MHz) phy. So, the set_rate needs to be
implemented only for this SoC.
Thanks,
Sekhar
___
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: edma: clear interrupt status for interrupt enabled channels only
Nori, Sekhar nsek...@ti.com writes: On Fri, Mar 12, 2010 at 23:33:10, Kevin Hilman wrote: 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? There is some OS-less code running on the accelerator. I believe (at least some parts of) the accelerator cannot even see the DDR so having an OS implemented there seems far fetched. Without an OS in place, it is easier to poll on EDMA IPR bits. Having Linux handle the interrupt brings in IPC mechanisms which again needs an OS running on the other side and is also seen as detrimental to performance. OK, thanks for the clarification. applying, and queueing in davinci-next for 2.6.35 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 bnieb...@efjohnson.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. I can certainly do that. 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. I guess I was hoping that this could be reviewed as if it were a new driver submission. I ended up more or less rewriting all of the functional parts of the driver (txrx_bufs(), chipselect(), IRQs and DMA callbacks), so it's very difficult to show this as a series of changes. I do understand the problem from your perspective, though. My thought was that if the TI folks were willing to look the driver over and they gave their blessing, that you would look at it as if it were a replacement driver and accept or deny it on that basis. I'm OK with the approach of considering it as a brand new driver. The changelog made me think it was a bunch of fixes/enhancements and not a re-write. It should then be made more clear in the changelog that this is essentially a re-write, and why it is not done in a series of small changes. Whichever approach, this will need to worked out between you and the origial TI authors (Sandeep, Sudahkar) who will need to review/signoff this replacement. Kevin ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
dm644x DDR2 interface
Hi all. This is a hardware issue. At the beginning of paragraph 2 DM644x DDR2 Supported Devices of the document SPRAAC5F, I read: The DM644x DDR2 interface supports JEDEC DDR2 x16 devices. Supported densities are 256 Mb, 512Mb, and 1Gb in the x16 device width. Really, SPRAAC5F deals only with x16 devices. The question is: does dm6446 support x32 devices? I think so, but the statement quoted above doesn't tell it. Thanks a lot Gabriele ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
create Single Nand Image
Hello, Is it possible to create a single Nand image which contains ubl, u-boot, u-boot_env, uImage and rootfs ? Any help would be appreciate. Thanks. Regards, Sandeep Sheriker M Your Mail works best with the New Yahoo Optimized IE8. Get it NOW! 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
Re: [PATCH v2] davinci: MMC: Pass number of SG segments as platform data
On Fri, 12 Mar 2010 18:04:09 +0530 Sudhakar Rajashekhara sudhakar@ti.com 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. It's unclear what the runtime effects of this change are. I assumed (without justification) that they're minor and I scheduled the patch for 2.6.35. If that was the wrong decision then blame the changelog ;) ___ 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.
From: Kevin Hilman khil...@deeprootsystems.com Date: Fri, 12 Mar 2010 14:27:09 -0800 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. Please do: Acked-by: David S. Miller da...@davemloft.net ___ 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
I've applied the patch to the latest git kernel (I believe it was against arago), and tested it on the DM355EVM, in the meantime in polling mode only. I intend to make more tests in the near future. Several issues I've encountered were indeed solved (such as the extra writes to the bus after the chip-select turns idle). ___ 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] net: davinci emac: use dma_{map, unmap}_single API for cache coherency
From: Kevin Hilman khil...@deeprootsystems.com
Date: Thu, 11 Mar 2010 14:56:01 -0800
Sekhar Nori nsek...@ti.com writes:
The davinci emac driver uses some ARM specific DMA APIs
for cache coherency which have been removed from kernel
with the 2.6.34 merge.
Modify the driver to use the dma_{map, unmap}_single() APIs
defined in dma-mapping.h
Without this fix, the driver fails to compile on Linus's
tree.
Tested on DM365 and OMAP-L138 EVMs.
Signed-off-by: Sekhar Nori nsek...@ti.com
Acked-by: Kevin Hilman khil...@deeprootsystems.com
Verified that this is compiling/running again with v2.6.34-rc1.
Applied, thanks.
___
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
From: Kevin Hilman khil...@deeprootsystems.com Date: Fri, 12 Mar 2010 15:28:47 -0800 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 Applied, thanks. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
