Re: Lauterbach and DM365
2010/7/5 Diego Dompe diego.do...@ridgerun.com Hi, Yes, you can attach the lauterbach to a DM365. I think is even on the list of processors supported on recent versions. Diego On Jun 28, 2010, at 7:16 AM, Kieran Bingham wrote: Hi Guys, Has anyone used a lauterbach to connect the DM365? I can't find documentation anywhere on what settings to use... it works perfectly. Ask to Lauterbach, they will help you! -- Regards Kieran ___ 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 -- 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 1/3] ASoC: DaVinci: Added two clocking possibilities to McBSP (I2S)
Hi, On Fri, Jul 02, 2010 at 22:42:25, Raffaele Recalcati wrote: From: Raffaele Recalcati raffaele.recalc...@bticino.it Added two clocking options for dm365 McBSP peripheral when used with I2S timings, that are SND_SOC_DAIFMT_CBS_CFS (the cpu generates clock and frame sync) and SND_SOC_DAIFMT_CBS_CFM (the cpu gets clock from external pin and generates frame sync). A slave clock management can be important when the external codec needs the system clock and the bit clock synchronized (tested with uda1345). This patch has been developed against the: http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git git tree and has been tested on bmx board (similar to dm365 evm, but using uda1345 as external audio codec). Signed-off-by: Raffaele Recalcati raffaele.recalc...@bticino.it Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it --- sound/soc/davinci/davinci-i2s.c | 111 +++--- sound/soc/davinci/davinci-i2s.h |5 ++ 2 files changed, 107 insertions(+), 9 deletions(-) diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c index adadcd3..a893538 100644 --- a/sound/soc/davinci/davinci-i2s.c +++ b/sound/soc/davinci/davinci-i2s.c @@ -26,6 +26,7 @@ #include mach/asp.h #include davinci-pcm.h +#include davinci-i2s.h /* @@ -68,16 +69,21 @@ #define DAVINCI_MCBSP_RCR_RDATDLY(v) ((v) 16) #define DAVINCI_MCBSP_RCR_RFIG (1 18) #define DAVINCI_MCBSP_RCR_RWDLEN2(v) ((v) 21) +#define DAVINCI_MCBSP_RCR_RFRLEN2(v) ((v) 24) +#define DAVINCI_MCBSP_RCR_RPHASE (1 31) #define DAVINCI_MCBSP_XCR_XWDLEN1(v) ((v) 5) #define DAVINCI_MCBSP_XCR_XFRLEN1(v) ((v) 8) #define DAVINCI_MCBSP_XCR_XDATDLY(v) ((v) 16) #define DAVINCI_MCBSP_XCR_XFIG (1 18) #define DAVINCI_MCBSP_XCR_XWDLEN2(v) ((v) 21) +#define DAVINCI_MCBSP_XCR_XFRLEN2(v) ((v) 24) +#define DAVINCI_MCBSP_XCR_XPHASE (1 31) #define DAVINCI_MCBSP_SRGR_FWID(v) ((v) 8) #define DAVINCI_MCBSP_SRGR_FPER(v) ((v) 16) #define DAVINCI_MCBSP_SRGR_FSGM (1 28) +#define DAVINCI_MCBSP_SRGR_CLKSM (1 29) Use BIT(x) instead of (1 x). Regards, 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 0/1] davinci: spi: replace existing driver
Hi, On Sat, Jul 03, 2010 at 04:08:53, Brian Niebuhr wrote: I have included all of the recommended changes in this version of the patch. I also combined the patches into one patch to avoid bisecting issues. This makes the diff on davinci_spi.c very large. If people who are using this driver could test this version of the driver and Ack it, I would appreciate it. ** NOTE ** This patch requires the EDMA patch at: http://linux.davincidsp.com/pipermail/davinci-linux-open-source/2010-March/018022.html which is queued waiting on another driver fix, for DMA mode to work correctly. Brian Niebuhr (1): davinci: spi: replace existing 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/dm355.c | 12 +- arch/arm/mach-davinci/dm365.c | 12 +- arch/arm/mach-davinci/include/mach/spi.h| 37 +- drivers/spi/davinci_spi.c | 1328 --- 7 files changed, 648 insertions(+), 771 deletions(-) Quick update. I tested this patch on DM355 and DM365 EVMs. On DM355 all the 3 modes (DMA, Polled and Interrupt) worked fine. But in interrupt mode, on DM355, if I set intr_level = 1, then kernel hangs during booting after printing spi spi0.0: DaVinci SPI driver in Interrupt mode on the console. On DM365 only DMA and Polled mode worked fine. In interrupt mode, whether I set intr_level to ZERO or ONE, kernel booting hangs, similar to DM355. I'll update the status of testing on OMAP-L1x EVMs later. I am using the Linux kernel from [1] for testing. [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinci.git;a=summary Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 3/6] davinci: dm644x evm: setup NAND flash timing
The DM644x EVM nand flash timing was earlier being
done as a special case in the NAND driver itself.
With the NAND driver now capable of progamming the
AEMIF interface using timing data passed from the
platform, the timing values are being moved into
their rightful place in the EVM specific board file.
The values being programmed match what was being done
earlier and thus do not represent any change in
performance/functionality.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-davinci/board-dm644x-evm.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
b/arch/arm/mach-davinci/board-dm644x-evm.c
index 34c8b41..65bb940 100644
--- a/arch/arm/mach-davinci/board-dm644x-evm.c
+++ b/arch/arm/mach-davinci/board-dm644x-evm.c
@@ -37,6 +37,7 @@
#include mach/nand.h
#include mach/mmc.h
#include mach/usb.h
+#include mach/aemif.h
#define DM644X_EVM_PHY_MASK(0x2)
#define DM644X_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
@@ -137,11 +138,22 @@ static struct mtd_partition
davinci_evm_nandflash_partition[] = {
*/
};
+static struct davinci_aemif_timing davinci_evm_nandflash_timing = {
+ .wsetup = 20,
+ .wstrobe= 40,
+ .whold = 20,
+ .rsetup = 10,
+ .rstrobe= 40,
+ .rhold = 10,
+ .ta = 40,
+};
+
static struct davinci_nand_pdata davinci_evm_nandflash_data = {
.parts = davinci_evm_nandflash_partition,
.nr_parts = ARRAY_SIZE(davinci_evm_nandflash_partition),
.ecc_mode = NAND_ECC_HW,
.options= NAND_USE_FLASH_BBT,
+ .timing = davinci_evm_nandflash_timing,
};
static struct resource davinci_evm_nandflash_resource[] = {
--
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
[PATCH v2 1/6] davinci: add support for aemif timing configuration
This patch adds support to configure the AEMIF interface
with supplied timing values.
Since this capability is useful both from NOR and NAND
flashes, it is provided as a new interface and in a file
of its own.
AEMIF timing configuration is required in cases:
1) Where the AEMIF clock rate can change at runtime (a side
affect of cpu frequency change).
2) Where U-Boot does not support NAND/NOR but supports other
media like SPI Flash or MMC/SD and thus does not care about
setting up the AEMIF timing for kernel to use.
3) Where U-Boot just hasn't configured the timing values and
cannot be upgraded because the box is already in the field.
Since there is now a header file for AEMIF interface, the
common (non-NAND specific) defines for AEMIF registers have
been moved from nand.h into the newly created aemif.h
Signed-off-by: Sekhar Nori nsek...@ti.com
---
v2:
1) return error from aemif_clk_rate() in case the timing values obtained
exceed the max allowed
2) removed common aemif register definitions from nand.h
arch/arm/mach-davinci/Makefile |2 +-
arch/arm/mach-davinci/aemif.c | 134
arch/arm/mach-davinci/include/mach/aemif.h | 36
arch/arm/mach-davinci/include/mach/nand.h |3 -
drivers/mtd/nand/davinci_nand.c|1 +
5 files changed, 172 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/mach-davinci/aemif.c
create mode 100644 arch/arm/mach-davinci/include/mach/aemif.h
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index eab4c0f..77a0f71 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -5,7 +5,7 @@
# Common objects
obj-y := time.o clock.o serial.o io.o psc.o \
- gpio.o dma.o usb.o common.o sram.o
+ gpio.o dma.o usb.o common.o sram.o aemif.o
obj-$(CONFIG_DAVINCI_MUX) += mux.o
diff --git a/arch/arm/mach-davinci/aemif.c b/arch/arm/mach-davinci/aemif.c
new file mode 100644
index 000..12b712f
--- /dev/null
+++ b/arch/arm/mach-davinci/aemif.c
@@ -0,0 +1,134 @@
+/*
+ * AEMIF support for DaVinci SoCs
+ *
+ * Copyright (C) 2010 Texas Instruments Incorporated. http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/io.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/module.h
+
+#include mach/aemif.h
+
+/* Timing value configuration */
+
+#define TA(x) ((x) 2)
+#define RHOLD(x) ((x) 4)
+#define RSTROBE(x) ((x) 7)
+#define RSETUP(x) ((x) 13)
+#define WHOLD(x) ((x) 17)
+#define WSTROBE(x) ((x) 20)
+#define WSETUP(x) ((x) 26)
+
+#define TA_MAX 0x3
+#define RHOLD_MAX 0x7
+#define RSTROBE_MAX0x3f
+#define RSETUP_MAX 0xf
+#define WHOLD_MAX 0x7
+#define WSTROBE_MAX0x3f
+#define WSETUP_MAX 0xf
+
+#define TIMING_MASK(TA(TA_MAX) | \
+ RHOLD(RHOLD_MAX) | \
+ RSTROBE(RSTROBE_MAX) | \
+ RSETUP(RSETUP_MAX) | \
+ WHOLD(WHOLD_MAX) | \
+ WSTROBE(WSTROBE_MAX) | \
+ WSETUP(WSETUP_MAX))
+
+#define NS_IN_KHZ 100
+
+/*
+ * aemif_calc_rate - calculate timing data.
+ * @wanted: The cycle time needed in nanoseconds.
+ * @clk: The input clock rate in kHz.
+ * @max: The maximum divider value that can be programmed.
+ *
+ * On success, returns the calculated timing value minus 1 for easy
+ * programming into AEMIF timing registers, else negative errno.
+ */
+static int aemif_calc_rate(int wanted, unsigned long clk, int max)
+{
+ int result;
+
+ result = DIV_ROUND_UP((wanted * clk), NS_IN_KHZ) - 1;
+
+ pr_debug(%s: result %d from %ld, %d\n, __func__, result, clk, wanted);
+
+ /* It is generally OK to have a more relaxed timing than requested... */
+ if (result 0)
+ result = 0;
+
+ /* ... But configuring tighter timings is not an option. */
+ else if (result max)
+ result = -EINVAL;
+
+ return result;
+}
+
+/**
+ * davinci_aemif_setup_timing - setup timing values for a given AEMIF interface
+ * @t: timing values to be progammed
+ * @base: The virtual base address of the AEMIF interface
+ * @cs: chip-select to program the timing values for
+ *
+ * This function programs the given timing values (in real clock) into the
+ * AEMIF registers taking the AEMIF clock into account.
+ *
+ * This function does not use any locking while programming the AEMIF
+ * because it is expected that there is only one user of a given
+ * chip-select.
+ *
+ * Returns 0 on success, else negative errno.
+ */
+int davinci_aemif_setup_timing(struct
[PATCH v2 6/6] davinci: dm6467t evm: setup NAND flash timing
Setup NAND flash timing on DM6467T EVM.
Without the timing setup, the NAND flash on DM6467T
RevC EVM reports a number of random bad blocks because
of read errors.
Also, with this, copying a 100M file on RevB EVM takes
~35 sec against 1 minute 30 seconds earlier.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
v2: DM6467T and DM6467 EVMs use slightly different NAND parts, made the
timing configuration specific to DM6467T.
arch/arm/mach-davinci/board-dm646x-evm.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 6d88893..749aef8 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -42,6 +42,7 @@
#include mach/nand.h
#include mach/clock.h
#include mach/cdce949.h
+#include mach/aemif.h
#include clock.h
@@ -71,6 +72,16 @@ static struct mtd_partition davinci_nand_partitions[] = {
}
};
+static struct davinci_aemif_timing dm6467tevm_nandflash_timing = {
+ .wsetup = 29,
+ .wstrobe= 24,
+ .whold = 14,
+ .rsetup = 19,
+ .rstrobe= 33,
+ .rhold = 0,
+ .ta = 29,
+};
+
static struct davinci_nand_pdata davinci_nand_data = {
.mask_cle = 0x8,
.mask_ale = 0x4,
@@ -730,6 +741,9 @@ static __init void evm_init(void)
dm646x_init_mcasp0(dm646x_evm_snd_data[0]);
dm646x_init_mcasp1(dm646x_evm_snd_data[1]);
+ if (machine_is_davinci_dm6467tevm())
+ davinci_nand_data.timing = dm6467tevm_nandflash_timing;
+
platform_device_register(davinci_nand_device);
if (HAS_ATA)
--
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
[PATCH v2 2/6] nand: davinci: add support for timing configuration
This patch modifies the DaVinci NAND driver to use the
new AEMIF timing setup API to configure the NAND access
timings.
Earlier, AEMIF configuration was being done as a special
case for DM644x board, but now more boards emerge which have
capability to boot for other media (SPI flash, NOR flash) and
have the kernel access NAND flash. This means that kernel cannot
always depend on the bootloader to setup the NAND.
Also, on platforms such as da850/omap-l138, the aemif input
frequency changes as cpu frequency changes; necessiating
re-calculation of timimg values as part of cpufreq transtitions.
This patch forms the basis for adding that support.
Signed-off-by: Sekhar Nori nsek...@ti.com
---
v2: no need to include aemif.h in nand.c in this patch since patch 1/6 does
that now.
arch/arm/mach-davinci/include/mach/nand.h |3 +
drivers/mtd/nand/davinci_nand.c | 60 ++--
2 files changed, 25 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/nand.h
b/arch/arm/mach-davinci/include/mach/nand.h
index b5893f0..0251510 100644
--- a/arch/arm/mach-davinci/include/mach/nand.h
+++ b/arch/arm/mach-davinci/include/mach/nand.h
@@ -80,6 +80,9 @@ struct davinci_nand_pdata { /* platform_data */
/* Main and mirror bbt descriptor overrides */
struct nand_bbt_descr *bbt_td;
struct nand_bbt_descr *bbt_md;
+
+ /* Access timings */
+ struct davinci_aemif_timing *timing;
};
#endif /* __ARCH_ARM_DAVINCI_NAND_H */
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 8e2d56c..8beb0d0 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -75,6 +75,8 @@ struct davinci_nand_info {
uint32_tmask_cle;
uint32_tcore_chipsel;
+
+ struct davinci_aemif_timing *timing;
};
static DEFINE_SPINLOCK(davinci_nand_lock);
@@ -479,36 +481,6 @@ static int nand_davinci_dev_ready(struct mtd_info *mtd)
return davinci_nand_readl(info, NANDFSR_OFFSET) BIT(0);
}
-static void __init nand_dm6446evm_flash_init(struct davinci_nand_info *info)
-{
- uint32_t regval, a1cr;
-
- /*
-* NAND FLASH timings @ PLL1 == 459 MHz
-* - AEMIF.CLK freq = PLL1/6 = 459/6 = 76.5 MHz
-* - AEMIF.CLK period = 1/76.5 MHz = 13.1 ns
-*/
- regval = 0
- | (0 31) /* selectStrobe */
- | (0 30) /* extWait (never with NAND) */
- | (1 26) /* writeSetup 10 ns */
- | (3 20) /* writeStrobe 40 ns */
- | (1 17) /* writeHold 10 ns */
- | (0 13) /* readSetup 10 ns */
- | (3 7)/* readStrobe 60 ns */
- | (0 4)/* readHold10 ns */
- | (3 2)/* turnAround ?? ns */
- | (0 0)/* asyncSize 8-bit bus */
- ;
- a1cr = davinci_nand_readl(info, A1CR_OFFSET);
- if (a1cr != regval) {
- dev_dbg(info-dev, Warning: NAND config: Set A1CR \
- reg to 0x%08x, was 0x%08x, should be done by \
- bootloader.\n, regval, a1cr);
- davinci_nand_writel(info, A1CR_OFFSET, regval);
- }
-}
-
/*--*/
/* An ECC layout for using 4-bit ECC with small-page flash, storing
@@ -612,6 +584,7 @@ static int __init nand_davinci_probe(struct platform_device
*pdev)
info-chip.options = pdata-options;
info-chip.bbt_td = pdata-bbt_td;
info-chip.bbt_md = pdata-bbt_md;
+ info-timing= pdata-timing;
info-ioaddr= (uint32_t __force) vaddr;
@@ -689,15 +662,25 @@ static int __init nand_davinci_probe(struct
platform_device *pdev)
goto err_clk_enable;
}
- /* EMIF timings should normally be set by the boot loader,
-* especially after boot-from-NAND. The *only* reason to
-* have this special casing for the DM6446 EVM is to work
-* with boot-from-NOR ... with CS0 manually re-jumpered
-* (after startup) so it addresses the NAND flash, not NOR.
-* Even for dev boards, that's unusually rude...
+ /*
+* Setup Async configuration register in case we did not boot from
+* NAND and so bootloader did not bother to set it up.
*/
- if (machine_is_davinci_evm())
- nand_dm6446evm_flash_init(info);
+ val = davinci_nand_readl(info, A1CR_OFFSET + info-core_chipsel * 4);
+
+ /* Extended Wait is not valid and Select Strobe mode is not used */
+ val = ~(ACR_ASIZE_MASK | ACR_EW_MASK | ACR_SS_MASK);
+ if (info-chip.options NAND_BUSWIDTH_16)
+ val |= 0x1;
+
+
[PATCH 5/6] davinci: am18x/da850/omap-l138 evm: setup NAND flash timing
Setup the NAND flash timings for DA850 EVM
Before configuring the timing values, throughput calculation
using dd command yielded 469 kB/s write and 966 kB/s read speed.
After the timing configuration, the throughput was measured to
be 2.4 MB/s write and 5 MB/s read.
[Mukul Bhatnagar: actual calculation of timing values from the
NAND datasheet]
Signed-off-by: Sekhar Nori nsek...@ti.com
Cc: Mukul Bhatnagar mbhatna...@ti.com
---
arch/arm/mach-davinci/board-da850-evm.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 2ec3095..85e6e58 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -35,6 +35,7 @@
#include mach/da8xx.h
#include mach/nand.h
#include mach/mux.h
+#include mach/aemif.h
#define DA850_EVM_PHY_MASK 0x1
#define DA850_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */
@@ -142,12 +143,23 @@ struct mtd_partition da850_evm_nandflash_partition[] = {
},
};
+static struct davinci_aemif_timing da850_evm_nandflash_timing = {
+ .wsetup = 24,
+ .wstrobe= 21,
+ .whold = 14,
+ .rsetup = 19,
+ .rstrobe= 50,
+ .rhold = 0,
+ .ta = 20,
+};
+
static struct davinci_nand_pdata da850_evm_nandflash_data = {
.parts = da850_evm_nandflash_partition,
.nr_parts = ARRAY_SIZE(da850_evm_nandflash_partition),
.ecc_mode = NAND_ECC_HW,
.ecc_bits = 4,
.options= NAND_USE_FLASH_BBT,
+ .timing = da850_evm_nandflash_timing,
};
static struct resource da850_evm_nandflash_resource[] = {
--
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
[PATCH 4/6] davinci: am17x/da830/omap-l137 evm: setup NAND flash timing
From: Sudhakar Rajashekhara sudhakar@ti.com
Setup the NAND flash timings for DA830 EVM.
Before configuring the timing values, throughput calculation
using dd command yielded 477 kB/s write and 970 kB/s read speed.
After the timing configuration, the throughput was measured to
be 2.5 MB/s write and 5.1 MB/s read.
[Mukul Bhatnagar: actual calculation of timing values from the
NAND datasheet]
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
Cc: Mukul Bhatnagar mbhatna...@ti.com
Signed-off-by: Sekhar Nori nsek...@ti.com
---
arch/arm/mach-davinci/board-da830-evm.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da830-evm.c
b/arch/arm/mach-davinci/board-da830-evm.c
index 212d970..c0dce08 100644
--- a/arch/arm/mach-davinci/board-da830-evm.c
+++ b/arch/arm/mach-davinci/board-da830-evm.c
@@ -29,6 +29,7 @@
#include mach/nand.h
#include mach/da8xx.h
#include mach/usb.h
+#include mach/aemif.h
#define DA830_EVM_PHY_MASK 0x0
#define DA830_EVM_MDIO_FREQUENCY 220 /* PHY bus frequency */
@@ -360,6 +361,16 @@ static struct nand_bbt_descr
da830_evm_nand_bbt_mirror_descr = {
.pattern= da830_evm_nand_mirror_pattern
};
+static struct davinci_aemif_timing da830_evm_nandflash_timing = {
+ .wsetup = 24,
+ .wstrobe= 21,
+ .whold = 14,
+ .rsetup = 19,
+ .rstrobe= 50,
+ .rhold = 0,
+ .ta = 20,
+};
+
static struct davinci_nand_pdata da830_evm_nand_pdata = {
.parts = da830_evm_nand_partitions,
.nr_parts = ARRAY_SIZE(da830_evm_nand_partitions),
@@ -368,6 +379,7 @@ static struct davinci_nand_pdata da830_evm_nand_pdata = {
.options= NAND_USE_FLASH_BBT,
.bbt_td = da830_evm_nand_bbt_main_descr,
.bbt_md = da830_evm_nand_bbt_mirror_descr,
+ .timing = da830_evm_nandflash_timing,
};
static struct resource da830_evm_nand_resources[] = {
--
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: [spi-devel-general] [PATCH v2 0/1] davinci: spi: replaceexisting driver
On Sat, Jul 03, 2010 at 04:08:53, Brian Niebuhr wrote: I have included all of the recommended changes in this version of the patch. I also combined the patches into one patch to avoid bisecting issues. This makes the diff on davinci_spi.c very large. If people who are using this driver could test this version of the driver and Ack it, I would appreciate it. ** NOTE ** This patch requires the EDMA patch at: http://linux.davincidsp.com/pipermail/davinci-linux-open-sourc e/2010-March/018022.html which is queued waiting on another driver fix, for DMA mode to work correctly. Brian Niebuhr (1): davinci: spi: replace existing 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/dm355.c | 12 +- arch/arm/mach-davinci/dm365.c | 12 +- arch/arm/mach-davinci/include/mach/spi.h| 37 +- drivers/spi/davinci_spi.c | 1328 --- 7 files changed, 648 insertions(+), 771 deletions(-) Quick update. I tested this patch on DM355 and DM365 EVMs. On DM355 all the 3 modes (DMA, Polled and Interrupt) worked fine. But in interrupt mode, on DM355, if I set intr_level = 1, then kernel hangs during booting after printing spi spi0.0: DaVinci SPI driver in Interrupt mode on the console. Sudhakar - When you changed the interrupt level, did you also change the IORESOURCE_IRQ entry for SPI0? Maybe we could set the interrupt level automatically based on the IORESOURCE_IRQ provided? The problem is, I don't see any way of doing that without a bunch of machine-specific ifdefs in the driver. On DM365 only DMA and Polled mode worked fine. In interrupt mode, whether I set intr_level to ZERO or ONE, kernel booting hangs, similar to DM355. Does the interrupt mode of the existing driver work on DM365? I don't have one of these boards, so I can't debug the issue. If you have any ideas where the problem might be I'd appreciate the help in getting this resolved. If the change I mentioned above fixes the issue on DM355, then I've got to imagine that it's just a configuration issue of some sort on DM365. I'll update the status of testing on OMAP-L1x EVMs later. I am using the Linux kernel from [1] for testing. [1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-davinc i.git;a=summary ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Choosing filesytems JFFS2 or Ramdisk
How about using CRAMFS with a JFFS or YAFFS partition which is for configuration/logging. If your writable partitions become corrupt, you only lose configuration/logging and not your entire filesystem. Steve On 07/05/2010 07:50 AM, rohan tabish wrote: Hello I have an application requirement which performs alot of read write operations on the file system so what is the recommended file system i should use i guess using jffs2 is the option because having ram disk as file system will not be able to save the configuration on next boot. There is also a problem with JFFS2 as file system doing many file operations on flash will finish its life over the time as flash have limited life Kindly suggest what should be the preferred way out Regard's r...@n -- This message has been scanned for viruses and dangerous content by *MailScanner* http://www.mailscanner.info/, and is believed to be clean. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Question on RAMDISK
On 07/05/2010 05:52 AM, rohan tabish wrote: Hello everyone I am using a ramdisk image to boot the system its takes around 7secs to copy the ramdisk image from the flash to the RAM and then takes 3.6 seconds after kernal uncompressing to the linux prompt Reduce your RAMDISK size. Maybe use two partitions, one that is CRAMFS and another that is RAMDISK. I want to know that how to reduce this time of 7seconds. Also can anyone tell how to update the ramdisk image from the linux prompt.e.g if i have created a file and now iwant it at the next boot then how to make this file part of the old ramdisk image How about booting the system quickly with CRAMFS, with a JFFS2 filesystem that is smaller and a RAM disk to match the JFFS2. At startup, you can mount the JFFS2 (hidden mount point) and RAM disk, copy the JFFS2 contents to RAM, then on shutdown, copy it back. Regard's RT ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: change the source of simplewidget and compile it has no effect on our own application, can we change the code and rebuild the lib simplewidget?
You should look at the DVSDK documentation which shows how to rebuild the CodecEngine Codec Server. This process is a bit more tricky since it is building for two processors. The library that links with your application does not contain all the code for these components. There is the server portion which handles the request. I am not familiar with simplewidget, but it is likely that you are not getting the updated server which is going to be a mix of ARM/DSP code. Steve On 07/05/2010 07:25 AM, johnny wrote: Hi all, For some reason I have to change the code of dvsdk_demos_2_10_00_17/packages/ti/sdo/simplewidget/Button.c and Button.h, I complie the direcotry of simplewidget for dm365 but the new interface added by us can not be found. I found only one simplewidget_dm365.a470MV in the whole directory dvsdk_2_10_01_18 in directory dvsdk_demos_2_10_00_17/packages/ti/sdo/simplewidget/lib/, but after I delete the file dvsdk_demos_2_10_00_17/packages/ti/sdo/simplewidget/lib/simplewidget_dm365.a470MV, we can still compile our application successfully. How could this happen? can we change the code and rebuild the lib simplewidget? 2010-07-05 johnny -- This message has been scanned for viruses and dangerous content by *MailScanner* http://www.mailscanner.info/, and is believed to be clean. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: using jffs2 or ramdisk saving flash
Using an uncompressed kernel will also help your speed. On 07/02/2010 01:51 AM, rohan tabish wrote: I am using DM6446 have written device drivers each time my system boots i need to do insmod to install many drivers.for jffs2 file system these drivers are installed in flash that is lsmod displays the flash address this means each time i boot i write to flash in real product with time the flash will die so i have to switch to ramdisk image but problem with this is that it takes alot of time to boot the system. Anyone know how to save flash and boot quickly Regard's RT -- This message has been scanned for viruses and dangerous content by *MailScanner* http://www.mailscanner.info/, and is believed to be clean. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DM355 - 256MB RAM memory issue
DM355 doesn't include a DSP, and therefore has no Codec Server. The Codecs are configured to run 'locally' on the ARM. Chris From: davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of Todd Fischer Sent: Tuesday, July 06, 2010 8:00 AM To: tha...@e-consystems.com Cc: davinci-linux-open-source@linux.davincidsp.com; dhineshkumar; Mohamed Thalib H; maharajan Subject: Re: DM355 - 256MB RAM memory issue Tharmarajan, I believe you need to rebuild your codec server with a different memory map. Another idea is to have a hole in the kernel memory space (specify mem= in the kernel command line twice). I am not sure if the kernel version you are using for dm355 supports a hole in the kernel memory space. Todd On Mon, 2010-07-05 at 19:44 +0530, Tharmarajan Ganeshan wrote: Hi All, We are working on a DM355 processor based Development board. The Board has 256MB mDDR RAM and 5MP image sensor MT9P031. We are using the kernel version 2.6.10 We have modified the driver code for capturing 5MP raw image and converting this 5MP raw into YUV. For this 5MP image capturing , we have reserved 30MB. We have allocated 56MB to the CMEM driver. The reserved memory 30MB and the 56MB memory for CMEM are at top of the RAM. We are passing the remaining memory size to the kernel in bootargs as mem=170M. And we are using the NFS rootfilesystem. But we are getting kernel hanging issues while testing the IPNC_APP applications and 5MP still image capturing. Sometimes the kernel is hanging while booting itself. If we reserve the 30MB from the address region 0x8320 - 0x84FF and pass the memory size to kernel in bootargs as mem=50M, then we are NOT having any issues in running the applications. But we want to use the exact remaining memory. And also we are not able to program the NAND flash memory in kernel level if we are not passing the mem=50M in bootargs. What could be the cause for this kernel hanging issue ? Are we missing any configurations while building the kernel image ? Our Bootargs is : mem=50M console=ttyS1,115200n8 root=/dev/nfs rootwait rw ip=192.168.1.90:192.168.1.99:192.168.1.1:255.255.255.0 nfsroot=192.168.1.99:/tftpboot/bellatrix_rootfilesystem,nolock eth=00:0C:0C:A0:01:FE v4l2_video_capture=:device=MT9P031 Regards, Tharmarajan G ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.commailto: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: DM355 - 256MB RAM memory issue
Chris, I've only went through this exercise on the DM64x products and wrongfully assumed that it would still build the two libraries for the DM3xx devices, even if it just finally linked them all together in the end. Steve On 07/06/2010 10:59 AM, Ring, Chris wrote: DM355 doesn't include a DSP, and therefore has no Codec Server. The Codecs are configured to run 'locally' on the ARM. Chris *From:* davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] *On Behalf Of *Todd Fischer *Sent:* Tuesday, July 06, 2010 8:00 AM *To:* tha...@e-consystems.com *Cc:* davinci-linux-open-source@linux.davincidsp.com; dhineshkumar; Mohamed Thalib H; maharajan *Subject:* Re: DM355 - 256MB RAM memory issue Tharmarajan, I believe you need to rebuild your codec server with a different memory map. Another idea is to have a hole in the kernel memory space (specify mem= in the kernel command line twice). I am not sure if the kernel version you are using for dm355 supports a hole in the kernel memory space. Todd On Mon, 2010-07-05 at 19:44 +0530, Tharmarajan Ganeshan wrote: Hi All, We are working on a DM355 processor based Development board. The Board has 256MB mDDR RAM and 5MP image sensor MT9P031. We are using the kernel version 2.6.10 We have modified the driver code for capturing 5MP raw image and converting this 5MP raw into YUV. For this 5MP image capturing , we have reserved 30MB. We have allocated 56MB to the CMEM driver. The reserved memory 30MB and the 56MB memory for CMEM are at top of the RAM. We are passing the remaining memory size to the kernel in bootargs as mem=170M. And we are using the NFS rootfilesystem. But we are getting kernel hanging issues while testing the IPNC_APP applications and 5MP still image capturing. Sometimes the kernel is hanging while booting itself. If we reserve the 30MB from the address region 0x8320 - 0x84FF and pass the memory size to kernel in bootargs as mem=50M, then we are NOT having any issues in running the applications. But we want to use the exact remaining memory. And also we are not able to program the NAND flash memory in kernel level if we are not passing the mem=50M in bootargs. What could be the cause for this kernel hanging issue ? Are we missing any configurations while building the kernel image ? Our Bootargs is : mem=50M console=ttyS1,115200n8 root=/dev/nfs rootwait rw ip=192.168.1.90:192.168.1.99:192.168.1.1:255.255.255.0 nfsroot=192.168.1.99:/tftpboot/bellatrix_rootfilesystem,nolock eth=00:0C:0C:A0:01:FE v4l2_video_capture=:device=MT9P031 Regards, Tharmarajan G ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com mailto:Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- This message has been scanned for viruses and dangerous content by *MailScanner* http://www.mailscanner.info/, and is believed to be clean. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: DM355 - 256MB RAM memory issue
Chris, Disregard my message. I mistakenly applied your response to one of my replies. Steve On 07/06/2010 11:11 AM, Steve Poulsen wrote: Chris, I've only went through this exercise on the DM64x products and wrongfully assumed that it would still build the two libraries for the DM3xx devices, even if it just finally linked them all together in the end. Steve On 07/06/2010 10:59 AM, Ring, Chris wrote: DM355 doesn't include a DSP, and therefore has no Codec Server. The Codecs are configured to run 'locally' on the ARM. Chris *From:* davinci-linux-open-source-boun...@linux.davincidsp.com [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] *On Behalf Of *Todd Fischer *Sent:* Tuesday, July 06, 2010 8:00 AM *To:* tha...@e-consystems.com *Cc:* davinci-linux-open-source@linux.davincidsp.com; dhineshkumar; Mohamed Thalib H; maharajan *Subject:* Re: DM355 - 256MB RAM memory issue Tharmarajan, I believe you need to rebuild your codec server with a different memory map. Another idea is to have a hole in the kernel memory space (specify mem= in the kernel command line twice). I am not sure if the kernel version you are using for dm355 supports a hole in the kernel memory space. Todd On Mon, 2010-07-05 at 19:44 +0530, Tharmarajan Ganeshan wrote: Hi All, We are working on a DM355 processor based Development board. The Board has 256MB mDDR RAM and 5MP image sensor MT9P031. We are using the kernel version 2.6.10 We have modified the driver code for capturing 5MP raw image and converting this 5MP raw into YUV. For this 5MP image capturing , we have reserved 30MB. We have allocated 56MB to the CMEM driver. The reserved memory 30MB and the 56MB memory for CMEM are at top of the RAM. We are passing the remaining memory size to the kernel in bootargs as mem=170M. And we are using the NFS rootfilesystem. But we are getting kernel hanging issues while testing the IPNC_APP applications and 5MP still image capturing. Sometimes the kernel is hanging while booting itself. If we reserve the 30MB from the address region 0x8320 - 0x84FF and pass the memory size to kernel in bootargs as mem=50M, then we are NOT having any issues in running the applications. But we want to use the exact remaining memory. And also we are not able to program the NAND flash memory in kernel level if we are not passing the mem=50M in bootargs. What could be the cause for this kernel hanging issue ? Are we missing any configurations while building the kernel image ? Our Bootargs is : mem=50M console=ttyS1,115200n8 root=/dev/nfs rootwait rw ip=192.168.1.90:192.168.1.99:192.168.1.1:255.255.255.0 nfsroot=192.168.1.99:/tftpboot/bellatrix_rootfilesystem,nolock eth=00:0C:0C:A0:01:FE v4l2_video_capture=:device=MT9P031 Regards, Tharmarajan G ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com mailto:Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- This message has been scanned for viruses and dangerous content by *MailScanner* http://www.mailscanner.info/, and is believed to be clean. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- This message has been scanned for viruses and dangerous content by *MailScanner* http://www.mailscanner.info/, and is believed to be clean. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Rif: Re: [PATCH 3/3] ASoC: DaVinci: More accurate calculation for clock divider for McBSP (I2S)
raffaele.recalc...@bticino.it wrote:
-Troy Kisky troy.ki...@boundarydevices.com ha scritto: -
Per: Raffaele Recalcati lamiapost...@gmail.com
Da: Troy Kisky troy.ki...@boundarydevices.com
Data: 02/07/2010 22.57
Cc: davinci-linux-open-source@linux.davincidsp.com, Mark Brown
broo...@opensource.wolfsonmicro.com, Raffaele Recalcati
raffaele.recalc...@bticino.it
Oggetto: Re: [PATCH 3/3] ASoC: DaVinci: More accurate calculation for
clock divider for McBSP (I2S)
Raffaele Recalcati wrote:
@@ -447,6 +448,24 @@ static int davinci_i2s_hw_params(struct
snd_pcm_substream *substream,
8 - 1);
+if (dev-i2s_accurate_clock) {
+clk_div = 256;
+do {
+
framesize = (freq / (--clk_div)) /
+params-rate_num *
+params-
rate_den;
+
} while (((framesize 33) || (framesize 4095))
+ (clk_div));
+clk_div--;
+srgr |= DAVINCI_MCBSP_SRGR_FPER
(framesize - 1);
+} else {
+/* symmetric waveforms */
+
clk_div = freq / (mcbsp_word_length * 16) /
+ params-
rate_num * params-rate_den;
+srgr |= DAVINCI_MCBSP_SRGR_FPER
(mcbsp_word_length *
+
16 - 1);
+}
+
/* symmetric waveforms */
clk_div = freq / (mcbsp_word_length * 16) /
params-rate_num * params-
rate_den;
Can you test to see if this works to replace all the above ?
unsigned cycles;
framesize = mcbsp_word_length * 16;
cycles = (freq / params-rate_num) * params-
rate_den;
clk_div = cycles / framesize;
if (dev-i2s_accurate_clock) {
framesize = cycles / clk_div;
if (framesize 4096))
framesize = 4096;
}
srgr |= DAVINCI_MCBSP_SRGR_FPER(framesize - 1);
yes, it works.
Now I'm trying to understand the differences:
your solution with i2s_accurate_clock enabled:
davinci-asp davinci-asp.0: framesize = 32
davinci-asp davinci-asp.0: clk_div = 86
your solution with i2s_accurate_clock NOT enabled:
davinci-asp davinci-asp.0: framesize = 32
davinci-asp davinci-asp.0: clk_div = 86
the same.
my solution with i2s_accurate_clock enabled:
davinci-asp davinci-asp.0: my framesize = 33
davinci-asp
davinci-asp.0: clk_div = 82
here the continuous serial clock is faster
my solution with i2s_accurate_clock NOT enabled
davinci-asp davinci-asp.0: my framesize = 32
davinci-asp davinci-asp.0: clk_div = 86
here the continuous
serial clock is the same as yours.
it seems better my and Davide solution.
Indeed, your algorithm may produce more accurate results for the specific rate
that you tested for. However, that seems more luck than anything. How do you
know that a frame size of 33 will always give more accurate results than a frame
size of 32? If your going to loop, you need to calculate the error and minimize
that
and not just stop when framesize finally reaches your minimum size of 33.
Also, you may want to stop when your framesize twice your minimum framesize.
Otherwise you may end up with a very very fast clock most of which is garbage
cycles.
Troy
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 3/3] ASoC: DaVinci: Added fast clock timing for McBSP (I2S)
From: Raffaele Recalcati raffaele.recalc...@bticino.it
i2s_fast_clock switch can be used to have a better approximate
frequency.
The waveform will be not symmetric.
This patch has been developed against the
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
git tree and has been tested on bmx board (similar to dm365 evm, but using
uda1345 as external audio codec).
Signed-off-by: Raffaele Recalcati raffaele.recalc...@bticino.it
Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it
---
arch/arm/mach-davinci/include/mach/asp.h |7 +++
sound/soc/davinci/davinci-i2s.c | 24 +++-
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/asp.h
b/arch/arm/mach-davinci/include/mach/asp.h
index 314570d..2d8f8af 100644
--- a/arch/arm/mach-davinci/include/mach/asp.h
+++ b/arch/arm/mach-davinci/include/mach/asp.h
@@ -63,6 +63,13 @@ struct snd_platform_data {
unsigned sram_size_playback;
unsigned sram_size_capture;
+ /*
+* This define works when both clock and FS are output for the cpu
+* and makes clock very fast (FS is not symmetrical, but sampling
+* frequency is better approximated
+*/
+ bool i2s_fast_clock;
+
/* To be used when cpu gets clock from external pin */
int clk_input_pin;
diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c
index e478be9..0af5bae 100644
--- a/sound/soc/davinci/davinci-i2s.c
+++ b/sound/soc/davinci/davinci-i2s.c
@@ -150,6 +150,7 @@ struct davinci_mcbsp_dev {
*/
unsigned enable_channel_combine:1;
+ bool i2s_fast_clock;
unsigned int fmt;
int clk_div;
int clk_input_pin;
@@ -443,11 +444,23 @@ static int davinci_i2s_hw_params(struct snd_pcm_substream
*substream,
DAVINCI_MCBSP_SRGR_CLKSM;
srgr |= DAVINCI_MCBSP_SRGR_FWID(mcbsp_word_length *
8 - 1);
- /* symmetric waveforms */
- clk_div = freq / (mcbsp_word_length * 16) /
- params-rate_num * params-rate_den;
- srgr |= DAVINCI_MCBSP_SRGR_FPER(mcbsp_word_length *
- 16 - 1);
+ if (dev-i2s_fast_clock) {
+ clk_div = 256;
+ do {
+ framesize = (freq / (--clk_div)) /
+ params-rate_num *
+ params-rate_den;
+ } while (((framesize 33) || (framesize 4095))
+(clk_div));
+ clk_div--;
+ srgr |= DAVINCI_MCBSP_SRGR_FPER(framesize - 1);
+ } else {
+ /* symmetric waveforms */
+ clk_div = freq / (mcbsp_word_length * 16) /
+ params-rate_num * params-rate_den;
+ srgr |= DAVINCI_MCBSP_SRGR_FPER(mcbsp_word_length *
+ 16 - 1);
+ }
clk_div = 0xFF;
srgr |= clk_div;
break;
@@ -643,6 +656,7 @@ static int davinci_i2s_probe(struct platform_device *pdev)
pdata-sram_size_playback;
dev-dma_params[SNDRV_PCM_STREAM_CAPTURE].sram_size =
pdata-sram_size_capture;
+ dev-i2s_fast_clock = pdata-i2s_fast_clock;
dev-clk_input_pin = pdata-clk_input_pin;
}
dev-clk = clk_get(pdev-dev, NULL);
--
1.7.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 1/3] ASoC: DaVinci: Added two clocking possibilities to McBSP (I2S)
From: Raffaele Recalcati raffaele.recalc...@bticino.it
Added two clocking options for dm365 McBSP peripheral when used
with I2S timings, that are SND_SOC_DAIFMT_CBS_CFS (the cpu generates
clock and frame sync) and SND_SOC_DAIFMT_CBS_CFM (the cpu gets clock
from external pin and generates frame sync).
A slave clock management can be important when the external codec needs
the system clock and the bit clock synchronized (tested with uda1345).
This patch has been developed against the:
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
git tree and has been tested on bmx board (similar to dm365 evm, but using
uda1345 as external audio codec).
Signed-off-by: Raffaele Recalcati raffaele.recalc...@bticino.it
Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it
---
sound/soc/davinci/davinci-i2s.c | 92 +++
1 files changed, 83 insertions(+), 9 deletions(-)
diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c
index adadcd3..319e8ca 100644
--- a/sound/soc/davinci/davinci-i2s.c
+++ b/sound/soc/davinci/davinci-i2s.c
@@ -68,16 +68,21 @@
#define DAVINCI_MCBSP_RCR_RDATDLY(v) ((v) 16)
#define DAVINCI_MCBSP_RCR_RFIG (1 18)
#define DAVINCI_MCBSP_RCR_RWDLEN2(v) ((v) 21)
+#define DAVINCI_MCBSP_RCR_RFRLEN2(v) ((v) 24)
+#define DAVINCI_MCBSP_RCR_RPHASE (1 31)
#define DAVINCI_MCBSP_XCR_XWDLEN1(v) ((v) 5)
#define DAVINCI_MCBSP_XCR_XFRLEN1(v) ((v) 8)
#define DAVINCI_MCBSP_XCR_XDATDLY(v) ((v) 16)
#define DAVINCI_MCBSP_XCR_XFIG (1 18)
#define DAVINCI_MCBSP_XCR_XWDLEN2(v) ((v) 21)
+#define DAVINCI_MCBSP_XCR_XFRLEN2(v) ((v) 24)
+#define DAVINCI_MCBSP_XCR_XPHASE (1 31)
#define DAVINCI_MCBSP_SRGR_FWID(v) ((v) 8)
#define DAVINCI_MCBSP_SRGR_FPER(v) ((v) 16)
#define DAVINCI_MCBSP_SRGR_FSGM(1 28)
+#define DAVINCI_MCBSP_SRGR_CLKSM (1 29)
#define DAVINCI_MCBSP_PCR_CLKRP(1 0)
#define DAVINCI_MCBSP_PCR_CLKXP(1 1)
@@ -144,6 +149,9 @@ struct davinci_mcbsp_dev {
* won't end up being swapped because of the underrun.
*/
unsigned enable_channel_combine:1;
+
+ unsigned int fmt;
+ int clk_div;
};
static inline void davinci_mcbsp_write_reg(struct davinci_mcbsp_dev *dev,
@@ -254,10 +262,12 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
struct davinci_mcbsp_dev *dev = cpu_dai-private_data;
unsigned int pcr;
unsigned int srgr;
+ /* Attention srgr is updated by hw_params! */
srgr = DAVINCI_MCBSP_SRGR_FSGM |
DAVINCI_MCBSP_SRGR_FPER(DEFAULT_BITPERSAMPLE * 2 - 1) |
DAVINCI_MCBSP_SRGR_FWID(DEFAULT_BITPERSAMPLE - 1);
+ dev-fmt = fmt;
/* set master/slave audio interface */
switch (fmt SND_SOC_DAIFMT_MASTER_MASK) {
case SND_SOC_DAIFMT_CBS_CFS:
@@ -372,6 +382,16 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
return 0;
}
+static int davinci_i2s_dai_set_clkdiv(struct snd_soc_dai *cpu_dai,
+ int div_id, int div)
+{
+ struct davinci_mcbsp_dev *dev = cpu_dai-private_data;
+ int srgr;
+
+ dev-clk_div = div;
+ return 0;
+}
+
static int davinci_i2s_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
@@ -380,8 +400,8 @@ static int davinci_i2s_hw_params(struct snd_pcm_substream
*substream,
struct davinci_pcm_dma_params *dma_params =
dev-dma_params[substream-stream];
struct snd_interval *i = NULL;
- int mcbsp_word_length;
- unsigned int rcr, xcr, srgr;
+ int mcbsp_word_length, master;
+ unsigned int rcr, xcr, srgr, clk_div, freq, framesize;
u32 spcr;
snd_pcm_format_t fmt;
unsigned element_cnt = 1;
@@ -396,12 +416,44 @@ static int davinci_i2s_hw_params(struct snd_pcm_substream
*substream,
davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SPCR_REG, spcr);
}
- i = hw_param_interval(params, SNDRV_PCM_HW_PARAM_SAMPLE_BITS);
- srgr = DAVINCI_MCBSP_SRGR_FSGM;
- srgr |= DAVINCI_MCBSP_SRGR_FWID(snd_interval_value(i) - 1);
+ master = dev-fmt SND_SOC_DAIFMT_MASTER_MASK;
+ fmt = params_format(params);
+ mcbsp_word_length = asp_word_length[fmt];
- i = hw_param_interval(params, SNDRV_PCM_HW_PARAM_FRAME_BITS);
- srgr |= DAVINCI_MCBSP_SRGR_FPER(snd_interval_value(i) - 1);
+ switch (master) {
+ case SND_SOC_DAIFMT_CBS_CFS:
+ freq = clk_get_rate(dev-clk);
+ srgr = DAVINCI_MCBSP_SRGR_FSGM |
+ DAVINCI_MCBSP_SRGR_CLKSM;
+ srgr |= DAVINCI_MCBSP_SRGR_FWID(mcbsp_word_length *
+
[PATCH 2/3] ASoC: DaVinci: Added selection of clk input pin for McBSP
From: Raffaele Recalcati raffaele.recalc...@bticino.it
When McBSP peripheral gets the clock from an external pin,
there are three possible chooses, MCBSP_CLKX, MCBSP_CLKR
and MCBSP_CLKS.
evm-dm365 uses MCBSP_CLKR, instead in bmx board I have a different
hardware connection and I use MCBSP_CLKS, so I have added
this possibility.
This patch has been developed against the:
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
git tree and has been tested on bmx board (similar to dm365 evm)
Signed-off-by: Raffaele Recalcati raffaele.recalc...@bticino.it
Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it
---
arch/arm/mach-davinci/include/mach/asp.h |8
sound/soc/davinci/davinci-i2s.c | 28 +++-
2 files changed, 31 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/asp.h
b/arch/arm/mach-davinci/include/mach/asp.h
index 834725f..314570d 100644
--- a/arch/arm/mach-davinci/include/mach/asp.h
+++ b/arch/arm/mach-davinci/include/mach/asp.h
@@ -63,6 +63,9 @@ struct snd_platform_data {
unsigned sram_size_playback;
unsigned sram_size_capture;
+ /* To be used when cpu gets clock from external pin */
+ int clk_input_pin;
+
/* McASP specific fields */
int tdm_slots;
u8 op_mode;
@@ -78,6 +81,11 @@ enum {
MCASP_VERSION_2,/* DA8xx/OMAPL1x */
};
+enum {
+ MCBSP_CLKR = 0, /* DM365 */
+ MCBSP_CLKS,
+};
+
#define INACTIVE_MODE 0
#define TX_MODE1
#define RX_MODE2
diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c
index 319e8ca..e478be9 100644
--- a/sound/soc/davinci/davinci-i2s.c
+++ b/sound/soc/davinci/davinci-i2s.c
@@ -152,6 +152,7 @@ struct davinci_mcbsp_dev {
unsigned int fmt;
int clk_div;
+ int clk_input_pin;
};
static inline void davinci_mcbsp_write_reg(struct davinci_mcbsp_dev *dev,
@@ -278,11 +279,26 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
DAVINCI_MCBSP_PCR_CLKRM;
break;
case SND_SOC_DAIFMT_CBM_CFS:
- /* McBSP CLKR pin is the input for the Sample Rate Generator.
-* McBSP FSR and FSX are driven by the Sample Rate Generator. */
- pcr = DAVINCI_MCBSP_PCR_SCLKME |
- DAVINCI_MCBSP_PCR_FSXM |
- DAVINCI_MCBSP_PCR_FSRM;
+ pcr = DAVINCI_MCBSP_PCR_FSRM | DAVINCI_MCBSP_PCR_FSXM;
+ /*
+* Selection of the clock input pin that is the
+* input for the Sample Rate Generator.
+* McBSP FSR and FSX are driven by the Sample Rate
+* Generator.
+*/
+ switch (dev-clk_input_pin) {
+ case MCBSP_CLKS:
+ pcr |= DAVINCI_MCBSP_PCR_CLKXM |
+ DAVINCI_MCBSP_PCR_CLKRM;
+ break;
+ case MCBSP_CLKR:
+ pcr |= DAVINCI_MCBSP_PCR_SCLKME;
+ break;
+ default:
+ printk(KERN_ERR %s:bad clk_input_pin\n, __func__);
+ return -EINVAL;
+ }
+
break;
case SND_SOC_DAIFMT_CBM_CFM:
/* codec is master */
@@ -436,6 +452,7 @@ static int davinci_i2s_hw_params(struct snd_pcm_substream
*substream,
srgr |= clk_div;
break;
case SND_SOC_DAIFMT_CBM_CFS:
+ /* Clock given on CLKS */
srgr = DAVINCI_MCBSP_SRGR_FSGM;
clk_div = dev-clk_div - 1;
srgr |= DAVINCI_MCBSP_SRGR_FWID(mcbsp_word_length * 8 - 1);
@@ -626,6 +643,7 @@ static int davinci_i2s_probe(struct platform_device *pdev)
pdata-sram_size_playback;
dev-dma_params[SNDRV_PCM_STREAM_CAPTURE].sram_size =
pdata-sram_size_capture;
+ dev-clk_input_pin = pdata-clk_input_pin;
}
dev-clk = clk_get(pdev-dev, NULL);
if (IS_ERR(dev-clk)) {
--
1.7.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH 02/33] Removing dead ARCH_DAVINCI_TNETV107X
On Wed, Jun 30, 2010 at 08:07:31PM +0300, Baruch Siach wrote: Hi Christoph, On Wed, Jun 30, 2010 at 06:05:38PM +0200, Christoph Egger wrote: ARCH_DAVINCI_TNETV107X doesn't exist in Kconfig, therefore removing all references for it from the source code. Signed-off-by: Christoph Egger sicce...@cs.fau.de --- arch/arm/mach-davinci/include/mach/cputype.h |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-davinci/include/mach/cputype.h b/arch/arm/mach-davinci/include/mach/cputype.h index cea6b89..6143022 100644 --- a/arch/arm/mach-davinci/include/mach/cputype.h +++ b/arch/arm/mach-davinci/include/mach/cputype.h @@ -85,10 +85,4 @@ IS_DAVINCI_CPU(tnetv107x, DAVINCI_CPU_ID_TNETV107X) #define cpu_is_davinci_da850() 0 #endif -#ifdef CONFIG_ARCH_DAVINCI_TNETV107X -#define cpu_is_davinci_tnetv107x() is_davinci_tnetv107x() -#else -#define cpu_is_davinci_tnetv107x() 0 Why remove the #else part? Nobody uses cpu_is_davinci_tnetv107x as well. Acked-by: Kirill A. Shutemov kir...@shutemov.name -- Kirill A. Shutemov ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 02/33] Removing dead ARCH_DAVINCI_TNETV107X
ARCH_DAVINCI_TNETV107X doesn't exist in Kconfig, therefore removing all references for it from the source code. Signed-off-by: Christoph Egger sicce...@cs.fau.de --- arch/arm/mach-davinci/include/mach/cputype.h |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-davinci/include/mach/cputype.h b/arch/arm/mach-davinci/include/mach/cputype.h index cea6b89..6143022 100644 --- a/arch/arm/mach-davinci/include/mach/cputype.h +++ b/arch/arm/mach-davinci/include/mach/cputype.h @@ -85,10 +85,4 @@ IS_DAVINCI_CPU(tnetv107x, DAVINCI_CPU_ID_TNETV107X) #define cpu_is_davinci_da850() 0 #endif -#ifdef CONFIG_ARCH_DAVINCI_TNETV107X -#define cpu_is_davinci_tnetv107x() is_davinci_tnetv107x() -#else -#define cpu_is_davinci_tnetv107x() 0 -#endif - #endif -- 1.7.0.4 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH 00/33] Removing dead code
Hi all!
As part of the VAMOS[0] research project at the University of
Erlangen we are looking at multiple integrity errors in linux'
configuration system.
I've been running a check on the arch/arm sourcetree for
config Items not defined in Kconfig and found 33 such cases. Sourcecode
blocks depending on these Items are not reachable from a vanilla
kernel -- dead code. I've seen such dead blocks made on purpose
e.g. while integrating new features into the kernel but generally
they're just useless.
Each of the patches in this patchset removes on such dead
config Item, I'd be glad if you consider applying them. I've been
doing deeper analysis of such issues before and can do so again but
I'm not so sure they were fastly usefull. Unfortunately arm doesn't
allow some allyesconfig build covering all of that code so I couldn't
build-test all of them, sorry for that.
Please keep me informed of this patch getting confirmed /
merged so we can keep track of it.
Regards
Christoph Egger
[0] http://vamos1.informatik.uni-erlangen.de/
Christoph Egger (33):
Removing dead MTD_NAND_AT91_BUSWIDTH_16
Removing dead ARCH_DAVINCI_TNETV107X
Removing dead OMAP_MUX_ERRORS
Removing dead MSM7X00A_IDLE
Removing dead OMAP_IR
Removing dead SHARPSL_LOCOMO
Removing dead CPU_S3C2400
Removing dead SA1101
Removing dead MAGICV
Removing dead VIDEO_AT91_ISI
Removing dead OMAP_DSP
Removing dead OMAP_STI
Replacing LEDS_OMAP_DEBUG with OMAP_DEBUG_LEDS
Removing dead SDMA_IRAM
Removing dead PROCESSOR_NS9750
Removing dead APM
Removing dead SX1_OLD_FLASH
Removing dead OMAP_ARM_96MHZ
Removing dead MACH_OMAP_H4_OTG
Removing dead MACH_OMAP2_H4_USB1
Removing dead OMAP2_VENC_OUT_TYPE_SVIDEO,
OMAP2_VENC_OUT_TYPE_COMPOSITE
Removing dead MPU_{BRIDGE,TESLA}_IOMMU
Removing dead BACKLIGHT_CORGI
Removing dead ARCH_GUMSTIX_ORIG
Removing dead CORGI_SSP_DEPRECATED
Removing dead XSCALE_CACHE_ERRATA
Removing dead IDE_PXA_CF
Removing dead CPU_S3C24XX
Removing dead SND_SOC_SMDK2443_WM9710
Removing dead S3C_DEV_ADC
Removing dead MACH_U300_BS26
Removing dead CPU_ICACHE_STREAMING_DISABLE
Removing dead MACH_U300_USE_I2S_AS_MASTER
arch/arm/mach-at91/at572d940hf_devices.c | 73 --
arch/arm/mach-at91/at91sam9263_devices.c | 49 --
arch/arm/mach-at91/board-at572d940hf_ek.c |4 -
arch/arm/mach-at91/board-sam9m10g45ek.c|4 -
arch/arm/mach-davinci/include/mach/cputype.h |6 -
arch/arm/mach-msm/idle.S | 13 -
arch/arm/mach-ns9xxx/gpio.c|8 -
arch/arm/mach-omap1/board-h2.c | 18 -
arch/arm/mach-omap1/board-nokia770.c | 132
arch/arm/mach-omap1/board-palmte.c | 84 ---
arch/arm/mach-omap1/board-sx1.c| 26 -
arch/arm/mach-omap1/devices.c | 72 --
arch/arm/mach-omap1/mcbsp.c|3 -
arch/arm/mach-omap1/mux.c |5 -
arch/arm/mach-omap1/opp_data.c |3 -
arch/arm/mach-omap2/board-h4.c | 26 -
arch/arm/mach-omap2/board-omap3stalker.c |5 -
arch/arm/mach-omap2/devices.c | 57 --
arch/arm/mach-omap2/omap-iommu.c | 22 -
arch/arm/mach-pxa/corgi_pm.c |2 -
arch/arm/mach-pxa/include/mach/gumstix.h | 12 +-
arch/arm/mach-pxa/sharpsl_pm.c | 20 -
arch/arm/mach-pxa/sleep.S |7 -
arch/arm/mach-pxa/spitz_pm.c |2 -
arch/arm/mach-pxa/trizeps4.c |6 +-
arch/arm/mach-s3c2410/include/mach/gpio-fns.h |5 -
arch/arm/mach-s3c2410/include/mach/gpio.h |4 -
arch/arm/mach-s3c2410/include/mach/regs-gpio.h |4 -
arch/arm/mach-s3c2443/mach-smdk2443.c |7 -
arch/arm/mach-s5pv210/cpu.c|4 -
arch/arm/mach-sa1100/include/mach/SA-1101.h| 925
arch/arm/mach-sa1100/include/mach/hardware.h |4 -
arch/arm/mach-sa1100/include/mach/irqs.h |2 -
arch/arm/mach-u300/clock.c | 91 ---
arch/arm/mach-u300/core.c |7 -
arch/arm/mm/proc-arm925.S |3 -
arch/arm/plat-mxc/include/mach/mx51.h |4 -
arch/arm/plat-omap/Kconfig |2 +-
arch/arm/plat-omap/debug-leds.c|2 +-
arch/arm/plat-omap/devices.c | 62 --
arch/arm/plat-omap/include/plat/dsp_common.h | 40 -
arch/arm/plat-s3c24xx/cpu.c| 15 -
arch/arm/plat-s3c24xx/include/plat/s3c2400.h | 31 -
43 files changed, 4 insertions(+), 1867 deletions(-)
delete mode 100644 arch/arm/mach-sa1100/include/mach/SA-1101.h
delete mode 100644 arch/arm/plat-omap/include/plat/dsp_common.h
delete mode 100644 arch/arm/plat-s3c24xx/include/plat/s3c2400.h
Re: [PATCH 02/33] Removing dead ARCH_DAVINCI_TNETV107X
Hi Christoph,
On Wed, Jun 30, 2010 at 06:05:38PM +0200, Christoph Egger wrote:
ARCH_DAVINCI_TNETV107X doesn't exist in Kconfig, therefore removing
all references for it from the source code.
Signed-off-by: Christoph Egger sicce...@cs.fau.de
---
arch/arm/mach-davinci/include/mach/cputype.h |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/cputype.h
b/arch/arm/mach-davinci/include/mach/cputype.h
index cea6b89..6143022 100644
--- a/arch/arm/mach-davinci/include/mach/cputype.h
+++ b/arch/arm/mach-davinci/include/mach/cputype.h
@@ -85,10 +85,4 @@ IS_DAVINCI_CPU(tnetv107x, DAVINCI_CPU_ID_TNETV107X)
#define cpu_is_davinci_da850() 0
#endif
-#ifdef CONFIG_ARCH_DAVINCI_TNETV107X
-#define cpu_is_davinci_tnetv107x() is_davinci_tnetv107x()
-#else
-#define cpu_is_davinci_tnetv107x() 0
Why remove the #else part?
baruch
-#endif
-
#endif
--
1.7.0.4
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
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] ASoC: DaVinci: Added support for cpu clocking I2S
On Wed, Jun 30, 2010 at 10:17:40AM +0200, Raffaele Recalcati wrote:
2010/6/28 Mark Brown broo...@opensource.wolfsonmicro.com
It's still very hard to understand what this patch is supposed to do.
As previously mentioned this would probably be a lot clearer if you
split this into multiple patches, for example one adding support for the
fast clock mode, one adding support for selecting the pin used for any
external clock and then further patches with any other changes.
Looking at other paches, they are simpler than mine.
The big problem is you're just making some general (and not particularly
clear) statements about features without saying anything concrete about
what the patch actually does - is there a bug being fixed, a feature
implemented, or what?
Added audio playback support with [frame sync master - clock master]
mode
and with [frame sync master - clock slave].
What are these modes - which clock are you talking about?
McBSP i2s interface to external codec.
Perhaps you mean the bit clock on the I2S interface? There are multiple
clocks on the actual I2S link itself, and often people lump in the
master clock for the I2S interface into the interface itself.
i2s_fast_clock switch can be used to have better approximate or
symmetric waveforms.
Why would someone choose not to use this?
I was not sure if symmetric waveform can be a must.
In general I think it is better a non symmetric, but better approximate,
waveform.
Anyway, it is better to have the possibility to choose in my opinion,
because I have not so much experience in i2s communication.
If I understand this correctly when you say approximate what you mean
is approximate clock rate so the tradeoff is between the accuracy of
the rate generated and the duty cycle of the output signal?
+ /* To be used when cpu gets clock from extenal pin */
+ int clk_input_pin;
How would one use this?
looking at 2.5 Clock, Frames, and Data in
you can select MCBSP_CLKS or other input clock pins.
You need to put this in the comments.
+static int davinci_i2s_dai_set_clkdiv(struct snd_soc_dai *cpu_dai,
+ int div_id, int div)
+{
+ struct davinci_mcbsp_dev *dev = cpu_dai-private_data;
+ int srgr;
+
+ dev-clk_div = div;
+ return 0;
+}
I would add a clock ID here in case someone wants to configure another
clock in the patch.
Can you explain better,
please?
You need to require a value for div_id.
I'd also expect this to be doing a clk_get() using the struct device for
the DAI so that the driver can function even if the clock tree for a new..
SoC is different.
Sorry, I don't understand, can you explain me better?
clk_get() takes two parameters, a struct device and a name. You should
be using a clock specified in terms of a particular device, not one with
a NULL pointer for the struct device.
+ freq = 12200; /* FIXME ask to Texas */
...this presumably ought to be in an else clause (or perhaps just not
using this clocking at all if you can't find the clock?).
freq is used to obtain clk_div.
The real problem is that, as explained in the manual, it is not clear its
value.
I hope someone can help!!
I would very strongly expect that the division would be from the clock
rate of the source clock which you can obtain by using clk_get().
___
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/3] ASoC: DaVinci: Added selection of clk input pin for McBSP
On Wed, Jun 30, 2010 at 03:47:57PM +0200, Raffaele Recalcati wrote: + /* To be used when cpu gets clock from external pin */ + int clk_input_pin; + As previously indicated please say how to use this. + default: + printk(KERN_ERR %s:bad clk_input_pin\n, __func__); Use dev_err(). ___ 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 02/33] Removing dead ARCH_DAVINCI_TNETV107X
Christoph Egger sicce...@cs.fau.de writes: ARCH_DAVINCI_TNETV107X doesn't exist in Kconfig, therefore removing all references for it from the source code. Signed-off-by: Christoph Egger sicce...@cs.fau.de Please leave this define in. The full support for this platform is currently in linux-next and will be merged for 2.6.36. 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] spi: davinci: Added support for chip select using gpio
On Mon, Jun 28, 2010 at 12:47 AM, Raffaele Recalcati
lamiapost...@gmail.com wrote:
From: Raffaele Recalcati raffaele.recalc...@bticino.it
It is not everytime possible, due to hardware constraints,
to use the hw chip select available on spi port.
So I add this possibility using a gpio as chip select.
If controller_data variable is not null it is
the gpio to be used as chip select.
The default case is compatible with evmdm365.
This patch has been developed against the
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
git tree and has been tested on bmx board (similar to dm365 evm but with
gpio as spi chip select).
Signed-off-by: Raffaele Recalcati raffaele.recalc...@bticino.it
Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it
The davinci SPI driver is getting completely replaced (as soon as I
receive the respun patches), and I assume this patch will no longer
apply after the fact, so I'm not going to pick this patch up. You
should coordinate with Brian Niebuhr to get this feature into his new
driver.
Cheers,
g.
---
arch/arm/mach-davinci/dm365.c | 10 ++
drivers/spi/davinci_spi.c | 27 ++-
2 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index a146849..42fd4a4 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -677,10 +677,12 @@ void __init dm365_init_spi0(unsigned chipselect_mask,
davinci_cfg_reg(DM365_SPI0_SDO);
/* not all slaves will be wired up */
- if (chipselect_mask BIT(0))
- davinci_cfg_reg(DM365_SPI0_SDENA0);
- if (chipselect_mask BIT(1))
- davinci_cfg_reg(DM365_SPI0_SDENA1);
+ if (!((unsigned long) info-controller_data)) {
+ if (chipselect_mask BIT(0))
+ davinci_cfg_reg(DM365_SPI0_SDENA0);
+ if (chipselect_mask BIT(1))
+ davinci_cfg_reg(DM365_SPI0_SDENA1);
+ }
spi_register_board_info(info, len);
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 95afb6b..621ae46 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -29,6 +29,7 @@
#include linux/spi/spi_bitbang.h
#include linux/slab.h
+#include mach/gpio.h
#include mach/spi.h
#include mach/edma.h
@@ -270,18 +271,26 @@ static void davinci_spi_chipselect(struct spi_device
*spi, int value)
pdata = davinci_spi-pdata;
/*
- * Board specific chip select logic decides the polarity and cs
- * line for the controller
- */
+ * Board specific chip select logic decides the polarity and cs
+ * line for the controller
+ */
if (value == BITBANG_CS_INACTIVE) {
- set_io_bits(davinci_spi-base + SPIDEF, CS_DEFAULT);
-
- data1_reg_val |= CS_DEFAULT SPIDAT1_CSNR_SHIFT;
- iowrite32(data1_reg_val, davinci_spi-base + SPIDAT1);
-
+ if ((unsigned long) spi-controller_data) {
+ gpio_set_value(spi-controller_data, \
+ !(spi-mode SPI_CS_HIGH));
+ } else {
+ set_io_bits(davinci_spi-base + SPIDEF, CS_DEFAULT);
+
+ data1_reg_val |= CS_DEFAULT SPIDAT1_CSNR_SHIFT;
+ iowrite32(data1_reg_val, davinci_spi-base + SPIDAT1);
+ }
while ((ioread32(davinci_spi-base + SPIBUF)
- SPIBUF_RXEMPTY_MASK) == 0)
+ SPIBUF_RXEMPTY_MASK) == 0)
cpu_relax();
+ } else {
+ if ((unsigned long) spi-controller_data)
+ gpio_set_value(spi-controller_data, \
+ (spi-mode SPI_CS_HIGH));
}
}
--
1.7.0.4
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Rif: Re: [PATCH] spi: davinci: Added support for chip select using gpio
-glik...@secretlab.ca ha scritto: -
Per: Raffaele Recalcati lamiapost...@gmail.com, Brian Niebuhr
bniebu...@gmail.com
Da: Grant Likely grant.lik...@secretlab.ca
Inviato da: glik...@secretlab.ca
Data: 01/07/2010 01.03
Cc: davinci-linux-open-sou...@linux.davincidsp.com, Raffaele
Recalcati raffaele.recalc...@bticino.it, Davide Bonfanti
davide.bonfa...@bticino.it, Russell King li...@arm.linux.org.uk,
Sandeep Paulraj s-paul...@ti.com, Cyril Chemparathy cy...@ti.com,
Miguel Aguilar miguel.agui...@ridgerun.com, Thomas Koeller
thomas.koel...@baslerweb.com, David Brownell
dbrown...@users.sourceforge.net, Philby John pj...@in.mvista.com,
Sudhakar Rajashekhara sudhakar@ti.com,
linux-arm-ker...@lists.infradead.org, linux-ker...@vger.kernel.org,
spi-devel-gene...@lists.sourceforge.net
Oggetto: Re: [PATCH] spi: davinci: Added support for chip select
using gpio
On Mon, Jun 28, 2010 at 12:47 AM, Raffaele Recalcati
lamiapost...@gmail.com wrote:
From: Raffaele Recalcati raffaele.recalc...@bticino.it
It is not everytime possible, due to hardware constraints,
to use the hw chip select available on spi port.
So I add this possibility using a gpio as chip select.
If controller_data variable is not null it is
the gpio to be used as chip select.
The default case is compatible with evmdm365.
This patch has been developed against the
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.
git
git tree and has been tested on bmx board (similar to dm365 evm
but with
gpio as spi chip select).
Signed-off-by: Raffaele Recalcati raffaele.recalc...@bticino.it
Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it
The davinci SPI driver is getting completely replaced (as soon as I
receive the respun patches), and I assume this patch will no longer
apply after the fact, so I'm not going to pick this patch up. You
should coordinate with Brian Niebuhr to get this feature into his new
driver.
I'm not very lucky with davinci-linux-open-source patching.
Thank you for the information.
The patch is really simple and so it will be not a real problem to up port
it.
I'd like anyway a timing roadmap, because,
if now the best kernel choose for dm365 is surely
http://arago-project.org/git/projects/linux-davinci.git
because of dvsdk (video codec) compatibility,
it is possible that next year 2.6.36 will be stable and compatible to dvsdk
(video codec).
The kernel of dm365 (that is a video processor) has to be compatible to its
video codec.
How to manage the transition?
Cheers,
g.
---
arch/arm/mach-davinci/dm365.c | 10 ++
drivers/spi/davinci_spi.c | 27 ++-
2 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-davinci/dm365.c
b/arch/arm/mach-davinci/dm365.c
index a146849..42fd4a4 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -677,10 +677,12 @@ void __init dm365_init_spi0(unsigned
chipselect_mask,
davinci_cfg_reg(DM365_SPI0_SDO);
/* not all slaves will be wired up */
- if (chipselect_mask BIT(0))
- davinci_cfg_reg(DM365_SPI0_SDENA0);
- if (chipselect_mask BIT(1))
- davinci_cfg_reg(DM365_SPI0_SDENA1);
+ if (!((unsigned long) info-controller_data)) {
+ if (chipselect_mask BIT(0))
+ davinci_cfg_reg(DM365_SPI0_SDENA0);
+ if (chipselect_mask BIT(1))
+ davinci_cfg_reg(DM365_SPI0_SDENA1);
+ }
spi_register_board_info(info, len);
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 95afb6b..621ae46 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -29,6 +29,7 @@
#include linux/spi/spi_bitbang.h
#include linux/slab.h
+#include mach/gpio.h
#include mach/spi.h
#include mach/edma.h
@@ -270,18 +271,26 @@ static void davinci_spi_chipselect(struct
spi_device *spi, int value)
pdata = davinci_spi-pdata;
/*
-* Board specific chip select logic decides the polarity
and cs
-* line for the controller
-*/
+ * Board specific chip select logic decides the polarity and
cs
+ * line for the controller
+ */
if (value == BITBANG_CS_INACTIVE) {
- set_io_bits(davinci_spi-base + SPIDEF,
CS_DEFAULT);
-
- data1_reg_val |= CS_DEFAULT SPIDAT1_CSNR_SHIFT;
- iowrite32(data1_reg_val, davinci_spi-base +
SPIDAT1);
-
+ if ((unsigned long) spi-controller_data) {
+ gpio_set_value(spi-controller_data, \
+ !(spi-mode SPI_CS_HIGH));
+ } else {
+ set_io_bits(davinci_spi-base + SPIDEF,
CS_DEFAULT);
+
+ data1_reg_val |= CS_DEFAULT
SPIDAT1_CSNR_SHIFT;
+ iowrite32(data1_reg_val, davinci_spi-base
+ SPIDAT1);
+ }
Re: [PATCH 3/3] ASoC: DaVinci: Added fast clock timing for McBSP (I2S)
On Wed, Jun 30, 2010 at 03:47:58PM +0200, Raffaele Recalcati wrote: From: Raffaele Recalcati raffaele.recalc...@bticino.it i2s_fast_clock switch can be used to have a better approximate Oh, and please look at the CC list for these posts. You're CCing *very* widely and at least one address (chaithr...@ti.com) actually bounces. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Rif: Re: [PATCH 1/3] ASoC: DaVinci: Added two clocking possibilities to McBSP (I2S)
-Mark Brown broo...@opensource.wolfsonmicro.com ha scritto: - Per: Raffaele Recalcati lamiapost...@gmail.com Da: Mark Brown broo...@opensource.wolfsonmicro.com Data: 04/07/2010 11.15 Cc: davinci-linux-open-sou...@linux.davincidsp.com, Raffaele Recalcati raffaele.recalc...@bticino.it, Davide Bonfanti davide.bonfa...@bticino.it, ...@slimlogic.co.uk Oggetto: Re: [PATCH 1/3] ASoC: DaVinci: Added two clocking possibilities to McBSP (I2S) On Fri, Jul 02, 2010 at 07:12:25PM +0200, Raffaele Recalcati wrote: From: Raffaele Recalcati raffaele.recalc...@bticino.it Added two clocking options for dm365 McBSP peripheral when used with I2S timings, that are SND_SOC_DAIFMT_CBS_CFS (the cpu generates You've not sent any of these patches to the ALSA list or to Liam Girdwood, the other ASoC maintainer. In general you should be looking to include at least the subsystem maintainers and mailing list for the relevant code, anyone who actively works on the driver and possibly an architecture-specific list. ok, but, first I was using scripts/get_maintainer.pl, but it created a too long cc list. thinking anyway, if get_mantainer is not right, it is better to fix it, instead of guessing who to send the patches to. So I'll use this -cc list from the script. scripts/get_maintainer.pl -f sound/soc/davinci/davinci-i2s.c Liam Girdwood l...@slimlogic.co.uk Mark Brown broo...@opensource.wolfsonmicro.com Jaroslav Kysela pe...@perex.cz Takashi Iwai ti...@suse.de Troy Kisky troy.ki...@boundarydevices.com Raffaele Recalcati raffaele.recalc...@bticino.it Davide Bonfanti davide.bonfa...@bticino.it alsa-de...@alsa-project.org linux-ker...@vger.kernel.org The first two patches look OK, though I'd like to see some DaVinci people confirming they're OK. I hope they answer. Raffaele Recalcati Driver Linux BSP Bticino S.p.A. Via L.Manara 4, Erba (CO), Italy Tel: +39.(0)31.653.252 Tel2: +39.(0)31.653.652 Fax: +39.(0)31.653.283 E-mail: raffaele.recalc...@bticino.it Web: www.bticino.it Bticino Legrand Zucchini Cablofil Ortronics Ce message, ainsi que tous les fichiers joints à ce message, peuvent contenir des informations sensibles et/ ou confidentielles ne devant pas être divulguées. Si vous n'êtes pas le destinataire de ce message (ou que vous recevez ce message par erreur), nous vous remercions de le notifier immédiatement à son expéditeur, et de détruire ce message. Toute copie, divulgation, modification, utilisation ou diffusion, non autorisée, directe ou indirecte, de tout ou partie de ce message, est strictement interdite. This e-mail, and any document attached hereby, may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized, direct or indirect, copying, disclosure, distribution or other use of the material or parts thereof is strictly forbidden. ___ 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/3] ASoC: DaVinci: Added fast clock timing for McBSP (I2S)
On Wed, Jun 30, 2010 at 03:47:58PM +0200, Raffaele Recalcati wrote:
+ /*
+ * This define works when both clock and FS are output for the cpu
+ * and makes clock very fast (FS is not symmetrical, but sampling
+ * frequency is better approximated
+ */
+ bool i2s_fast_clock;
I'm having a hard time following the description here - which clock is
being made very fast? The output clocks, which are the ones people can
observe, will presumably not suddenly start running very fast.
It's probably better to rename this option to reflect the actual
function (trading off between frequency accuracy and mark/space ratio)
rather than the way it's implemented internally.
- srgr |= DAVINCI_MCBSP_SRGR_FPER(mcbsp_word_length *
- 16 - 1);
+ if (dev-i2s_fast_clock) {
+ clk_div = 256;
+ do {
+ framesize = (freq / (--clk_div)) /
+ params-rate_num *
+ params-rate_den;
+ } while (((framesize 33) || (framesize 4095))
+ (clk_div));
+ clk_div--;
+ srgr |= DAVINCI_MCBSP_SRGR_FPER(framesize - 1);
+ } else {
+ /* symmetric waveforms */
+ clk_div = freq / (mcbsp_word_length * 16) /
+ params-rate_num * params-rate_den;
+ srgr |= DAVINCI_MCBSP_SRGR_FPER(mcbsp_word_length *
+ 16 - 1);
+ }
Hrm. This doesn't really correspond to your commit message at all.
Your commit message makes it sound like you've changed something about
the clocking setup of the device, such as adding another clock source,
but what you've actually done here is change the method used to
calculate the divider.
I'm *guessing* that the actual effect of your change is that you will
normally end up selecting a very much higher bit clock than would
otherwise be the case. It strikes me that there must be a better
algorithm for the calculation - for example, working up from the minimum
clock rate - which will give the same results as we currently have where
the driver is already generating accurate rates.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH] ASoC: DaVinci: More accurate calculation for clock divider for McBSP (I2S)
From: Raffaele Recalcati raffaele.recalc...@bticino.it
i2s_accurate_sck switch can be used to have a better approximate
sampling frequency.
The trade off is between more accurate clock (fast clock)
and less accurate clock (slow clock).
The waveform will be not symmetric.
Probably it is possible to get a better algorithm for calculating
the divider, trying to keep a slower clock as possible.
This patch has been developed against the
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
git tree and has been tested on bmx board (similar to dm365 evm, but using
uda1345 as external audio codec).
Signed-off-by: Raffaele Recalcati raffaele.recalc...@bticino.it
Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it
---
arch/arm/mach-davinci/include/mach/asp.h | 33 ++
sound/soc/davinci/davinci-i2s.c | 28 -
2 files changed, 55 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/asp.h
b/arch/arm/mach-davinci/include/mach/asp.h
index 0847d21..5149abe 100644
--- a/arch/arm/mach-davinci/include/mach/asp.h
+++ b/arch/arm/mach-davinci/include/mach/asp.h
@@ -73,6 +73,39 @@ struct snd_platform_data {
*/
int clk_input_pin;
+ /*
+* This flag works when both clock and FS are outputs for the cpu
+* and makes clock more accurate (FS is not symmetrical and the
+* clock is very fast.
+* The clock becoming faster is named
+* i2s continuous serial clocl (I2S_SCK) and it is an externally
+* visible bit clock.
+*
+* first line : WordSelect
+* second line : ContinuousSerialClock
+* third line: SerialData
+*
+* SYMMETRICAL APPROACH:
+* ___ LEFT
+* _| RIGHT |__|
+* _ _ _ _ _ _ _ _
+* _| |_| |_ x16 _| |_| |_| |_| |_ x16 _| |_| |_
+* _ _ _ _ _ _ _ _
+* _/ \_/ \_ ... _/ \_/ \_/ \_/ \_ ... _/ \_/ \_
+*\_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/
+*
+* ACCURATE CLOCK APPROACH:
+* __ LEFT
+* _| RIGHT|___|
+* _ _ _ _ _ _ _ _ _
+* _| |_ x16 _| |_| |_ x16 _| |_| |_| |_| |_| |_| |
+* _ _ _ _ dummy cycles
+* _/ \_ ... _/ \_/ \_ ... _/ \__
+*\_/ \_/ \_/\_/
+*
+*/
+ bool i2s_accurate_sck;
+
/* McASP specific fields */
int tdm_slots;
u8 op_mode;
diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c
index 17f594f..e6dcd81 100644
--- a/sound/soc/davinci/davinci-i2s.c
+++ b/sound/soc/davinci/davinci-i2s.c
@@ -122,6 +122,7 @@ static const unsigned char
double_fmt[SNDRV_PCM_FORMAT_S32_LE + 1] = {
};
struct davinci_mcbsp_dev {
+ struct device *dev;
struct davinci_pcm_dma_params dma_params[2];
void __iomem*base;
#define MOD_DSP_A 0
@@ -154,6 +155,7 @@ struct davinci_mcbsp_dev {
unsigned int fmt;
int clk_div;
int clk_input_pin;
+ bool i2s_accurate_sck;
};
static inline void davinci_mcbsp_write_reg(struct davinci_mcbsp_dev *dev,
@@ -296,7 +298,7 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
pcr |= DAVINCI_MCBSP_PCR_SCLKME;
break;
default:
- dev_err(pdev-dev, bad clk_input_pin\n);
+ dev_err(dev-dev, bad clk_input_pin\n);
return -EINVAL;
}
@@ -447,11 +449,23 @@ static int davinci_i2s_hw_params(struct snd_pcm_substream
*substream,
DAVINCI_MCBSP_SRGR_CLKSM;
srgr |= DAVINCI_MCBSP_SRGR_FWID(mcbsp_word_length *
8 - 1);
- /* symmetric waveforms */
- clk_div = freq / (mcbsp_word_length * 16) /
- params-rate_num * params-rate_den;
- srgr |= DAVINCI_MCBSP_SRGR_FPER(mcbsp_word_length *
- 16 - 1);
+ if (dev-i2s_accurate_sck) {
+ clk_div = 256;
+ do {
+ framesize = (freq / (--clk_div)) /
+ params-rate_num *
+ params-rate_den;
+ } while (((framesize 33) || (framesize 4095))
+(clk_div));
+ clk_div--;
+ srgr |= DAVINCI_MCBSP_SRGR_FPER(framesize - 1);
+ } else {
+ /*
Rif: Re: [PATCH 3/3] ASoC: DaVinci: More accurate calculation for clock divider for McBSP (I2S)
-Troy Kisky troy.ki...@boundarydevices.com ha scritto: -
Per: Raffaele Recalcati lamiapost...@gmail.com
Da: Troy Kisky troy.ki...@boundarydevices.com
Data: 02/07/2010 22.57
Cc: davinci-linux-open-sou...@linux.davincidsp.com, Mark Brown
broo...@opensource.wolfsonmicro.com, Raffaele Recalcati
raffaele.recalc...@bticino.it
Oggetto: Re: [PATCH 3/3] ASoC: DaVinci: More accurate calculation for
clock divider for McBSP (I2S)
Raffaele Recalcati wrote:
@@ -447,6 +448,24 @@ static int davinci_i2s_hw_params(struct
snd_pcm_substream *substream,
8 - 1);
+if (dev-i2s_accurate_clock) {
+clk_div = 256;
+do {
+
framesize = (freq / (--clk_div)) /
+params-rate_num *
+params-
rate_den;
+
} while (((framesize 33) || (framesize 4095))
+ (clk_div));
+clk_div--;
+srgr |= DAVINCI_MCBSP_SRGR_FPER
(framesize - 1);
+} else {
+/* symmetric waveforms */
+
clk_div = freq / (mcbsp_word_length * 16) /
+ params-
rate_num * params-rate_den;
+srgr |= DAVINCI_MCBSP_SRGR_FPER
(mcbsp_word_length *
+
16 - 1);
+}
+
/* symmetric waveforms */
clk_div = freq / (mcbsp_word_length * 16) /
params-rate_num * params-
rate_den;
Can you test to see if this works to replace all the above ?
unsigned cycles;
framesize = mcbsp_word_length * 16;
cycles = (freq / params-rate_num) * params-
rate_den;
clk_div = cycles / framesize;
if (dev-i2s_accurate_clock) {
framesize = cycles / clk_div;
if (framesize 4096))
framesize = 4096;
}
srgr |= DAVINCI_MCBSP_SRGR_FPER(framesize - 1);
yes, it works.
Now I'm trying to understand the differences:
your solution with i2s_accurate_clock enabled:
davinci-asp davinci-asp.0: framesize = 32
davinci-asp davinci-asp.0: clk_div = 86
your solution with i2s_accurate_clock NOT enabled:
davinci-asp davinci-asp.0: framesize = 32
davinci-asp davinci-asp.0: clk_div = 86
the same.
my solution with i2s_accurate_clock enabled:
davinci-asp davinci-asp.0: my framesize = 33
davinci-asp
davinci-asp.0: clk_div = 82
here the continuous serial clock is faster
my solution with i2s_accurate_clock NOT enabled
davinci-asp davinci-asp.0: my framesize = 32
davinci-asp davinci-asp.0: clk_div = 86
here the continuous
serial clock is the same as yours.
it seems better my and Davide solution.
Raffaele Recalcati
Driver Linux BSP
Bticino S.p.A.
Via
L.Manara 4, Erba (CO), Italy
Tel: +39.(0)31.653.252
Tel2:
+39.(0)31.653.652
Fax: +39.(0)31.653.283
E-mail:
raffaele.recalc...@bticino.it
Web:
www.bticino.it
Bticino
Legrand
Zucchini
Cablofil
Ortronics
Ce message, ainsi que tous les fichiers joints à ce message,
peuvent contenir des informations sensibles et/ ou confidentielles
ne devant pas être divulguées. Si vous n'êtes pas le destinataire
de ce message (ou que vous recevez ce message par erreur), nous
vous remercions de le notifier immédiatement à son expéditeur, et
de détruire ce message. Toute copie, divulgation, modification,
utilisation ou diffusion, non autorisée, directe ou indirecte, de
tout ou partie de ce message, est strictement interdite.
This e-mail, and any document attached hereby, may contain
confidential and/or privileged information. If you are not the
intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any
unauthorized, direct or indirect, copying, disclosure, distribution
or other use of the material or parts thereof is strictly
forbidden.
___
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/3] ASoC: DaVinci: Added selection of clk input pin for McBSP
From: Raffaele Recalcati raffaele.recalc...@bticino.it
When McBSP peripheral gets the clock from an external pin,
there are three possible chooses, MCBSP_CLKX, MCBSP_CLKR
and MCBSP_CLKS.
evm-dm365 uses MCBSP_CLKR, instead in bmx board I have a different
hardware connection and I use MCBSP_CLKS, so I have added
this possibility.
This patch has been developed against the:
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
git tree and has been tested on bmx board (similar to dm365 evm)
Signed-off-by: Raffaele Recalcati raffaele.recalc...@bticino.it
Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it
---
arch/arm/mach-davinci/include/mach/asp.h | 15 +++
sound/soc/davinci/davinci-i2s.c | 29 -
2 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/asp.h
b/arch/arm/mach-davinci/include/mach/asp.h
index 834725f..0847d21 100644
--- a/arch/arm/mach-davinci/include/mach/asp.h
+++ b/arch/arm/mach-davinci/include/mach/asp.h
@@ -63,6 +63,16 @@ struct snd_platform_data {
unsigned sram_size_playback;
unsigned sram_size_capture;
+ /*
+* If McBSP peripheral gets the clock from an external pin,
+* there are three chooses, that are MCBSP_CLKX, MCBSP_CLKR
+* and MCBSP_CLKS.
+* Depending on different hardware connections it is possible
+* to use this setting to change the behaviour of McBSP
+* driver. The dm365_clk_input_pin enum is available for dm365
+*/
+ int clk_input_pin;
+
/* McASP specific fields */
int tdm_slots;
u8 op_mode;
@@ -78,6 +88,11 @@ enum {
MCASP_VERSION_2,/* DA8xx/OMAPL1x */
};
+enum dm365_clk_input_pin {
+ MCBSP_CLKR = 0, /* DM365 */
+ MCBSP_CLKS,
+};
+
#define INACTIVE_MODE 0
#define TX_MODE1
#define RX_MODE2
diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c
index c8f038c..ba5644b 100644
--- a/sound/soc/davinci/davinci-i2s.c
+++ b/sound/soc/davinci/davinci-i2s.c
@@ -122,6 +122,7 @@ static const unsigned char
double_fmt[SNDRV_PCM_FORMAT_S32_LE + 1] = {
};
struct davinci_mcbsp_dev {
+ struct device *dev;
struct davinci_pcm_dma_params dma_params[2];
void __iomem*base;
#define MOD_DSP_A 0
@@ -153,6 +154,7 @@ struct davinci_mcbsp_dev {
unsigned int fmt;
int clk_div;
+ int clk_input_pin;
};
static inline void davinci_mcbsp_write_reg(struct davinci_mcbsp_dev *dev,
@@ -279,11 +281,26 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
DAVINCI_MCBSP_PCR_CLKRM;
break;
case SND_SOC_DAIFMT_CBM_CFS:
- /* McBSP CLKR pin is the input for the Sample Rate Generator.
-* McBSP FSR and FSX are driven by the Sample Rate Generator. */
- pcr = DAVINCI_MCBSP_PCR_SCLKME |
- DAVINCI_MCBSP_PCR_FSXM |
- DAVINCI_MCBSP_PCR_FSRM;
+ pcr = DAVINCI_MCBSP_PCR_FSRM | DAVINCI_MCBSP_PCR_FSXM;
+ /*
+* Selection of the clock input pin that is the
+* input for the Sample Rate Generator.
+* McBSP FSR and FSX are driven by the Sample Rate
+* Generator.
+*/
+ switch (dev-clk_input_pin) {
+ case MCBSP_CLKS:
+ pcr |= DAVINCI_MCBSP_PCR_CLKXM |
+ DAVINCI_MCBSP_PCR_CLKRM;
+ break;
+ case MCBSP_CLKR:
+ pcr |= DAVINCI_MCBSP_PCR_SCLKME;
+ break;
+ default:
+ dev_err(dev-dev, bad clk_input_pin\n);
+ return -EINVAL;
+ }
+
break;
case SND_SOC_DAIFMT_CBM_CFM:
/* codec is master */
@@ -644,6 +661,7 @@ static int davinci_i2s_probe(struct platform_device *pdev)
pdata-sram_size_playback;
dev-dma_params[SNDRV_PCM_STREAM_CAPTURE].sram_size =
pdata-sram_size_capture;
+ dev-clk_input_pin = pdata-clk_input_pin;
}
dev-clk = clk_get(pdev-dev, NULL);
if (IS_ERR(dev-clk)) {
@@ -676,6 +694,7 @@ static int davinci_i2s_probe(struct platform_device *pdev)
goto err_free_mem;
}
dev-dma_params[SNDRV_PCM_STREAM_CAPTURE].channel = res-start;
+ dev-dev = pdev-dev;
davinci_i2s_dai.private_data = dev;
davinci_i2s_dai.capture.dma_data = dev-dma_params;
--
1.7.0.4
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
[PATCH 3/3] ASoC: DaVinci: More accurate continuous serial clock for McBSP (I2S)
From: Raffaele Recalcati raffaele.recalc...@bticino.it
i2s_accurate_sck switch can be used to have a better approximate
sampling frequency.
The clock is an externally visible bit clock and it is named
i2s continuous serial clock (I2S_SCK).
The trade off is between more accurate clock (fast clock)
and less accurate clock (slow clock).
The waveform will be not symmetric.
Probably it is possible to get a better algorithm for calculating
the divider, trying to keep a slower clock as possible.
This patch has been developed against the
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
git tree and has been tested on bmx board (similar to dm365 evm, but using
uda1345 as external audio codec).
Signed-off-by: Raffaele Recalcati raffaele.recalc...@bticino.it
Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it
---
arch/arm/mach-davinci/include/mach/asp.h | 33 ++
sound/soc/davinci/davinci-i2s.c | 24 +
2 files changed, 52 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-davinci/include/mach/asp.h
b/arch/arm/mach-davinci/include/mach/asp.h
index 0847d21..b12c69e 100644
--- a/arch/arm/mach-davinci/include/mach/asp.h
+++ b/arch/arm/mach-davinci/include/mach/asp.h
@@ -73,6 +73,39 @@ struct snd_platform_data {
*/
int clk_input_pin;
+ /*
+* This flag works when both clock and FS are outputs for the cpu
+* and makes clock more accurate (FS is not symmetrical and the
+* clock is very fast.
+* The clock becoming faster is named
+* i2s continuous serial clock (I2S_SCK) and it is an externally
+* visible bit clock.
+*
+* first line : WordSelect
+* second line : ContinuousSerialClock
+* third line: SerialData
+*
+* SYMMETRICAL APPROACH:
+* ___ LEFT
+* _| RIGHT |__|
+* _ _ _ _ _ _ _ _
+* _| |_| |_ x16 _| |_| |_| |_| |_ x16 _| |_| |_
+* _ _ _ _ _ _ _ _
+* _/ \_/ \_ ... _/ \_/ \_/ \_/ \_ ... _/ \_/ \_
+*\_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/
+*
+* ACCURATE CLOCK APPROACH:
+* __ LEFT
+* _| RIGHT|___|
+* _ _ _ _ _ _ _ _ _
+* _| |_ x16 _| |_| |_ x16 _| |_| |_| |_| |_| |_| |
+* _ _ _ _ dummy cycles
+* _/ \_ ... _/ \_/ \_ ... _/ \__
+*\_/ \_/ \_/\_/
+*
+*/
+ bool i2s_accurate_sck;
+
/* McASP specific fields */
int tdm_slots;
u8 op_mode;
diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c
index ba5644b..b251bc9 100644
--- a/sound/soc/davinci/davinci-i2s.c
+++ b/sound/soc/davinci/davinci-i2s.c
@@ -155,6 +155,7 @@ struct davinci_mcbsp_dev {
unsigned int fmt;
int clk_div;
int clk_input_pin;
+ bool i2s_accurate_sck;
};
static inline void davinci_mcbsp_write_reg(struct davinci_mcbsp_dev *dev,
@@ -447,11 +448,23 @@ static int davinci_i2s_hw_params(struct snd_pcm_substream
*substream,
DAVINCI_MCBSP_SRGR_CLKSM;
srgr |= DAVINCI_MCBSP_SRGR_FWID(mcbsp_word_length *
8 - 1);
- /* symmetric waveforms */
- clk_div = freq / (mcbsp_word_length * 16) /
- params-rate_num * params-rate_den;
- srgr |= DAVINCI_MCBSP_SRGR_FPER(mcbsp_word_length *
- 16 - 1);
+ if (dev-i2s_accurate_sck) {
+ clk_div = 256;
+ do {
+ framesize = (freq / (--clk_div)) /
+ params-rate_num *
+ params-rate_den;
+ } while (((framesize 33) || (framesize 4095))
+(clk_div));
+ clk_div--;
+ srgr |= DAVINCI_MCBSP_SRGR_FPER(framesize - 1);
+ } else {
+ /* symmetric waveforms */
+ clk_div = freq / (mcbsp_word_length * 16) /
+ params-rate_num * params-rate_den;
+ srgr |= DAVINCI_MCBSP_SRGR_FPER(mcbsp_word_length *
+ 16 - 1);
+ }
clk_div = 0xFF;
srgr |= clk_div;
break;
@@ -662,6 +675,7 @@ static int davinci_i2s_probe(struct platform_device *pdev)
dev-dma_params[SNDRV_PCM_STREAM_CAPTURE].sram_size =
Angstrom File System Booting Problem
Hi, I am booting my board using tftp for kernel and NFS for my file system through with dhcp enabled. The file system is made using Angstrom Online Builder for My Davinci 6446 evm. I selected everything for the file system. During booting and after the kernel booting and file system being mounted using nfs, the booting stops at this line: nfs: server 10.130.201.55 not responding, still trying I m wondering why its trying to connect to the same nfs server again? Is there away to disable this step? For example, disabling a certain configuration to overcome it? -- Amr Ali Abdel-Naby Embedded Systems Developer www.embedded-tips.blogspot.com _ Hotmail: Powerful Free email with security by Microsoft. https://signup.live.com/signup.aspx?id=60969___ 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] ASoC: DaVinci: Added two clocking possibilities to McBSP (I2S)
From: Raffaele Recalcati raffaele.recalc...@bticino.it
Added two clocking options for dm365 McBSP peripheral when used
with I2S timings, that are SND_SOC_DAIFMT_CBS_CFS (the cpu generates
clock and frame sync) and SND_SOC_DAIFMT_CBS_CFM (the cpu gets clock
from external pin and generates frame sync).
A slave clock management can be important when the external codec needs
the system clock and the bit clock synchronized (tested with uda1345).
This patch has been developed against the:
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
git tree and has been tested on bmx board (similar to dm365 evm, but using
uda1345 as external audio codec).
Signed-off-by: Raffaele Recalcati raffaele.recalc...@bticino.it
Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it
---
sound/soc/davinci/davinci-i2s.c | 110 +++---
sound/soc/davinci/davinci-i2s.h |5 ++
2 files changed, 106 insertions(+), 9 deletions(-)
diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c
index adadcd3..c8f038c 100644
--- a/sound/soc/davinci/davinci-i2s.c
+++ b/sound/soc/davinci/davinci-i2s.c
@@ -26,6 +26,7 @@
#include mach/asp.h
#include davinci-pcm.h
+#include davinci-i2s.h
/*
@@ -68,16 +69,21 @@
#define DAVINCI_MCBSP_RCR_RDATDLY(v) ((v) 16)
#define DAVINCI_MCBSP_RCR_RFIG (1 18)
#define DAVINCI_MCBSP_RCR_RWDLEN2(v) ((v) 21)
+#define DAVINCI_MCBSP_RCR_RFRLEN2(v) ((v) 24)
+#define DAVINCI_MCBSP_RCR_RPHASE BIT(31)
#define DAVINCI_MCBSP_XCR_XWDLEN1(v) ((v) 5)
#define DAVINCI_MCBSP_XCR_XFRLEN1(v) ((v) 8)
#define DAVINCI_MCBSP_XCR_XDATDLY(v) ((v) 16)
#define DAVINCI_MCBSP_XCR_XFIG (1 18)
#define DAVINCI_MCBSP_XCR_XWDLEN2(v) ((v) 21)
+#define DAVINCI_MCBSP_XCR_XFRLEN2(v) ((v) 24)
+#define DAVINCI_MCBSP_XCR_XPHASE BIT(31)
#define DAVINCI_MCBSP_SRGR_FWID(v) ((v) 8)
#define DAVINCI_MCBSP_SRGR_FPER(v) ((v) 16)
#define DAVINCI_MCBSP_SRGR_FSGM(1 28)
+#define DAVINCI_MCBSP_SRGR_CLKSM BIT(29)
#define DAVINCI_MCBSP_PCR_CLKRP(1 0)
#define DAVINCI_MCBSP_PCR_CLKXP(1 1)
@@ -144,6 +150,9 @@ struct davinci_mcbsp_dev {
* won't end up being swapped because of the underrun.
*/
unsigned enable_channel_combine:1;
+
+ unsigned int fmt;
+ int clk_div;
};
static inline void davinci_mcbsp_write_reg(struct davinci_mcbsp_dev *dev,
@@ -254,10 +263,12 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
struct davinci_mcbsp_dev *dev = cpu_dai-private_data;
unsigned int pcr;
unsigned int srgr;
+ /* Attention srgr is updated by hw_params! */
srgr = DAVINCI_MCBSP_SRGR_FSGM |
DAVINCI_MCBSP_SRGR_FPER(DEFAULT_BITPERSAMPLE * 2 - 1) |
DAVINCI_MCBSP_SRGR_FWID(DEFAULT_BITPERSAMPLE - 1);
+ dev-fmt = fmt;
/* set master/slave audio interface */
switch (fmt SND_SOC_DAIFMT_MASTER_MASK) {
case SND_SOC_DAIFMT_CBS_CFS:
@@ -372,6 +383,18 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
return 0;
}
+static int davinci_i2s_dai_set_clkdiv(struct snd_soc_dai *cpu_dai,
+ int div_id, int div)
+{
+ struct davinci_mcbsp_dev *dev = cpu_dai-private_data;
+
+ if (div_id != DAVINCI_MCBSP_CLKGDV)
+ return -ENODEV;
+
+ dev-clk_div = div;
+ return 0;
+}
+
static int davinci_i2s_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
@@ -380,8 +403,8 @@ static int davinci_i2s_hw_params(struct snd_pcm_substream
*substream,
struct davinci_pcm_dma_params *dma_params =
dev-dma_params[substream-stream];
struct snd_interval *i = NULL;
- int mcbsp_word_length;
- unsigned int rcr, xcr, srgr;
+ int mcbsp_word_length, master;
+ unsigned int rcr, xcr, srgr, clk_div, freq, framesize;
u32 spcr;
snd_pcm_format_t fmt;
unsigned element_cnt = 1;
@@ -396,12 +419,47 @@ static int davinci_i2s_hw_params(struct snd_pcm_substream
*substream,
davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SPCR_REG, spcr);
}
- i = hw_param_interval(params, SNDRV_PCM_HW_PARAM_SAMPLE_BITS);
- srgr = DAVINCI_MCBSP_SRGR_FSGM;
- srgr |= DAVINCI_MCBSP_SRGR_FWID(snd_interval_value(i) - 1);
+ master = dev-fmt SND_SOC_DAIFMT_MASTER_MASK;
+ fmt = params_format(params);
+ mcbsp_word_length = asp_word_length[fmt];
- i = hw_param_interval(params, SNDRV_PCM_HW_PARAM_FRAME_BITS);
- srgr |= DAVINCI_MCBSP_SRGR_FPER(snd_interval_value(i) - 1);
+ switch (master) {
+ case SND_SOC_DAIFMT_CBS_CFS:
+ freq = clk_get_rate(dev-clk);
Re: [PATCH 1/3] ASoC: DaVinci: Added two clocking possibilities to McBSP (I2S)
On Tue, 2010-07-06 at 10:39 +0200, Raffaele Recalcati wrote:
From: Raffaele Recalcati raffaele.recalc...@bticino.it
Added two clocking options for dm365 McBSP peripheral when used
with I2S timings, that are SND_SOC_DAIFMT_CBS_CFS (the cpu generates
clock and frame sync) and SND_SOC_DAIFMT_CBS_CFM (the cpu gets clock
from external pin and generates frame sync).
A slave clock management can be important when the external codec needs
the system clock and the bit clock synchronized (tested with uda1345).
This patch has been developed against the:
http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git
git tree and has been tested on bmx board (similar to dm365 evm, but using
uda1345 as external audio codec).
Signed-off-by: Raffaele Recalcati raffaele.recalc...@bticino.it
Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it
All
Acked-by: Liam Girdwood l...@slimlogic.co.uk
But lets get some feedback from the DaVinci folks on this too.
---
sound/soc/davinci/davinci-i2s.c | 110 +++---
sound/soc/davinci/davinci-i2s.h |5 ++
2 files changed, 106 insertions(+), 9 deletions(-)
diff --git a/sound/soc/davinci/davinci-i2s.c b/sound/soc/davinci/davinci-i2s.c
index adadcd3..c8f038c 100644
--- a/sound/soc/davinci/davinci-i2s.c
+++ b/sound/soc/davinci/davinci-i2s.c
@@ -26,6 +26,7 @@
#include mach/asp.h
#include davinci-pcm.h
+#include davinci-i2s.h
/*
@@ -68,16 +69,21 @@
#define DAVINCI_MCBSP_RCR_RDATDLY(v) ((v) 16)
#define DAVINCI_MCBSP_RCR_RFIG (1 18)
#define DAVINCI_MCBSP_RCR_RWDLEN2(v) ((v) 21)
+#define DAVINCI_MCBSP_RCR_RFRLEN2(v) ((v) 24)
+#define DAVINCI_MCBSP_RCR_RPHASE BIT(31)
#define DAVINCI_MCBSP_XCR_XWDLEN1(v) ((v) 5)
#define DAVINCI_MCBSP_XCR_XFRLEN1(v) ((v) 8)
#define DAVINCI_MCBSP_XCR_XDATDLY(v) ((v) 16)
#define DAVINCI_MCBSP_XCR_XFIG (1 18)
#define DAVINCI_MCBSP_XCR_XWDLEN2(v) ((v) 21)
+#define DAVINCI_MCBSP_XCR_XFRLEN2(v) ((v) 24)
+#define DAVINCI_MCBSP_XCR_XPHASE BIT(31)
#define DAVINCI_MCBSP_SRGR_FWID(v) ((v) 8)
#define DAVINCI_MCBSP_SRGR_FPER(v) ((v) 16)
#define DAVINCI_MCBSP_SRGR_FSGM (1 28)
+#define DAVINCI_MCBSP_SRGR_CLKSM BIT(29)
#define DAVINCI_MCBSP_PCR_CLKRP (1 0)
#define DAVINCI_MCBSP_PCR_CLKXP (1 1)
@@ -144,6 +150,9 @@ struct davinci_mcbsp_dev {
* won't end up being swapped because of the underrun.
*/
unsigned enable_channel_combine:1;
+
+ unsigned int fmt;
+ int clk_div;
};
static inline void davinci_mcbsp_write_reg(struct davinci_mcbsp_dev *dev,
@@ -254,10 +263,12 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
struct davinci_mcbsp_dev *dev = cpu_dai-private_data;
unsigned int pcr;
unsigned int srgr;
+ /* Attention srgr is updated by hw_params! */
srgr = DAVINCI_MCBSP_SRGR_FSGM |
DAVINCI_MCBSP_SRGR_FPER(DEFAULT_BITPERSAMPLE * 2 - 1) |
DAVINCI_MCBSP_SRGR_FWID(DEFAULT_BITPERSAMPLE - 1);
+ dev-fmt = fmt;
/* set master/slave audio interface */
switch (fmt SND_SOC_DAIFMT_MASTER_MASK) {
case SND_SOC_DAIFMT_CBS_CFS:
@@ -372,6 +383,18 @@ static int davinci_i2s_set_dai_fmt(struct snd_soc_dai
*cpu_dai,
return 0;
}
+static int davinci_i2s_dai_set_clkdiv(struct snd_soc_dai *cpu_dai,
+ int div_id, int div)
+{
+ struct davinci_mcbsp_dev *dev = cpu_dai-private_data;
+
+ if (div_id != DAVINCI_MCBSP_CLKGDV)
+ return -ENODEV;
+
+ dev-clk_div = div;
+ return 0;
+}
+
static int davinci_i2s_hw_params(struct snd_pcm_substream *substream,
struct snd_pcm_hw_params *params,
struct snd_soc_dai *dai)
@@ -380,8 +403,8 @@ static int davinci_i2s_hw_params(struct snd_pcm_substream
*substream,
struct davinci_pcm_dma_params *dma_params =
dev-dma_params[substream-stream];
struct snd_interval *i = NULL;
- int mcbsp_word_length;
- unsigned int rcr, xcr, srgr;
+ int mcbsp_word_length, master;
+ unsigned int rcr, xcr, srgr, clk_div, freq, framesize;
u32 spcr;
snd_pcm_format_t fmt;
unsigned element_cnt = 1;
@@ -396,12 +419,47 @@ static int davinci_i2s_hw_params(struct
snd_pcm_substream *substream,
davinci_mcbsp_write_reg(dev, DAVINCI_MCBSP_SPCR_REG, spcr);
}
- i = hw_param_interval(params, SNDRV_PCM_HW_PARAM_SAMPLE_BITS);
- srgr = DAVINCI_MCBSP_SRGR_FSGM;
- srgr |= DAVINCI_MCBSP_SRGR_FWID(snd_interval_value(i) - 1);
+ master = dev-fmt SND_SOC_DAIFMT_MASTER_MASK;
+ fmt = params_format(params);
+ mcbsp_word_length = asp_word_length[fmt];
- i = hw_param_interval(params,
RE: [PATCH 1/3] ASoC: DaVinci: Added two clocking possibilities to McBSP (I2S)
Hi, On Tue, Jul 06, 2010 at 15:15:59, Liam Girdwood wrote: On Tue, 2010-07-06 at 10:39 +0200, Raffaele Recalcati wrote: From: Raffaele Recalcati raffaele.recalc...@bticino.it Added two clocking options for dm365 McBSP peripheral when used with I2S timings, that are SND_SOC_DAIFMT_CBS_CFS (the cpu generates clock and frame sync) and SND_SOC_DAIFMT_CBS_CFM (the cpu gets clock from external pin and generates frame sync). A slave clock management can be important when the external codec needs the system clock and the bit clock synchronized (tested with uda1345). This patch has been developed against the: http://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-davinci.git git tree and has been tested on bmx board (similar to dm365 evm, but using uda1345 as external audio codec). Signed-off-by: Raffaele Recalcati raffaele.recalc...@bticino.it Signed-off-by: Davide Bonfanti davide.bonfa...@bticino.it All Acked-by: Liam Girdwood l...@slimlogic.co.uk But lets get some feedback from the DaVinci folks on this too. Acked-by: Sudhakar Rajashekhara sudhakar@ti.com Regards, Sudhakar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Angstrom File System Booting Problem
Hi, I am booting my board using tftp for kernel and NFS for my file system through with dhcp enabled. The file system is made using Angstrom Online Builder for My Davinci 6446 evm. I selected everything for the file system. During booting and after the kernel booting and file system being mounted using nfs, the booting stops at this line: nfs: server 10.130.201.55 not responding, still trying I m wondering why its trying to connect to the same nfs server again? Is there away to disable this step? For example, disabling a certain configuration to overcome it? -- Amr Ali Abdel-Naby Embedded Systems Developer Hotmail: Powerful Free email with security by Microsoft. Get it now. _ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969___ 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/3] ASoC: DaVinci: Added two clocking possibilities to McBSP (I2S)
On Tue, Jul 06, 2010 at 05:00:24PM +0530, Sudhakar Rajashekhara wrote: Acked-by: Liam Girdwood l...@slimlogic.co.uk Acked-by: Sudhakar Rajashekhara sudhakar@ti.com Applied all, 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: Rif: Re: [PATCH 3/3] ASoC: DaVinci: More accurate calculation for clock divider for McBSP (I2S)
On Tue, Jul 06, 2010 at 11:35:28AM -0700, Troy Kisky wrote: Indeed, your algorithm may produce more accurate results for the specific rate that you tested for. However, that seems more luck than anything. How do you know that a frame size of 33 will always give more accurate results than a frame size of 32? If your going to loop, you need to calculate the error and minimize that and not just stop when framesize finally reaches your minimum size of 33. Yes, this is pretty much the algorithm I was trying to suggest earlier. Iterate up until you hit either an exact match or decide that the frame size is getting too big. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
pwrite in mtd
The write to mtd pwrite(fd, writebuf, size, mtdoffset) returns error Num 22, Invalid Arguments Any clue? ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
