TI JPEG Encoder on DM6446/DVEVM, IMGENC1_create fails
Dear group,
This time with a proper subject ;)...
I want to integrate the DM6446 JPEG encoder
(xdc.useModule('ti.sdo.codecs.jpegenc.ce.JPEGENC')) into a codec server
to run on DSP side and create a matching ceapp on gpp side.
We're using DVSDK 1.30.01.41 (BIOS 5.31.08, CMEM 2.00.01, CE 2.00.01, FC
2.00.01, XDAIS 6.00.01, XDC 3.00.02). Our test environment is a dvevm
board plus our self designed DM6446 based pcb (both using 256MB).
I've used the video_copy example to setup both sides. I modified the
all.tcf file from the all_codecs dir to use 32kb L1 Cache again, plus
some modifications on heap/stack sizes. I have attached the server tcf
cfg files (I hope attaching works)
I'm currently facing following problem:
Whenever I call IMGENC1_create on the engine the function returns an
error (if I pass NULL as params it succeeds but I can't do any
control/process calls on the encoder after creation).
I activated DSKT2 tracing and I receive the following output:
[DSP] @2,399,765tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 - _DSKT2_init
Enter
[DSP] @2,399,839tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 - _DSKT2_init
Exit
[DSP] @2,399,883tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 - DSKT2_createAlg
Enter (scratchId=1, fxns=0x8fb66a84, parentAlg=0x0, params=0x8fe05cc0)
[DSP] @2,399,970tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 - _DSKT2_init
Enter
[DSP] @2,400,016tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 - _DSKT2_init
Exit
[DSP] @2,400,060tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Enter (scratchId=1, fxns=0x8fb66a84, parentAlg=0x0,
params=0x8fe05cc0, extHeapId=-1881121600, singleHeap=0)
[DSP] @2,400,202tk: [+2 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Num memory recs requested 8
[DSP] @2,400,276tk: [+2 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Num memory recs requested 5
[DSP] @2,400,343tk: [+4 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Requested memTab[0]: size=0x260, align=0x8,
space=IALG_EXTERNAL, attrs=IALG_PERSIST
[DSP] @2,400,434tk: [+4 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Requested memTab[1]: size=0xe00, align=0x8,
space=IALG_EXTERNAL, attrs=IALG_SCRATCH
[DSP] @2,400,522tk: [+4 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Requested memTab[2]: size=0x253, align=0x8,
space=IALG_EXTERNAL, attrs=IALG_PERSIST
[DSP] @2,400,611tk: [+4 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Requested memTab[3]: size=0x1400, align=0x8,
space=IALG_EXTERNAL, attrs=IALG_SCRATCH
[DSP] @2,400,700tk: [+4 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Requested memTab[4]: size=0xe54, align=0x80,
space=IALG_EXTERNAL, attrs=IALG_PERSIST
[DSP] @2,400,790tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
_DSKT2_assignInstanceMemory Enter (scratchId=1, numRecs=5, extHeapId=1)
[DSP] @2,400,868tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
_DSKT2_usesInternalScratch Enter (numRecs=5)
[DSP] @2,400,927tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
_DSKT2_usesInternalScratch Exit (returnVal=0)
[DSP] @2,400,994tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
_DSKT2_allocateInDesignatedSpace Enter (index=0,
ialgSpace=IALG_EXTERNAL, extHeapId=1)
[DSP] @2,401,081tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
_DSKT2_allocateInDesignatedSpace Exit (returnVal=1)
[DSP] @2,401,145tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
_DSKT2_allocateInDesignatedSpace Enter (index=1,
ialgSpace=IALG_EXTERNAL, extHeapId=1)
[DSP] @2,401,256tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
_DSKT2_allocateInDesignatedSpace Exit (returnVal=1)
[DSP] @2,401,318tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
_DSKT2_allocateInDesignatedSpace Enter (index=2,
ialgSpace=IALG_EXTERNAL, extHeapId=1)
[DSP] @2,401,403tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
_DSKT2_allocateInDesignatedSpace Exit (returnVal=1)
[DSP] @2,401,466tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
_DSKT2_allocateInDesignatedSpace Enter (index=3,
ialgSpace=IALG_EXTERNAL, extHeapId=1)
[DSP] @2,401,592tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
_DSKT2_allocateInDesignatedSpace Exit (returnVal=1)
[DSP] @2,401,655tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
_DSKT2_allocateInDesignatedSpace Enter (index=4,
ialgSpace=IALG_EXTERNAL, extHeapId=1)
[DSP] @2,401,772tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
_DSKT2_allocateInDesignatedSpace Exit (returnVal=1)
[DSP] @2,401,834tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
_DSKT2_usesInternalScratch Enter (numRecs=5)
[DSP] @2,401,893tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
_DSKT2_usesInternalScratch Exit (returnVal=0)
[DSP] @2,401,952tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
_DSKT2_assignInstanceMemory Exit (returnVal=1)
[DSP] @2,402,013tk: [+4 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Allocated memTab[0]: base=0x88000250, size=0x260,
align=0x8, space=IALG_EXTERNAL, attrs=IALG_PERSIST
[DSP] @2,402,114tk: [+4 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Allocated memTab[1]: base=0x880004b0, size=0xe00,
align=0x8, space=IALG_EXTERNAL, attrs=IALG_PERSIST
[DSP] @2,402,214tk: [+4 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Allocated memTab[2]: base=0x880012b0,
AW: (no subject)
Hi Chase,
thank you for your quick reply.
Here's some additional information:
I quite confident that it's an IMGENC1 encoder since I'm also querying
this information from the encoder (unfortunately left that out in the
trace log).
Here's the missing output
### CEapp- alg[0]: name = jpgenc typeTab =
ti.sdo.ce.image1.IIMGENC1 local = 0
Finally replacing all IMGENC1_ with IMGENC_ function calls/structs,
leads to linker errors since the linker uses
1will link with
ti.sdo.ce.image1:lib/imgdec1.a470MV;lib/imgenc1.a470MV
Instead of the image libraries. Finally the encoder datasheet states
that it's: eXpressDSP(tm) Digital Media (XDM 1.0 IIMGENC1) interface
compliant
Maybe my problem is a tools versioning problem (thanks for the hint with
DVSDK 2.00 which made me look for versions again)
There's a file named JPEGENC.version.2.00.002.wizardversion.0.5.2
within the JPEG encoder directory structure, I assume that's the
version.
There are following requirements listed in the encoder user manual
DSP/BIOS 5.31.02, we're using 5.31.08
CGTOOLS 6.0.14, we're using 6.0.15
FC 2.20.01, we're using 2.00.01. This is not an explicit requirement,
but it's listed in the section 2.3.2 (installing FC). Maybe this is the
problem, I'm currently downloading/installing the new FC. I'll keep you
informed.
Regards
Frank
Von: Maupin, Chase [mailto:chase.mau...@ti.com]
Gesendet: Donnerstag, 13. August 2009 15:57
An: Frank Bhattacharyya; davinci-linux-open-source@linux.davincidsp.com
Betreff: RE: (no subject)
Frank,
You may need to use the IMGENC APIs rather than the IMGENC1 APIs for
this release of the JPEG codec. Last I checked the JPEG encoder for
DM6446 used the xDM 0.9 APIs.
If you can you may want to upgrade to DVSDK 2.00 which contains DMAI.
The DMAI package includes sample applications for JPEG encode and decode
for DM6446. At the very least this might help you see how to use the
image encoder.
Sincerely,
Chase Maupin
Software Applications
Catalog DSP Products
e-mail: chase.mau...@ti.com
phone: (281) 274-3285
For support:
Forums - http://community.ti.com/forums/
Wiki - http://wiki.davincidsp.com/
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On
Behalf Of Frank Bhattacharyya
Sent: Thursday, August 13, 2009 7:27 AM
To: davinci-linux-open-source@linux.davincidsp.com
Subject: (no subject)
Dear group,
I want to integrate the DM6446 JPEG encoder
(xdc.useModule('ti.sdo.codecs.jpegenc.ce.JPEGENC')) into a codec server
to run on DSP side and create a matching ceapp on gpp side.
We're using DVSDK 1.30.01.41 (BIOS 5.31.08, CMEM 2.00.01, CE 2.00.01, FC
2.00.01, XDAIS 6.00.01, XDC 3.00.02). Our test environment is a dvevm
board plus our self designed DM6446 based boards (both using 256MB).
I've used the video_copy example to setup both sides. I modified the
all.tcf file from the all_codecs dir to use 32kb L1 Cache again, plus
some modifications on heap/stack sizes. I have attached the server tcf
cfg files (I hope attaching works)
I'm currently facing following problem:
Whenever I call IMGENC1_create on the engine the function returns an
error (if I pass NULL as params it succeeds but I can't do any
control/process calls on the encoder).
I activated DSKT2 tracing and I receive the following output:
[DSP] @2,399,765tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 - _DSKT2_init
Enter
[DSP] @2,399,839tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 - _DSKT2_init
Exit
[DSP] @2,399,883tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 - DSKT2_createAlg
Enter (scratchId=1, fxns=0x8fb66a84, parentAlg=0x0, params=0x8fe05cc0)
[DSP] @2,399,970tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 - _DSKT2_init
Enter
[DSP] @2,400,016tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 - _DSKT2_init
Exit
[DSP] @2,400,060tk: [+0 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Enter (scratchId=1, fxns=0x8fb66a84, parentAlg=0x0,
params=0x8fe05cc0, extHeapId=-1881121600, singleHeap=0)
[DSP] @2,400,202tk: [+2 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Num memory recs requested 8
[DSP] @2,400,276tk: [+2 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Num memory recs requested 5
[DSP] @2,400,343tk: [+4 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Requested memTab[0]: size=0x260, align=0x8,
space=IALG_EXTERNAL, attrs=IALG_PERSIST
[DSP] @2,400,434tk: [+4 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Requested memTab[1]: size=0xe00, align=0x8,
space=IALG_EXTERNAL, attrs=IALG_SCRATCH
[DSP] @2,400,522tk: [+4 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Requested memTab[2]: size=0x253, align=0x8,
space=IALG_EXTERNAL, attrs=IALG_PERSIST
[DSP] @2,400,611tk: [+4 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Requested memTab[3]: size=0x1400, align=0x8,
space=IALG_EXTERNAL, attrs=IALG_SCRATCH
[DSP] @2,400,700tk: [+4 T:0x8fa0348c] ti.sdo.fc.dskt2 -
DSKT2_createAlg3 Requested memTab[4]:
ALSA on Linux Kernel v2.6.31-rc5-davinci1
Hi all, I was trying to play audio on Linux Kernel v2.6.31-rc5-davinci1. I have enabled ALSA related following configurations: * Sequencer support * OSS Mixer API * OSS PCM (digital audio) API [*] OSS PCM (digital audio) API - Include plugin system [*] Support old ALSA API [*] Verbose procfs contents [*] Verbose printk [*] Generic sound devices [*] ARM sound devices --- * ALSA for SoC audio support * SoC Audio for the TI DAVINCI chip * SoC Audio support for DaVinci DM6446 or DM355 EVM In dmesg, I can see one alsa device. I was able to play back using my old oss based application, but when I tried to play using aplay utility, output was not available. I also tried to use amixer but it failed as below: r...@192.168.1.247:~# amixer cset numid=1 127,127 ALSA sound/core/control.c:1227: ALSA sound/core/control.c:1227: unknown ioctl = 0xc2c85513 unknown ioctl = 0xc2c85513 amixer: Control default element write error: Inappropriate ioctl for device Any suggestions ? Regards, Viral ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: ALSA on Linux Kernel v2.6.31-rc5-davinci1
On Fri, Aug 14, 2009 at 15:19:56, Viral Sachde wrote: Hi all, I was trying to play audio on Linux Kernel v2.6.31-rc5-davinci1. I have enabled ALSA related following configurations: * Sequencer support * OSS Mixer API * OSS PCM (digital audio) API [*] OSS PCM (digital audio) API - Include plugin system [*] Support old ALSA API [*] Verbose procfs contents [*] Verbose printk [*] Generic sound devices [*] ARM sound devices --- * ALSA for SoC audio support * SoC Audio for the TI DAVINCI chip * SoC Audio support for DaVinci DM6446 or DM355 EVM In dmesg, I can see one alsa device. I was able to play back using my old oss based application, but when I tried to play using aplay utility, output was not available. I also tried to use amixer but it failed as below: r...@192.168.1.247:~# amixer cset numid=1 127,127 ALSA sound/core/control.c:1227: ALSA sound/core/control.c:1227: unknown ioctl = 0xc2c85513 unknown ioctl = 0xc2c85513 amixer: Control default element write error: Inappropriate ioctl for device Any suggestions ? Viral, I checked with the above configuration options you have set, I do not observe the issues you have mentioned. Tested it on DM6446 and DM355 EVM. Both ALSA and OSS emulation are working fine. I am using Sourcery G++ Lite 2009q1-203 tool chain and Arago file system Arago 2009.03-rc4. Regards, Chaithrika Regards, Viral ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: [PATCH] davinci: Handle pinmux conflict between mmc/sd and nor flash
On Fri, Aug 14, 2009 at 04:51:05, Kevin Hilman wrote:
Sudhakar Rajashekhara sudhakar@ti.com writes:
On DA850/OMAP-L138 EVM, MMC/SD and NOR Flash share
some of the AEMIF pins. This patch prints out a warning
during booting, if both MMC/SD and NOR Flash are enabled
in kernel menuconfig.
If both MMC/SD and NOR Flash are enabled, only MMC/SD
will work correctly.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
This patch is dependent on the following patches which
I have submitted earlier:
[PATCH] davinci: Macro to convert GPIO signal to GPIO pin number
[PATCH v3] davinci: Add platform support for da850/omap-l138 GLCD
[PATCH v3] davinci: Add MMC/SD support for da850/omap-l138
[PATCH v3] davinci: Add NAND flash support for DA850/OMAP-L138
[PATCH v3] davinci: Add NOR flash support for da850/omap-l138
FYI for future reference. When you have lots of patch dependencies
like this, it is simpler to send them as a series. If you use
git-format-patch for a range of commits, it will automatically do
the 'PATCH x/y' formatting etc.
In this case, in the series if one patch needs modifications
then do I need to re-submit the whole series again?
arch/arm/mach-davinci/board-da850-evm.c | 63
--
1 files changed, 42 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 70a2f48..f2946a0 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -244,6 +244,20 @@ static void __init da850_evm_init_nor(void)
iounmap(aemif_addr);
}
+#if defined(CONFIG_MTD_PHYSMAP) || \
+defined(CONFIG_MTD_PHYSMAP_MODULE)
+#define HAS_NOR 1
+#else
+#define HAS_NOR 0
+#endif
+
+#if defined(CONFIG_MMC_DAVINCI) || \
+defined(CONFIG_MMC_DAVINCI_MODULE)
+#define HAS_MMC 1
+#else
+#define HAS_MMC 0
+#endif
+
static __init void da850_evm_init(void)
{
struct davinci_soc_info *soc_info = davinci_soc_info;
@@ -298,27 +312,34 @@ static __init void da850_evm_init(void)
pr_warning(da830_evm_init: watchdog registration failed: %d\n,
ret);
- ret = da8xx_pinmux_setup(da850_mmcsd0_pins);
- if (ret)
- pr_warning(da850_evm_init: mmcsd0 mux setup failed: %d\n,
- ret);
-
- ret = gpio_request(DA850_MMCSD_CD_PIN, MMC CD\n);
- if (ret)
- pr_warning(da850_evm_init: can not open GPIO %d\n,
- DA850_MMCSD_CD_PIN);
- gpio_direction_input(DA850_MMCSD_CD_PIN);
-
- ret = gpio_request(DA850_MMCSD_WP_PIN, MMC WP\n);
- if (ret)
- pr_warning(da850_evm_init: can not open GPIO %d\n,
- DA850_MMCSD_WP_PIN);
- gpio_direction_input(DA850_MMCSD_WP_PIN);
-
- ret = da8xx_register_mmcsd0(da850_mmc_config);
- if (ret)
- pr_warning(da850_evm_init: mmcsd0 registration failed: %d\n,
- ret);
+ if (HAS_MMC) {
+ if (HAS_NOR)
+ pr_warning(WARNING: both NOR Flash and MMC/SD are
+ enabled, but they share AEMIF pins.\n
+ \tDisable one of them.\n);
+
Hmm, this isn't quite right. MMC will never be configured unless NOR
is enabled also.
This is not the case now. MMC will get initialized even if NOR is
not enabled. If the second if condition is true it only prints the
warning and proceeds to initialize MMC.
- 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 v3] davinci: Add NOR flash support for da850/omap-l138
On Fri, Aug 14, 2009 at 04:43:58, Kevin Hilman wrote: Sudhakar Rajashekhara sudhakar@ti.com writes: This patch adds platform data for the 8MB NOR flash found on da850/omap-l138 EVM. Both NOR and NAND can co-exist on da850/omap-l138 as they are using different chip selects. Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com --- Since the previous version: 1. Removed #ifdef macro guards from the board file. 2. Defined macros for CS2 offset and the value being written to this offset. 3. Value at the CS2 offset of AEMIOF is being read before writing to it. 4. Corrected the argument to ioremap() function. Thanks, pushing today. Kevin This patch is dependent on the following patches which I have submitted earlier: [PATCH] davinci: Macro to convert GPIO signal to GPIO pin number [PATCH v3] davinci: Add platform support for da850/omap-l138 GLCD [PATCH v3] davinci: Add MMC/SD support for da850/omap-l138 [PATCH v3] davinci: Add NAND flash support for DA850/OMAP-L138 I am not seeing any of these patches in the tree. Something wrong? - 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 RFC 1/2] MUSB: CPPI 4.1 DMA driver (take 4)
Texas Instruments CPPI 4.1 DMA support for the MUSBMHRDC driver.
The code makes use of the accelerated generic RNDIS DMA mode, falling back to
the transparent (packet per transfer) mode if the hardware restrictions prevent
it from using the accelerated mode.
---
Changes since the previous take:
- added workaround for never completing DMA channel teardown;
- added forgotten is_cppi41_enabled() in musb_h_tx_dma_start();
- changed Kconfig dependency to ARCH_DAVINCI_DA8XX since DA850/OMAP-L138 is
also supported;
- replaced 'void *__iomem' with 'void __iomem *'...
drivers/usb/musb/Kconfig | 10
drivers/usb/musb/Makefile |8
drivers/usb/musb/cppi41_dma.c | 1240 +
drivers/usb/musb/cppi41_dma.h | 110 +++
drivers/usb/musb/musb_core.c |4
drivers/usb/musb/musb_dma.h|6
drivers/usb/musb/musb_gadget.c |4
drivers/usb/musb/musb_host.c | 10
8 files changed, 1382 insertions(+), 10 deletions(-)
Index: linux-davinci/drivers/usb/musb/Kconfig
===
--- linux-davinci.orig/drivers/usb/musb/Kconfig
+++ linux-davinci/drivers/usb/musb/Kconfig
@@ -160,10 +160,18 @@ config USB_INVENTRA_DMA
config USB_TI_CPPI_DMA
bool
depends on USB_MUSB_HDRC !MUSB_PIO_ONLY
- default ARCH_DAVINCI
+ default ARCH_DAVINCI_DMx
help
Enable DMA transfers when TI CPPI DMA is available.
+config USB_TI_CPPI41_DMA
+ bool
+ depends on USB_MUSB_HDRC !MUSB_PIO_ONLY
+ default ARCH_DAVINCI_DA8XX
+ select CPPI41
+ help
+ Enable DMA transfers when TI CPPI 4.1 DMA is available.
+
config USB_TUSB_OMAP_DMA
bool
depends on USB_MUSB_HDRC !MUSB_PIO_ONLY
Index: linux-davinci/drivers/usb/musb/Makefile
===
--- linux-davinci.orig/drivers/usb/musb/Makefile
+++ linux-davinci/drivers/usb/musb/Makefile
@@ -53,9 +53,13 @@ ifneq ($(CONFIG_MUSB_PIO_ONLY),y)
musb_hdrc-objs += cppi_dma.o
else
- ifeq ($(CONFIG_USB_TUSB_OMAP_DMA),y)
-musb_hdrc-objs += tusb6010_omap.o
+ ifeq ($(CONFIG_USB_TI_CPPI41_DMA),y)
+musb_hdrc-objs += cppi41_dma.o
+ifeq ($(CONFIG_USB_TUSB_OMAP_DMA),y)
+ musb_hdrc-objs += tusb6010_omap.o
+
+endif
endif
endif
endif
Index: linux-davinci/drivers/usb/musb/cppi41_dma.c
===
--- /dev/null
+++ linux-davinci/drivers/usb/musb/cppi41_dma.c
@@ -0,0 +1,1240 @@
+/*
+ * Copyright (C) 2005-2006 by Texas Instruments
+ * Copyright (c) 2008, MontaVista Software, Inc. sou...@mvista.com
+ *
+ * This file implements a DMA interface using TI's CPPI 4.1 DMA.
+ *
+ * This program is free software; you can distribute it and/or modify it
+ * under the terms of the GNU General Public License (Version 2) as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 59 Temple Place - Suite 330, Boston MA 02111-1307, USA.
+ *
+ */
+
+#include linux/errno.h
+#include linux/dma-mapping.h
+
+#include mach/cppi41.h
+
+#include musb_core.h
+#include musb_dma.h
+#include cppi41_dma.h
+
+/* Configuration */
+#define USB_CPPI41_DESC_SIZE_SHIFT 6
+#define USB_CPPI41_DESC_ALIGN (1 USB_CPPI41_DESC_SIZE_SHIFT)
+#define USB_CPPI41_CH_NUM_PD 64 /* 4K bulk data at full speed */
+#define USB_CPPI41_MAX_PD (USB_CPPI41_CH_NUM_PD * USB_CPPI41_NUM_CH)
+
+#undef DEBUG_CPPI_TD
+#undef USBDRV_DEBUG
+
+#ifdef USBDRV_DEBUG
+#define dprintk(x, ...) printk(x, ## __VA_ARGS__)
+#else
+#define dprintk(x, ...)
+#endif
+
+/*
+ * Data structure definitions
+ */
+
+/*
+ * USB Packet Descriptor
+ */
+struct usb_pkt_desc;
+
+struct usb_pkt_desc {
+ /* Hardware descriptor fields from this point */
+ struct cppi41_host_pkt_desc hw_desc;
+ /* Protocol specific data */
+ dma_addr_t dma_addr;
+ struct usb_pkt_desc *next_pd_ptr;
+ u8 ch_num;
+ u8 ep_num;
+};
+
+/**
+ * struct cppi41_channel - DMA Channel Control Structure
+ *
+ * Using the same for Tx/Rx.
+ */
+struct cppi41_channel {
+ struct dma_channel channel;
+
+ struct cppi41_dma_ch_obj dma_ch_obj; /* DMA channel object */
+ struct cppi41_queue src_queue; /* Tx queue or Rx free descriptor/ */
+ /* buffer queue */
+ struct cppi41_queue_obj queue_obj; /* Tx queue object or Rx free */
+ /* descriptor/buffer queue object */
+
+ u32
[PATCH RFC 2/2] MUSB: DA8xx/OMAP-L1x glue layer (take 2)
Texas Instruments DA8xx/OMAP-L1x glue layer for the MUSBMHRDC driver. Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com Signed-off-by: Yadviga Grigorieva yadv...@ru.mvista.com --- This patch (as well as the previous one) is against the recent DaVinci tree. Changes since the previos take: - s/da830/da8xx/ everywhere since DA850/OMAP-L138 is also supported; - moved CFGCHIPn #define's to mach/da8xx.h and dropped DA830_ prefix; - replaced #include mach/hardware.h with #include mach/da8xx.h... arch/arm/mach-davinci/include/mach/da8xx.h |6 arch/arm/mach-davinci/include/mach/usb.h | 37 ++ drivers/usb/musb/Kconfig |5 drivers/usb/musb/Makefile |6 drivers/usb/musb/da8xx.c | 522 + drivers/usb/musb/musb_core.h |1 6 files changed, 575 insertions(+), 2 deletions(-) Index: linux-davinci/arch/arm/mach-davinci/include/mach/da8xx.h === --- linux-davinci.orig/arch/arm/mach-davinci/include/mach/da8xx.h +++ linux-davinci/arch/arm/mach-davinci/include/mach/da8xx.h @@ -59,6 +59,12 @@ #define PINMUX18 0x48 #define PINMUX19 0x4c +#define CFGCHIP0 0x17c +#define CFGCHIP1 0x180 +#define CFGCHIP2 0x184 +#define CFGCHIP3 0x188 +#define CFGCHIP4 0x18c + void __init da830_init(void); void __init da850_init(void); Index: linux-davinci/arch/arm/mach-davinci/include/mach/usb.h === --- /dev/null +++ linux-davinci/arch/arm/mach-davinci/include/mach/usb.h @@ -0,0 +1,37 @@ +/* + * USB related definitions + * + * Copyright (C) 2009 MontaVista Software, Inc. sou...@mvista.com + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed as is without any warranty of any + * kind, whether express or implied. + */ + +#ifndef __ASM_ARCH_USB_H +#define __ASM_ARCH_USB_H + +/* DA8xx CFGCHIP2 (USB 2.0 PHY Control) register bits */ +#define CFGCHIP2_PHYCLKGD (1 17) +#define CFGCHIP2_VBUSSENSE (1 16) +#define CFGCHIP2_RESET (1 15) +#define CFGCHIP2_OTGMODE (3 13) +#define CFGCHIP2_NO_OVERRIDE (0 13) +#define CFGCHIP2_FORCE_HOST(1 13) +#define CFGCHIP2_FORCE_DEVICE (2 13) +#define CFGCHIP2_FORCE_HOST_VBUS_LOW (3 13) +#define CFGCHIP2_USB1PHYCLKMUX (1 12) +#define CFGCHIP2_USB2PHYCLKMUX (1 11) +#define CFGCHIP2_PHYPWRDN (1 10) +#define CFGCHIP2_OTGPWRDN (1 9) +#define CFGCHIP2_DATPOL(1 8) +#define CFGCHIP2_USB1SUSPENDM (1 7) +#define CFGCHIP2_PHY_PLLON (1 6)/* override PLL suspend */ +#define CFGCHIP2_SESENDEN (1 5)/* Vsess_end comparator */ +#define CFGCHIP2_VBDTCTEN (1 4)/* Vbus comparator */ +#define CFGCHIP2_REFFREQ (0xf 0) +#define CFGCHIP2_REFFREQ_12MHZ (1 0) +#define CFGCHIP2_REFFREQ_24MHZ (2 0) +#define CFGCHIP2_REFFREQ_48MHZ (3 0) + +#endif /* ifndef __ASM_ARCH_USB_H */ Index: linux-davinci/drivers/usb/musb/Kconfig === --- linux-davinci.orig/drivers/usb/musb/Kconfig +++ linux-davinci/drivers/usb/musb/Kconfig @@ -42,7 +42,10 @@ config USB_MUSB_SOC default y if (BF52x !BF522 !BF523) comment DaVinci 35x and 644x USB support - depends on USB_MUSB_HDRC ARCH_DAVINCI + depends on USB_MUSB_HDRC ARCH_DAVINCI_DMx + +comment DA8xx/OMAP-L1x USB support + depends on USB_MUSB_HDRC ARCH_DAVINCI_DA8XX comment OMAP 243x high speed USB support depends on USB_MUSB_HDRC ARCH_OMAP2430 Index: linux-davinci/drivers/usb/musb/Makefile === --- linux-davinci.orig/drivers/usb/musb/Makefile +++ linux-davinci/drivers/usb/musb/Makefile @@ -6,10 +6,14 @@ musb_hdrc-objs := musb_core.o obj-$(CONFIG_USB_MUSB_HDRC)+= musb_hdrc.o -ifeq ($(CONFIG_ARCH_DAVINCI),y) +ifeq ($(CONFIG_ARCH_DAVINCI_DMx),y) musb_hdrc-objs += davinci.o endif +ifeq ($(CONFIG_ARCH_DAVINCI_DA8XX),y) + musb_hdrc-objs += da8xx.o +endif + ifeq ($(CONFIG_USB_TUSB6010),y) musb_hdrc-objs += tusb6010.o endif Index: linux-davinci/drivers/usb/musb/da8xx.c === --- /dev/null +++ linux-davinci/drivers/usb/musb/da8xx.c @@ -0,0 +1,522 @@ +/* + * Texas Instruments DA8XX/OMAP-L137 glue layer + * + * Copyright (c) 2008-2009 MontaVista Software, Inc. sou...@mvista.com + * + * Based on the DaVinci glue layer code. + * Copyright (C) 2005-2006 by Texas Instruments + * + * This file is part of the Inventra Controller Driver for Linux. + * + * The Inventra Controller Driver for Linux 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
[PATCH v1 - 2/5] V4L : vpif capture - Kconfig and Makefile changes
From: Muralidharan Karicheri m-kariche...@ti.com Adds Kconfig and Makefile changes required for vpif capture driver Reviewed-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com --- Applies to V4L-DVB linux-next repository drivers/media/video/Kconfig | 15 +-- drivers/media/video/davinci/Makefile |2 ++ 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 1fa3c87..fc6a83e 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -501,10 +501,21 @@ config DISPLAY_DAVINCI_DM646X_EVM select VIDEO_ADV7343 select VIDEO_THS7303 help - Support for DaVinci based display device. + Support for DM6467 based display device. To compile this driver as a module, choose M here: the - module will be called davincihd_display. + module will be called vpif_display. + +config CAPTURE_DAVINCI_DM646X_EVM + tristate DM646x EVM Video Capture + depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + select VIDEOBUF_DMA_CONTIG + select VIDEO_DAVINCI_VPIF + help + Support for DM6467 based capture device. + + To compile this driver as a module, choose M here: the + module will be called vpif_capture. config VIDEO_DAVINCI_VPIF tristate DaVinci VPIF Driver diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index f44cad2..1a8b8f3 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -7,6 +7,8 @@ obj-$(CONFIG_VIDEO_DAVINCI_VPIF) += vpif.o #DM646x EVM Display driver obj-$(CONFIG_DISPLAY_DAVINCI_DM646X_EVM) += vpif_display.o +#DM646x EVM Capture driver +obj-$(CONFIG_CAPTURE_DAVINCI_DM646X_EVM) += vpif_capture.o # Capture: DM6446 and DM355 obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o -- 1.6.0.4 ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v1 0/5] V4L: vpif_capture driver for DM6467
From: Muralidharan Karicheri m-kariche...@ti.com This patch series add support for VPIF Capture Driver on DM6467. VPIF (Video Port Interface) has two channels for capture video or Raw image data. Currently only video capture is supported using TVP5147 on each of the channel. That means two simultaneous capture of NTSC/PAL video is possible using this driver. This has incorporated comments received against version v0 of the patch series Following are the patches in this series:- 1) DaVinci - re-structuring code to support vpif capture driver 2) V4L : vpif capture - Kconfig and Makefile changes 3) V4L : vpif_capture driver for DM6467 4) V4L : vpif updates for DM6467 vpif capture driver 5) V4L : vpif display - updates to support vpif capture on DM6467 NOTE: All patches are to be applied before build. Mandatory reviewers : Hans Verkuil hverk...@xs4all.nl for V4L tree Kevin Hilman khil...@deeprootsystems.com for DaVinci tree Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
[PATCH v1 - 1/5] DaVinci - restructuring code to support vpif capture driver
From: Muralidharan Karicheri m-kariche...@ti.com
This patch makes the following changes:-
1) Modify vpif_subdev_info to add board_info, routing information
and vpif interface configuration. Remove addr since it is
part of board_info
2) Add code to setup channel mode and input decoder path for
vpif capture driver
Also incorporated comments against version v0 of the patch series and
added a spinlock to protect writes to common registers
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Reviewed-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to DaVinci tree
arch/arm/mach-davinci/board-dm646x-evm.c| 227 --
arch/arm/mach-davinci/dm646x.c | 52 ++-
arch/arm/mach-davinci/include/mach/dm646x.h | 49 +-
3 files changed, 298 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 8c88fd0..c8c65d8 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -33,7 +33,7 @@
#include linux/i2c/at24.h
#include linux/i2c/pcf857x.h
#include linux/etherdevice.h
-
+#include media/tvp514x.h
#include asm/setup.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -63,8 +63,8 @@
#define DM646X_EVM_PHY_MASK(0x2)
#define DM646X_EVM_MDIO_FREQUENCY (220) /* PHY bus frequency */
-#define VIDCLKCTL_OFFSET (0x38)
-#define VSCLKDIS_OFFSET(0x6c)
+#define VIDCLKCTL_OFFSET (DAVINCI_SYSTEM_MODULE_BASE + 0x38)
+#define VSCLKDIS_OFFSET(DAVINCI_SYSTEM_MODULE_BASE + 0x6c)
#define VCH2CLK_MASK (BIT_MASK(10) | BIT_MASK(9) | BIT_MASK(8))
#define VCH2CLK_SYSCLK8(BIT(9))
@@ -75,6 +75,18 @@
#define VIDCH2CLK (BIT(10))
#define VIDCH3CLK (BIT(11))
+#define VIDCH1CLK (BIT(4))
+#define TVP7002_INPUT (BIT(4))
+#define TVP5147_INPUT (~BIT(4))
+#define VPIF_INPUT_ONE_CHANNEL (BIT(5))
+#define VPIF_INPUT_TWO_CHANNEL (~BIT(5))
+#define TVP5147_CH0tvp514x-0
+#define TVP5147_CH1tvp514x-1
+
+static void __iomem *vpif_vidclkctl_reg;
+static void __iomem *vpif_vsclkdis_reg;
+/* spin lock for updating above registers */
+static spinlock_t vpif_reg_lock;
static struct davinci_uart_config uart_config __initdata = {
.enabled_uarts = (1 0),
@@ -348,7 +360,7 @@ static struct i2c_board_info __initdata i2c_info[] = {
I2C_BOARD_INFO(cpld_reg0, 0x3a),
},
{
- I2C_BOARD_INFO(cpld_video, 0x3B),
+ I2C_BOARD_INFO(cpld_video, 0x3b),
},
};
@@ -359,18 +371,20 @@ static struct davinci_i2c_platform_data i2c_pdata = {
static int set_vpif_clock(int mux_mode, int hd)
{
+ unsigned long flags;
+ unsigned int value;
int val = 0;
int err = 0;
- unsigned int value;
- void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
- if (!cpld_client)
+ if (!vpif_vidclkctl_reg || !vpif_vsclkdis_reg || !cpld_client)
return -ENXIO;
/* disable the clock */
- value = __raw_readl(base + VSCLKDIS_OFFSET);
+ spin_lock_irqsave(vpif_reg_lock, flags);
+ value = __raw_readl(vpif_vsclkdis_reg);
value |= (VIDCH3CLK | VIDCH2CLK);
- __raw_writel(value, base + VSCLKDIS_OFFSET);
+ __raw_writel(value, vpif_vsclkdis_reg);
+ spin_unlock_irqrestore(vpif_reg_lock, flags);
val = i2c_smbus_read_byte(cpld_client);
if (val 0)
@@ -385,7 +399,7 @@ static int set_vpif_clock(int mux_mode, int hd)
if (err)
return err;
- value = __raw_readl(base + VIDCLKCTL_OFFSET);
+ value = __raw_readl(vpif_vidclkctl_reg);
value = ~(VCH2CLK_MASK);
value = ~(VCH3CLK_MASK);
@@ -394,24 +408,30 @@ static int set_vpif_clock(int mux_mode, int hd)
else
value |= (VCH2CLK_AUXCLK | VCH3CLK_AUXCLK);
- __raw_writel(value, base + VIDCLKCTL_OFFSET);
+ __raw_writel(value, vpif_vidclkctl_reg);
/* enable the clock */
- value = __raw_readl(base + VSCLKDIS_OFFSET);
+ spin_lock_irqsave(vpif_reg_lock, flags);
+ value = __raw_readl(vpif_vsclkdis_reg);
value = ~(VIDCH3CLK | VIDCH2CLK);
- __raw_writel(value, base + VSCLKDIS_OFFSET);
+ __raw_writel(value, vpif_vsclkdis_reg);
+ spin_unlock_irqrestore(vpif_reg_lock, flags);
return 0;
}
-static const struct vpif_subdev_info dm646x_vpif_subdev[] = {
+static struct vpif_subdev_info dm646x_vpif_subdev[] = {
{
- .addr = 0x2A,
.name = adv7343,
+ .board_info = {
+ I2C_BOARD_INFO(adv7343, 0x2a),
+ },
},
{
- .addr = 0x2C,
[PATCH v1 - 4/5] V4L : vpif updates for DM6467 vpif capture driver
From: Muralidharan Karicheri m-kariche...@ti.com
Following changes done for vpif driver to support vpif capture:-
1) Current version of display driver defined vpif register
space as part for vpif display platform driver resource
This is not correct since vpif is common across capture
and display drivers. So the resource iomap function is
moved to this module
2) Since there are common registers, a spinlock is added for
mutual exclusion.
This has incorporated comments against version v0 of the patch series
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next repository
drivers/media/video/davinci/vpif.c | 76 ---
drivers/media/video/davinci/vpif.h | 48 ++-
2 files changed, 98 insertions(+), 26 deletions(-)
diff --git a/drivers/media/video/davinci/vpif.c
b/drivers/media/video/davinci/vpif.c
index aa77126..3b8eac3 100644
--- a/drivers/media/video/davinci/vpif.c
+++ b/drivers/media/video/davinci/vpif.c
@@ -19,7 +19,11 @@
#include linux/init.h
#include linux/module.h
+#include linux/platform_device.h
+#include linux/spinlock.h
#include linux/kernel.h
+#include linux/io.h
+#include mach/hardware.h
#include vpif.h
@@ -31,6 +35,12 @@ MODULE_LICENSE(GPL);
#define VPIF_CH2_MAX_MODES (15)
#define VPIF_CH3_MAX_MODES (02)
+static resource_size_t res_len;
+static struct resource *res;
+spinlock_t vpif_lock;
+
+void __iomem *vpif_base;
+
static inline void vpif_wr_bit(u32 reg, u32 bit, u32 val)
{
if (val)
@@ -151,17 +161,17 @@ static void config_vpif_params(struct vpif_params
*vpifparams,
else if (config-capture_format) {
/* Set the polarity of various pins */
vpif_wr_bit(reg, VPIF_CH_FID_POLARITY_BIT,
- vpifparams-params.raw_params.fid_pol);
+ vpifparams-iface.fid_pol);
vpif_wr_bit(reg, VPIF_CH_V_VALID_POLARITY_BIT,
- vpifparams-params.raw_params.vd_pol);
+ vpifparams-iface.vd_pol);
vpif_wr_bit(reg, VPIF_CH_H_VALID_POLARITY_BIT,
- vpifparams-params.raw_params.hd_pol);
+ vpifparams-iface.hd_pol);
value = regr(reg);
/* Set data width */
value = ((~(unsigned int)(0x3))
VPIF_CH_DATA_WIDTH_BIT);
- value |= ((vpifparams-params.raw_params.data_sz)
+ value |= ((vpifparams-params.data_sz)
VPIF_CH_DATA_WIDTH_BIT);
regw(value, reg);
}
@@ -227,8 +237,60 @@ int vpif_channel_getfid(u8 channel_id)
}
EXPORT_SYMBOL(vpif_channel_getfid);
-void vpif_base_addr_init(void __iomem *base)
+static int __init vpif_probe(struct platform_device *pdev)
+{
+ int status = 0;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENOENT;
+
+ res_len = res-end - res-start + 1;
+
+ res = request_mem_region(res-start, res_len, res-name);
+ if (!res)
+ return -EBUSY;
+
+ vpif_base = ioremap(res-start, res_len);
+ if (!vpif_base) {
+ status = -EBUSY;
+ goto fail;
+ }
+
+ spin_lock_init(vpif_lock);
+ dev_info(pdev-dev, vpif probe success\n);
+ return 0;
+
+fail:
+ release_mem_region(res-start, res_len);
+ return status;
+}
+
+static int vpif_remove(struct platform_device *pdev)
{
- vpif_base = base;
+ iounmap(vpif_base);
+ release_mem_region(res-start, res_len);
+ return 0;
}
-EXPORT_SYMBOL(vpif_base_addr_init);
+
+static struct platform_driver vpif_driver = {
+ .driver = {
+ .name = vpif,
+ .owner = THIS_MODULE,
+ },
+ .remove = __devexit_p(vpif_remove),
+ .probe = vpif_probe,
+};
+
+static void vpif_exit(void)
+{
+ platform_driver_unregister(vpif_driver);
+}
+
+static int __init vpif_init(void)
+{
+ return platform_driver_register(vpif_driver);
+}
+subsys_initcall(vpif_init);
+module_exit(vpif_exit);
+
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h
index fca26dc..188841b 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -19,6 +19,7 @@
#include linux/io.h
#include linux/videodev2.h
#include mach/hardware.h
+#include mach/dm646x.h
/* Maximum channel allowed */
#define VPIF_NUM_CHANNELS (4)
@@ -26,7 +27,9 @@
#define VPIF_DISPLAY_NUM_CHANNELS (2)
/* Macros to
[PATCH v1 - 5/5] V4L : vpif display - updates to support vpif capture on DM6467
From: Muralidharan Karicheri m-kariche...@ti.com
The structure name for vpif display driver changed since it was not unique. So
this
update is done to reflect the same. Also removed the code related to register
address space iomap. Uses v4l2_i2c_new_subdev_board() instead of
v4l2_i2c_new_probed_subdev() so that platform data can be added for subdevice
configuration for polarities.
This has incorporated comments against version v0 of the patch series.
NOTE: This patch is dependent on the patch from Chaithrika for vpif display.
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
Applies to V4L-DVB linux-next repository
drivers/media/video/davinci/vpif_display.c | 52 +++
1 files changed, 14 insertions(+), 38 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index 969d4b3..ccc38b3 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -683,7 +683,7 @@ static int vpif_release(struct file *filep)
static int vpif_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
- struct vpif_config *config = vpif_dev-platform_data;
+ struct vpif_display_config *config = vpif_dev-platform_data;
cap-version = VPIF_DISPLAY_VERSION_CODE;
cap-capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
@@ -1053,7 +1053,7 @@ static int vpif_streamon(struct file *file, void *priv,
struct common_obj *common = ch-common[VPIF_VIDEO_INDEX];
struct channel_obj *oth_ch = vpif_obj.dev[!ch-channel_id];
struct vpif_params *vpif = ch-vpifparams;
- struct vpif_config *vpif_config_data =
+ struct vpif_display_config *vpif_config_data =
vpif_dev-platform_data;
unsigned long addr = 0;
int ret = 0;
@@ -1239,7 +1239,7 @@ static int vpif_enum_output(struct file *file, void *fh,
struct v4l2_output *output)
{
- struct vpif_config *config = vpif_dev-platform_data;
+ struct vpif_display_config *config = vpif_dev-platform_data;
if (output-index = config-output_count) {
vpif_dbg(1, debug, Invalid output index\n);
@@ -1422,10 +1422,10 @@ vpif_init_free_channel_objects:
*/
static __init int vpif_probe(struct platform_device *pdev)
{
- const struct subdev_info *subdevdata;
+ struct vpif_subdev_info *subdevdata;
int i, j = 0, k, q, m, err = 0;
struct i2c_adapter *i2c_adap;
- struct vpif_config *config;
+ struct vpif_display_config *config;
struct common_obj *common;
struct channel_obj *ch;
struct video_device *vfd;
@@ -1433,30 +1433,14 @@ static __init int vpif_probe(struct platform_device
*pdev)
int subdev_count;
vpif_dev = pdev-dev;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- v4l2_err(vpif_dev-driver,
- Error getting platform resource\n);
- return -ENOENT;
- }
- if (!request_mem_region(res-start, res-end - res-start + 1,
- vpif_dev-driver-name)) {
- v4l2_err(vpif_dev-driver, VPIF: failed request_mem_region\n);
- return -ENXIO;
- }
+ err = initialize_vpif();
- vpif_base = ioremap_nocache(res-start, res-end - res-start + 1);
- if (!vpif_base) {
- v4l2_err(vpif_dev-driver, Unable to ioremap VPIF reg\n);
- err = -ENXIO;
- goto resource_exit;
+ if (err) {
+ v4l2_err(vpif_dev-driver, Error initializing vpif\n);
+ return err;
}
- vpif_base_addr_init(vpif_base);
-
- initialize_vpif();
-
err = v4l2_device_register(vpif_dev, vpif_obj.v4l2_dev);
if (err) {
v4l2_err(vpif_dev-driver, Error registering v4l2 device\n);
@@ -1489,7 +1473,7 @@ static __init int vpif_probe(struct platform_device *pdev)
video_device_release(ch-video_dev);
}
err = -ENOMEM;
- goto video_dev_alloc_exit;
+ goto vpif_int_err;
}
/* Initialize field of video device */
@@ -1566,10 +1550,11 @@ static __init int vpif_probe(struct platform_device
*pdev)
}
for (i = 0; i subdev_count; i++) {
- vpif_obj.sd[i] = v4l2_i2c_new_probed_subdev(vpif_obj.v4l2_dev,
+ vpif_obj.sd[i] = v4l2_i2c_new_subdev_board(vpif_obj.v4l2_dev,
i2c_adap, subdevdata[i].name,
- subdevdata[i].name,
- subdevdata[i].addr);
+
Re: [PATCH v3] davinci: Add NOR flash support for da850/omap-l138
Sudhakar Rajashekhara wrote: I am not seeing any of these patches in the tree. Something wrong? Sorry, didn't push out. Pushed now. 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] davinci: Handle pinmux conflict between mmc/sd and nor flash
Sudhakar Rajashekhara sudhakar@ti.com writes:
On Fri, Aug 14, 2009 at 04:51:05, Kevin Hilman wrote:
Sudhakar Rajashekhara sudhakar@ti.com writes:
On DA850/OMAP-L138 EVM, MMC/SD and NOR Flash share
some of the AEMIF pins. This patch prints out a warning
during booting, if both MMC/SD and NOR Flash are enabled
in kernel menuconfig.
If both MMC/SD and NOR Flash are enabled, only MMC/SD
will work correctly.
Signed-off-by: Sudhakar Rajashekhara sudhakar@ti.com
---
This patch is dependent on the following patches which
I have submitted earlier:
[PATCH] davinci: Macro to convert GPIO signal to GPIO pin number
[PATCH v3] davinci: Add platform support for da850/omap-l138 GLCD
[PATCH v3] davinci: Add MMC/SD support for da850/omap-l138
[PATCH v3] davinci: Add NAND flash support for DA850/OMAP-L138
[PATCH v3] davinci: Add NOR flash support for da850/omap-l138
FYI for future reference. When you have lots of patch dependencies
like this, it is simpler to send them as a series. If you use
git-format-patch for a range of commits, it will automatically do
the 'PATCH x/y' formatting etc.
In this case, in the series if one patch needs modifications
then do I need to re-submit the whole series again?
Usually, just resubmitting the changed patch is all that is needed,
unless of course it affects code changed by later patches.
[...]
+ if (HAS_MMC) {
+ if (HAS_NOR)
+ pr_warning(WARNING: both NOR Flash and MMC/SD are
+ enabled, but they share AEMIF pins.\n
+ \tDisable one of them.\n);
+
Hmm, this isn't quite right. MMC will never be configured unless NOR
is enabled also.
This is not the case now. MMC will get initialized even if NOR is
not enabled. If the second if condition is true it only prints the
warning and proceeds to initialize MMC.
You're right, sorry for the noise.
Pushed along with the others just now.
Kevin
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
DaVinci git: updated to v2.6.31-rc6
DaVinci git updated to v2.6.31-rc6. A minor update so only boot tested on dm6446 EVM and da850 EVM. Also, FYI... my response/review of patches will likely be slow for a couple weeks due to travel. 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: Regarding increase in Sever Thread stack size
Is this what you're looking for?:
var Server = xdc.useModule('ti.sdo.ce.Server');
Server.algs = [
{name: viddec_copy, mod: VIDDEC_COPY, threadAttrs: {
stackSize: 0x4096, stackMemId: 0, priority: Server.MINPRI + 2}, groupId
: 0,
},
{name: videnc_copy, mod: VIDENC_COPY, threadAttrs: {
stackMemId: 0, priority: Server.MINPRI + 2}, groupId : 0,
}
];
The max limit is dictated by your available memory for BIOS TSK stacks.
- Rob
From: davinci-linux-open-source-boun...@linux.davincidsp.com
[mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On Behalf Of
Sandeep YEDIRE
Sent: Tuesday, August 11, 2009 10:34 PM
To: davinci-linux-open-source@linux.davincidsp.com
Cc: Sandeep Yedire
Subject: Regarding increase in Sever Thread stack size
Hello all,
is there anyway to increase server thread stack size for one particular codec?
What is max limit ?
Many Thanks,
Sandeep.Yedire
See the Web's breaking stories, chosen by people like you. Check out Yahoo!
Buzzhttp://in.rd.yahoo.com/tagline_buzz_1/*http://in.buzz.yahoo.com/.
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
